By Rik Farrow
Questions regarding this article should be directed to the author at email@example.com.
The trusted host problems had their genesis way back in the early '80's, when the Computer Science Research Group at University of California, Berkeley Campus was commissioned by DARPA (Advanced Research Projects Agency, part of the Department of Defense), to improve the UNIX system. A large part of this project was porting the TCP/IP protocols and applications to the UNIX system and the C language, a very important event in itself.
Before the Telnet application was completely ported, some
simpler applications were written to permit remote logins and
execution of programs. These programs--known collectively known
as the ``r'' commands--consist of
rlogin, rsh, rcp,
and some others. It is the first three which concern us here,
because of the trust problem.
In a university environment, especially in the early eighties, when computers were still rare and there were only 200 sites on the ARPANET (pre-Internet), security was not a big concern. But convenience was so the ``r'' commands are big on convenience and short on security.
Let's imagine that there are three systems named violet,
daisy, and boffo, all on the same network, and that the
administrator of violet trusts daisy, and vice versa. The
configuration file that spells out this trust arrangement is
/etc/hosts.equiv (see Listing 1). Now, any user with an
account on both systems can login into his or her account on the
other system without re-entering a password. The assumption is
that if a user is logged on to a trusted system, he or she should
not be required to authenticate by using a password a second
rlogin command passes along the names of the
remote user and the remote host, and the local
rlogin server (
rlogind) uses this
information to determine whether the user is pre-authenticated or
if a password should be required. Commands other than
rlogin will not even prompt for a password if trust
has not been extended. That is, if you want to use
rcp, you must have setup trust
In some cases, a user might have a different name on each
host. The ``r'' commands provide for this too. Each user can
have a file named
.rhosts in their home directory.
The user places host name-user name pairs in this file. For
example, a user named rik on violet but rfarrow on daisy might
include a line like ``daisy rfarrow'' so that he could log into
his own account on violet without entering a password. In the
case of the root (superuser), the
file is always ignored, and only
Hopefully, you are already beginning to notice some red flags
flying. For one thing, allowing users to create their own
~/.rhosts file means that any user can share his or
her account with any other user with no password. Sharing
accounts is never a good idea, and letting your users arrange
this on their own is an even worse idea. I suggest that you
decide whether to allow this or not, and make it part of your
local security policy. You can enforce this by having the
cron daemon run a shell script which looks for
.rhosts files in all home directories, mails a copy
of any such file to root, remove the file, and mail a warning to
Even arranging for trust with the
/etc/hosts.equiv file is not safe. Remember that I
said there were three machines, but have so far left out boffo.
Suppose the administrator of violet doesn't trust boffo, but
daisy's admin does. So a user from boffo can log into daisy, and
then from there log into a similarly-named account on violet--
even though violet's configuration file would deny this. Trust
is transitive. When setting up a trust arrangement, it is
essential that trust not be extended to any system
outside the local ring of trusted systems.
Sun Microsystems has participated in one of the darker moments
in UNIX system security. In all releases of SunOS, including the
latest (4.1.4), and the first several releases of Solaris 2.x
(but not including 2.3), the
included with the distribution contains only a single visible
character, the plus sign (
+). The plus sign is the
wild card, and means that a newly installed Sun system running
SunOS trusts any user (except root) on any host. While
most systems won't have an account for rik or guest on them, they
will have standard accounts, such as bin. Thus, an intruder
could log into any Sun system (which hadn't been correctly
configured) as the bin user, across the network, with no
Was Sun trying to make their systems insecure intentionally?
No, although they certainly succeeded. Having the plus sign just
made newly installed Sun workstations easier to use on a network.
If you have Sun systems, check for the plus sign in
/etc/hosts.equiv anywhere in the file by itself at
the beginning of a line. A plus sign in front of a hostname is
okay (but not necessary). The plus sign works the same way on any
system that supports the ``r'' commands, and you should delete it
if found (or trust everyone). A minus sign denies access. You
could have a
/etc/hosts.equiv file with just a minus
sign, and deny access.
Of course, if this were the only problem, things wouldn't be
too bad. The
rlogin command does have a bright
side. When trust is extended, no password is sent across the
network, so password sniffing programs will fail. You might also
be using ``r'' commands locally to aid in system administration.
What you should not do is allow use of the ``r'' commands between
networks which you do not control and therefore, can't trust.
Someone who wishes to break into a UNIX system will often
search for trust relationships. Kevin Mitnick did this (see my last column), and this is not
uncommon. Or suppose that a person running a password sniffer
captures the packets showing the use of
without a password. The sniff file includes the name of the
local and remote hosts, and the account name. To login, all they
have to do is fake his or her own host name and account name.
The ``r'' servers rely on the names found in the
rlogin request to determine if the request will be
permitted or denied. If the server blindly trusts this
information, then the attacker can login with no password.
Modern ``r'' servers include a reverse name lookup. That is,
they use the source IP address and convert it to a hostname using
gethostbyaddr(). If the hostname discovered by
converting the IP address doesn't match the name in the
rlogin packet, access is denied. Sun systems do
this, but is it sufficient? Nope. The attacker probably
controls the remote system, and can tell the Domain Name System
there to lie (see Steven Bellovin's paper ``Using DNS for System
Break-ins'' in the Proceedings of the Fifth Usenix Security
Or, in another attack, the attacker uses initial sequence number guessing (see my last column) and sends packets to the ``r'' server without ever receiving a reply. This is the form of IP address spoofing used by Kevin Mitnick in his Christmas Day attack.
There are a couple of things you can do to prevent these
attacks. One is to block packets destined for the ``r'' commands
from ever entering your network. The ``r'' servers listen at
ports 512 (
rexec, used by
rlogin), and 514 (
rsh). These are
connection-oriented services, and use the TCP protocol. Blocking
these with a packet filtering router is relatively easy to do.
Firewalls based on proxy servers typically block these by
You can also defend individual systems by turning off these
services if you don't intend to use them. The
/etc/inetd.conf file contains entries for each of
these services (see Listing 2). You
disable these services by putting a octothorp (pound sign or
#) at the beginning of the line, and sending a
hangup signal (SIGHUP, use
kill -HUP) to the
The ``r'' commands are certainly convenient. You can do
tricks with them, for example, access a remote tape drive as if
it were local by using
rsh to drive
But the lack of strong authentication is a terrible weakness.
Newer versions of the ``r'' commands include support for Kerberos
IV, which means if you are using Kerberos you could use the ``r''
commands in relative safety. If not, it is time to make some
decisions about your site, or at least the systems under your
control, about supporting these utilities. And check those Suns.
Remember that any system you have upgraded to a later version of
SunOS may have the plus sign in
(unless you overwrote it with your own file during
Last Modified: Tuesday, 22-Aug-95 15:56:02 PDT