jbowe@diamond.bbn.com (John Bowe) (11/15/89)
Here is a fix to rexd.c to do some security checking. When rexd gets a request, it finds the IP address of the requester. The addition I made is to find its host name and look it up in /etc/hosts.equiv. It essentially makes rexd as secure as rshd. This is for OS3.x sources. Does anyone have a fix for OS4? We don't have OS4 src. Ed's Note: Fixes placed in archives. FTP: Hostname : titan.rice.edu (128.42.30.1) Directory: sun-source Filename : rexd.c.fixes Archive Server Address: archive-server@rice.edu Archive Server Command: send sun-source rexd.c.fixes John Bowe <jbowe@bbn.com>
jdp@uunet.uu.net (John Polstra) (12/05/89)
In article <3170@brazos.Rice.edu> jbowe@diamond.bbn.com (John Bowe) writes: >X-Sun-Spots-Digest: Volume 8, Issue 202, message 13 of 17 > >Here is a fix to rexd.c to do some security checking. When rexd gets a >request, it finds the IP address of the requester. The addition I made is >to find its host name and look it up in /etc/hosts.equiv. It essentially >makes rexd as secure as rshd. Oh no it doesn't! Rsh and rshd use the reserved port mechanism as the basis of whatever security they have. When rshd receives a request, it checks to make sure that the request has come from one of the IP reserved ports (port number < 1024). If the requesting port is not a reserved port, rshd refuses to do anything. Only the superuser can get a reserved port. That is why rsh is setuid-root. It performs authentification on the *requesting* end, then gets a reserved port to pass the request on to rshd on the other machine. The idea is that an ordinary user cannot spoof the authentification, because he cannot get a reserved port. Any spoofing would have to be done by somebody with root privileges. In essence, if machine X is listed in hosts.equiv it means "we trust the superuser on machine X", *not* "we trust everybody on machine X". Rexd and on don't do any checking for reserved ports. I know this because an ls -l of /usr/bin/on reveals that it is not setuid-root. Without the reserved port mechanism, it is fairly easy for any normal user to put together a fake request to rexd and make it do almost anything he wants it to. Note: Don't bother sending me messages saying, "Oh yeah, well rsh and rshd aren't very secure either, because ...". I know all about that. I'm not claiming that rsh and rshd are secure in any absolute sense. I'm just pointing out that rexd and on will never be as secure as rshd and rsh, until /usr/bin/on becomes setuid-root and they start using the IP reserved port mechanism. John Polstra jdp@polstra.UUCP Polstra & Co., Inc. ...{uunet,sun}!practic!polstra!jdp Seattle, WA (206) 932-6482