[1610] in linux-security and linux-alert archive
[linux-security] Re: Re: Re: Re: Re: Security Concern..
daemon@ATHENA.MIT.EDU (David Holland)
Fri Sep 19 04:20:13 1997
From: David Holland <dholland@eecs.harvard.edu>
To: linux-security@redhat.com
Date: Fri, 19 Sep 1997 01:39:08 -0400 (EDT)
In-Reply-To: <Pine.LNX.3.95.970918212207.1229A-100000@nemesis.psionic.com> from "Craig H. Rowland" at Sep 18, 97 10:21:27 pm
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
> Unfortunately this is true. I think there really are few long term
> solutions. The ones that come to me offhand include:
>
> - Banish all the Berkely-style r-commands altogether as they are antiques
> and continuous security problems. I've basically seen three *primary* uses
> for rsh, rlogin, rcp, etc. over the years of doing security audits:
Yeah, basically. Unfortunately, ssh isn't really an adequate universal
alternative until the legal problems get resolved. If they ever do.
Now, I think the next release of (linux) netkit-rsh is going to have
the default behavior of rlogind to ignore .rhosts and hosts_equiv
entries; you'll have to give it an option in inetd.conf to allow
them. I may hack rshd so it refuses to do anything at all unless the
same option is used.
And, if I get time, I'm going to fix rsh so it drops to the rexec
protocol (so it can ask for a password) if rcmd() doesn't work. rexec
isn't any worse than unencrypted rlogin to my knowledge; if I'm wrong
please let me know.
> I would personally take my chances with a sniffer on the network grabbing
> my password than to have a large number of transitive trusts between
> hosts.
Worse, if you can have a sniffer on your network, you can probably
also have someone performing active spoofing/hijacking attacks.
> Assuming we want to keep this poor security check in place we could
> change the kernel to allow the rresvport() call to bind to a port in the
> range of 1000-1024 without root privileges. Of course this opens up a
> whole new can of worms (although not as big as giving these commands
> SUID).
The purpose of having the commands setuid is that since only root can
bind a privileged port, the information sent by the rsh client must
have been sent by root, and therefore wasn't supplied by some random
malicious user. Since rshd has no mechanism for authentication besides
this, if you let anyone bind the privileged ports, anyone can pretend
to be any remote user as far as rshd is concerned. This is not a good
thing, because it means that ordinary users on the box who haven't
hacked root yet and don't have physical access to the network can
spoof rshd, making it even more insecure than it already is.
--
- David A. Holland | VINO project home page:
dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino
