Section 4.5 The rsh, rcp, TTrexecTT, and TTrloginTT Services

---

4.5 The rsh, rcp, rexec, and rlogin Services

In "Turn Off rsh, rcp, rlogin, and rexec" on page 100 it was recommended that these services be turned off because they are not considered secure and that SSH is an excellent secure alternative. Because these services are so popular (because they are useful), an explanation about how they work and their insecurity is offered here.

The rsh, rcp, rexec, and rlogin services are too insecure and too dangerous to use. Remove them from your systems and forbid their use. Really.

These allow one to remotely execute a process. In other words an account named joe on remote system zoro.com can issue the command

 rsh pentacorp.com stab files 

This will ask that pentacorp.com execute the command stab files as account joe. The authentication (to verify that this request be allowed) is by looking up the initiating system's name and account name (zoro.com and joe) in two configuration files on the pentacorp.com system.

If the initiating system's name appears in the system-wide configuration file /etc/hosts.equiv, any request from a user name on that system to pentacorp.com for the same user name will be honored. In other words, if the entry

zoro.com

appears in /etc/hosts.equiv on pentacorp.com, any user on zoro.com can do rsh commands as the same user name on pentacorp.com. Thus, zoro.com user joe can have commands executed by user joe on pentacorp.com and user cindy on zoro.com can have commands executed by user cindy on pentacorp.com but zoro.com user joe is not given permission by /etc/hosts.equiv to execute commands as user cindy on pentacorp.com and vice versa. Individual users may grant additional permissions for remote users to operate under their accounts. This is done by creating the file .rhosts in a user's home directory and adding the desired entries. Each entry takes up a line and may be in either of two formats.

The first format lists just the host name of the remote system allowed to rsh. Thus, if cindy's home Linux box is hv.isp.com and her personal account on it also is cindy she could add the entry

hv.isp.com

to her .rhosts file. Suppose cindy also is taking a night class at Georgia Tech and her account is cc02 on cory.gatech.com. She cannot specify cory.gatech.com because the account is different. Instead she specifies the host name, a space, and the remote account name such as

 cory.gatech.com cc02 

If she also is taking a class on comparative religion and that account is cr72, her .rhosts file might look like

 hv.isp.com cory.gatech.com cc02 cory.gatech.com cr72 

4.5.1 R* Security

The daemons for rsh and rexec have several security features to reduce intrusions.

1. In order for in.rshd, the server that supports rsh and rcp, to consider reading a user's .rhosts file, it ensures that the file is owned by the user and that nobody else has write access to it. Thus, permissions of 600 or 644 are acceptable but not 666.

2. The in.rshd daemon also does a reverse lookup on the numeric IP of the system making the request. This means that it takes the numeric IP address and determines what host name has that address. It requires that this host name matches the one that the requesting system claims to be. This prevents a cracker from issuing the command

    hostname zoro.com 

   With a system in your own domain, you must list it in the .rhosts or hosts.equiv in the same way the reverse lookup shows it (either fully qualified zoro.com or just the first component of the name zoro).

3. Also, it verifies that the source port number is less than 1024, which only root can open on a Linux or UNIX system. The only way that the daemon knows which user on the requesting system is making the request is that rsh runs set-UID to root and determines the real UID of the account invoking it, looks up this UID in /etc/passwd to find the user name, and sends this to the other system.

   In the Linux and UNIX world, only root is allowed to open a port number less than 1024 so the daemon insists that the requesting system be using such a low port number. This might be called the "big system idea." It sounds secure.

4.5.2 R* Insecurity

Security can be broken in a number of ways.

1. The cracker can install a bogus .rhosts. This is a classic case where both the ideas presented in "Understanding Linux Security" on page 18 come into play. The cracker is stuck in a maze of twisty little passages. If she wants to break into joe's account she knows that she needs to find a series of passages that get her to "install a bogus .rhosts file."

   If joe's home directory is writable by all (or can be made so) she might be able to find a suitable file. In older versions of in.rshd it did not care about garbled lines so long as a later line matches the invoking system's name.

   Suppose joe had a mail folder from a security mailing list showing known cracker sites. All a cracker had to do was find any random account to use and mv this mail folder to .rhosts. This random account might be an incorrectly configured FTP anonymous account or a badly written Web server CGI script.

2. If the intruder has root access on the initiating system or it is not Linux or UNIX, the UNIX/Linux security model (that only root can operate from a port number less than 1024) fails. There is another lesson here, which is know the security level of remote systems that you are considering granting access to your system.

3. The intruder can configure his system to pretend to be that of a trusted system, for example, zoro.com, for some techniques for doing this. In many cases this is quite easy.

4. The intruder can compromise the DNS that the server relies on. That DNS may be on a system different from the system serving rsh.

The best solution to rsh is to disable it. The "Host masquerades" cannot adequately be defended against if there are any untrusted systems on the LAN and rsh is at risk for suffering the session being sniffed. SSH was created explicitly to solve these problems. Do have your users make use of it.

Still, if your LAN is secure from internal attacks and sniffing, then TCP Wrappers around in.rshd can be secure. The rcp program allows copying files between systems and operates in much the same way as rsh and it has the same problems and solutions. Have your users use the scp command in the SSH package. It works like rcp but has all of the rock solid security of SSH. The rexec program works like rsh and has similar problems too. The alternative is ssh.

The rlogin program has all of the problems and solutions of rsh and rcp and it has the additional problem that if the client system (the requesting system) is not mentioned in the user's .rhosts file or the /etc/hosts.equiv file on the server system, the invoker will need to supply a password. This password is sent over the network in clear text, allowing a sniffer then to use that password to access that account via rlogin, telnet, ftp, popclient, etc.

The R* services can be disabled by commenting out the lines in /etc/inetd.conf that start

 shell login exec 

The rcp command uses the same remote service as rsh, shell.

---

Top