[1611] in linux-security and linux-alert archive
[linux-security] r-cmds (was Security Concern)
daemon@ATHENA.MIT.EDU (Yuri Volobuev)
Fri Sep 19 05:46:40 1997
Date: Fri, 19 Sep 1997 02:20:23 -0500 (CDT)
From: Yuri Volobuev <volobuev@t1.chem.umn.edu>
Reply-To: Yuri Volobuev <volobuev@t1.chem.umn.edu>
To: linux-security@redhat.com
In-Reply-To: <Pine.LNX.3.95.970918212207.1229A-100000@nemesis.psionic.com>
Resent-From: linux-security@redhat.com
On Thu, 18 Sep 1997, Craig H. Rowland wrote:
> 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.
[stuff deleted]
> 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.
....and not-so-lazy sysadmins trying to make management of big networks at
least partially automated. How would you apply your regular security patch
to some several dozens workstations without some form of transitive trust?
Apart from sysadmin tasks (software updates, backups, accounting, logins
managament) there're few other things that depend on r-commands. Good
example would be various message-passing libraries (e.g. PVP, MPI, etc.)
that simply won't work without a working equivalent of rsh (such a library,
or a summplimentary tool, starts several instances of a parallel job,
typically on a massively parallel (super)computer or a workstation cluster.
It happens non-interactively, there's no chance for user to type in
anything). Sure, with enough effort one can probably come up with a better
way to do all of the above, but life is much too short to fix everything.
Note, I'm arguing about the concept of trunsitive trust, not the fact that
r-cmds should be used for anything.
While some installations may not require any form of transitive trust some
certainly do. Not to say that there's any good reason to keep rlogind/rshd
enabled when ssh can be installed. If only ssh could emulate rsh, so that
one doesn't have to keep rsh binary around to talk to less fortunate
boxes... but I guess it's a political, rather than technical, question. If
not, patching ssh would be rather simple.
[mod: Please people, lets put this to rest. There is no ONE way to
configure a site. You get to choose between the "two evils". Some
sites require protection against sniffing, others feel unhappy about
the transitive trust. My experience shows that those sysops who have
been able to spoof a host themselves are more afraid for transitive
trust, while those that have experience sniffing are afraid for packet
sniffers. Take this as a warning that for others it can be "easy" to
do the thing you're not good at. -- REW]
> 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.
While a connection coming from a reserved port says nothing about the
originator's good or bad intentions, it certainly says that uid=0 was
involved there somewhere. Which means the guy was using r-cmd which
authentificated him, and there's a reason to believe that he's really the
one who he's pretending to be (unless that r-cmd is buggy or guy has root
anyway). If rlogind was to accept connections from any port, what's
stopping me from logging in to a remote machine as any user on the system,
by compiling and using an improved version of rsh that accepts my username
from the command line, rather than doing getuid()? You have to have a way
to keep users honest, at least you should try.
cheers,
yuri
