The rlogin Family of Protocols

The rlogin protocol, originally used with Unix-to-Unix terminal sessions, uses end-to-end mutual trust to avoid the transmission of any form of password. The protocol requires that the server trust the client to authenticate the user. The user places a file on the server indicating what combinations of username and hostname may connect to a particular account on machines using the server. The user may connect from these without presenting any further credentials such as a password.

The user must trust that the server is sufficiently secure, that no one else can alter the rhosts file and that no one else can read the rhosts file. The requirement that the rhosts file not be altered is obvious—if someone modified the rhosts file, he or she could connect to the account via the rlogin protocol without the permission of the legitimate user. The requirement that no one else can read the rhosts file is a bit more obscure, but learned from painful experience. If an attacker gains access to another account on the machine hosting the rlogin server, the attacker can read the rhosts file of a user and target the user for an indirect attack. In an indirect attack, the attacker attempts to gain access to an account listed in the rhosts file on another machine and use it to obtain access to the machine hosting the rlogin server.

Another file used by some servers for the rlogin protocol is called the host equivalence file, which is named “/etc/hosts.equiv” in the original Unix implementation. Any user of any host listed in the host equivalence file may access an account with the same username on the machine on which the host equivalence file exists without presenting a password. The use of a host equivalence file adds convenience for the user by relieving individual users from the need to create their own rhosts file. However, it opens up users to the risks of ARP spoofing and name server spoofing (both covered later in this chapter) without the implicit consent they give to that risk when creating their own rhosts file. System administrators are strongly urged not to use a host equivalence file because of those risks. Users without the network savvy to create an rhosts file are being put at risk from a threat they have no possibility of understanding.

The rlogin protocol remains vulnerable to ARP spoofing and DNS spoofing

It also does not completely protect a user who uses machines that he or she does not control. For example, when you start an rlogin terminal session from a client’s or colleague’s office, the client’s or colleague’s machine is not listed in your rhosts. In these cases, you must remember my password and have it transmitted across the network in plain sight of any sniffers that may be out there.

Problems with rlogin

As mentioned earlier, on a machine with any server for programs in the rlogin protocol family it is critical that only the user can modify his or her rhosts file. If it is possible for someone else to modify it then the ability to modify it can be leveraged into the ability to obtain full access to the account. Note that if your home directory is on an NFS mounted file system exported to someone else’s machine your rhosts file is vulnerable to simple attacks on NFS. A standard attack for the superuser of another machine is to give you an account on the other machine and then use the su command to gain access to your account on the other machine. The NFS server is fooled into believing you are accessing your files because it trusts the other machine to authenticate its users. So far, the attacker is limited to accessing your files, but when he alters your rhosts file the attacker can begin to run programs that execute with your privileges and do greater harm.

If an attacker is able to modify the superuser rlogin file or gain access to any account listed in it, such access can be leveraged into a very serious attack. In particular, an attacker can use rsh to subvert the requirement that Unix superuser logins occur from secure terminals. Unlike rlogin or telnet, rsh does not require a pseudo-tty. If protection of your superuser login account involves restricting insecure terminals, you may want to disable or alter the rsh program.

Do not confuse the rexec commands (rexec and rcmd) with the r-commands. The rexec daemon waits for a username and cleartext password to authenticate a client. It will then execute a single shell command. Although this is similar to rsh, rexec requires the transmission of a cleartext password to be sniffed. Also, it provides two distinct error conditions, one for an invalid username and one for an invalid password. Hence, a brute-force attack can be mounted by attempting all possible usernames to both determine what usernames are valid and which users have no password. A standard login program will not provide this distinction and provide a mechanism to prevent rapid-fire attempts to log in. Security conscious system administrators often disable the rexec daemon and rexec commands are so seldom known about by users as not to be missed.