[1608] in linux-security and linux-alert archive
[linux-security] Re: Re: Re: Re: Security Concern..
daemon@ATHENA.MIT.EDU (Craig H. Rowland)
Fri Sep 19 01:22:46 1997
Date: Thu, 18 Sep 1997 22:21:27 -0500 (CDT)
From: "Craig H. Rowland" <crowland@psionic.com>
To: linux-security@redhat.com
In-Reply-To: <199709181810.OAA00605@burgundy.eecs.harvard.edu>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
On Thu, 18 Sep 1997, David Holland wrote:
> > >> >-rwsr-xr-x 1 root bin 13937 Dec 5 1995 /usr/bin/rcp
> > >> and also this one
> > >
> > >losing rcp functionality.
> >
> > Nope. 'rcp' calls the privileged 'rsh' to perform the actual protocol.
> > 'rcp' itself doesn't need privileges at all, and IIRC it tries to throw
> > them away if it discovers that it has them.
>
> I wish. It uses rcmd().
>
> The long term solution to this problem is to change rcmd() to call
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:
1) System admins too lazy to type in their passwords between
systems.
2) Users too lazy to type in their passwords between systems.
3) Hackers abusing the above to ride transitive trusts
throughout a network.
I think that products like SSH are a very acceptable alternative to most
all of the r-commands. What amazes me the most about these commands
is the frequency they are linked to system intrusion, yet virtually all OS
vendors ship with them enabled. Some even go a step further and put the
'+' in /etc/hosts.equiv for you.
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. It certainly is the lesser of two evils. (For the truly paranoid,
you can hold down your enter key at the login: prompt for a second or two
as many [not all] password sniffers drop the session after 120 or so bytes
collected).
- The reason rcmd() needs root privs is to make a call to rresvport()
which binds the process to a privileged port before making a connection.
This is to allow the antique r-commands to do part of their
"authentication" based on the fact that the user is coming from reserved
port number ( from BSD 4.4 source for in.rshd ):
if (fromp->sin_port >= IPPORT_RESERVED ||
fromp->sin_port < IPPORT_RESERVED/2) {
syslog(LOG_NOTICE|LOG_AUTH,
"Connection from %s on illegal port %u",
inet_ntoa(fromp->sin_addr),
fromp->sin_port);
exit(1);
}
Naturally, if I'm coming from a reserved port I must be an OK guy
according to this check. I must be missing the point here as to why this
service *needs* to have the client come from a reserved port. There
certainly are no security reasons that I can think of, especially since
all these commands run SUID.
[ As a side note, if you see the string "Connection from <hostname> on
illegal port <un-reserved port>" in your logs then you can probably bet
that a person just hit your box with a port scan. All of you hackers
should know by now that to do a proper port scan you should originate from
a *reserved* port number, preferably port 20 (FTP-DATA channel) so you can
hop many incorrectly configured packet filters ]
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).
Anyway...just a rant sorry for the intrusion..
-- Craig
>
> --
> - David A. Holland | VINO project home page:
> dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino
>
