[comp.protocols.tcp-ip] hosts.equiv considered harmful

csd1032@UX.ACSS.UMN.EDU ("Aaron Y. T. Cheung") (11/20/88)

In article <185@bnr-fos.UUCP> hwt@bnr-public.UUCP (Henry Troup) writes:
|
| I just checked my SunOS 4.0 *distribution tape* hosts.equiv.  The
| file consists of "+\n".  A quick RofTFM shows that this means
| ***trust everyone***  Surprise!

Putting a "+" in hosts.equiv is definitely an oversight, and the problem
becomes quite seriuos when two vendors' oversights are put to work together:

Here we're in wide-spread use of a type of terminal server which is capable
of several login protocols (vis, telnet, rlogin, call).  The rlogin works
the usual way (rlogin <remotehost> [-l <remoteuser>]) except that when
connecting to a remote host, it uses the user-supplied <remoteuser> as
arguments to *BOTH* of the locuser and remuser parameters in the rcmd() call.
man rcmd for details. (The locuser is usually returned by "getpwuid(getuid())"
from the user's environment who is invoking the rlogin; but being a terminal
server, it wouldn't make too much sense, and hence is [apparently] not used).
Security checkpoint #1 passed....

Each of these terminal servers bears an Internet name and address, which
is listed in the [locally, centrally distributed] host table too.  The "+"
in hosts.equiv on a particular machine tells that machine to trust all hosts
it knows, including these terminal servers!
Security checkpoint #2 passed....

Consequence?  "rlogin john -l doe" logins the user in as doe on machine john,
WITHOUT A PASSWORD.

Quite an amusement, eh?  Btw, this is not hypothetical, it actually happenED.

/*
 *   Aaron Y. T. Cheung
 */