Security Vulnerability between FTP and Berkeley Rsh/Rlogin Protocols

This document was produced for the AusCERT and also sent to CERT and various software vendors. I believe that these agencies have done all that is reasonably possible to address the issue described.

Apart from the need to fix vulnerable systems, I believe that this problem is interesting in that it is caused by an interaction between two services acting exactly according to their specifications and not due to bugs in implementation.

Information on vulnerable versions has been removed from this document.

1. The Problem

There is an interaction between the operation of FTP servers and the authentication mechanism of the Berkeley 'r' command set (rsh and rlogin) that can permit users to access accounts to which they are not authorised, either on the local system or on other systems that trust the local system. Combined with poor operation of anonymous FTP service, this vulnerability can permit access by outside users.

This problem is unfortunately not actually a bug, but an interaction between two services behaving according to specification, but with conflicting assumptions.

Note that not all FTP or rsh/rlogin servers are affected. (See section 2.)

1.1. Use and Misuse of the FTP PORT command.

FTP operates by permitting an FTP client to issue file transfer commands to an FTP server, listening on TCP port 21. Actual file transfer involves the client instructing the server of an IP address and port number to use, which the client then listens on. The client then instructs the server to transfer the file, at which point the server then opens a TCP connection to the client's address and port, with a source (server end) port number of 20. The operation is as follows:

      (client establishes connection from local port 1024 to 
       server port 21)
      (client listens on port 1025 (4,1))
    client:1024 -> server:21                    PORT c,li,e,nt,4,1
    client:1024 <- server:21                    200 PORT command successful
    client:1024 -> server:21                    RETR file
    client:1024 <- server:21                    150 Opening ASCII mode ...
    client:1025 <- server:20                    <data for 'file'>
    client:1024 <- server:21                    226 Transfer complete

FTP servers also permit third-party transfers (implemented by very few FTP clients, although most will let you send the necessary commands manually); this is the reason for including the host address. To transfer a file 'file' from server1 to server2, the trialogue would be:

      (client establishes connection from local port 1026 to 
       server1 port 21)
      (client establishes connection from local port 1027 to 
       server2 port 21)
    client:1026 -> server1:21                   PASV
      (server1 listens on port 2049)
    client:1026 <- server1:21                   227 Passive (se,rv,er,1,8,1)
    client:1027                 -> server2:21   PORT se,rv,er,1,8,1
    client:1027                 <- server2:21   200 PORT command successful
    client:1026 -> server1:21                   STOR file
    client:1026 <- server1:21                   150 Opening ASCII mode ...
    client:1027                 -> server2:21   RETR file
    client:1027                 <- server2:21   150 Opening ASCII mode ...
                   server1:2049 <- server2:20   <data for 'file'>
    client:1026 <- server1:21                   226 Transfer complete
    client:1027                 <- server2:21   226 Transfer complete

To permit this operation, the PORT command must accept arbitrary IP addresses and ports. This opens up the possibility of bogus PORT commands being issued so that files can be sent into any other host/port combination that the FTP server can reach. This in itself has many security implications, particularly where the FTP server is inside a firewall, since connections can be made to otherwise protected systems.

(Many modern FTP clients use the PASV command to allow the FTP server to pick the port to be used in normal client<->server file transfer; universal acceptance of this mechanism and deprecation of the PORT command would make this document unnecessary.)

1.2. Use and Misuse of the Berkeley Rsh/Rlogin Services

"rlogin" is a simple TCP/IP interactive login program that connects to a server on a remote system that in turn allows an interactive login onto that system, much like Telnet, but is a much lighter weight protocol.

"rsh" is similar in operation, but instead of controlling a pseudo-terminal to emulate a terminal session, simply submits a shell command to the remote system for execution, passing input and output via the calling TCP stream.

Rsh operates as follows:

      (Client attempts to assign a local port <1024, eg 1023)
    client:1023 --> server:514          <connects>
    client:1023 --> server:514          <nul>luser<nul>ruser<nul>cmd<nul>
    client:1023 <-- server:514          <nul>
    client:1023 <-> server:514          <data>

(Rsh also permits the client to send a port number prior to the first <nul> for the server to send error messages to the client (stderr in Unix parlance), but this is option and largely irrelevant to the discussion.)

Rlogin operates the same way, but the port number is 513 rather than 514, and "cmd" is replaced by <terminal>/<speed>, eg "vt100/9600", and the data is terminal formatted data, where rsh is typically sending Unix-style input (normally LF-delimited lines of text, although this is by no means compulsory).

In the example above, "luser" is the user-id the client is being run from, and "ruser" is the user-id to run under on the server. "cmd" (for rsh only -- see above for rlogin) is the command to execute.

Authentication is normally done by checking the files hosts.equiv (in /etc under unix), and then by looking for a file called .rhosts in the ruser's home directory. These files specify hosts that can be trusted to make such a connection; if the host is not mentioned, or the luser field does not match the trusted user on the client system (by default the same as the user on the server, but overridable), the connection is rejected. (For rlogin, the connection continues, but the user must supply a password to log in.)

To ensure that users can not connect to the rsh ports themselves and just put any luser and ruser fields in, the rlogin & rsh daemons reject any attempt to connect to them using source ports of greater than 1023. Most systems require system privilege to access such ports, requiring that rsh/rlogin clients be installed with such privilege.

Clearly this requires that the client system be trusted by the server system not to hand out either access to the "privileged" ports or sufficient privilege to access them. Many security problems occur or are compounded when that assumption of trust breaks down.

1.3. Interaction between FTP and rsh/rlogin

The upshot of all this is simple. Multi-user system users normally are not permitted to create TCP channels with source ports <1024. Rsh/rlogin use this assumption to protect themselves from bogus authentication information. FTP breaks that assumption by providing the user with access to such a source port. An example follows:

The following assumptions are made. System rshd's user "foo" trusts system ftp's user bar. The attacker has already managed to insert the file "attack.txt" on system ftp, under an account (possibly "anonymous") that they can access using FTP. They are using that account as we pick up the story. "attack.txt" contains the following data:

    <nul>bar<nul>foo<nul>rm *<nul>

The FTP/rsh transaction is as follows:

    client:1028 -> ftp:21              PORT r,s,h,d,2,2
    client:1028 <- ftp:21              200 PORT command successful
    client:1028 -> ftp:21              RETR attack.txt
    client:1028 <- ftp:21              150 Opening ASCII mode ...
                   ftp:20 -> rshd:514  <nul>bar<nul>foo<nul>rm *<nul>
                   ftp:20 <- rshd:514  <nul>
    client:1028 <- ftp:21              226 Transfer complete

and now foo@rshd no longer has any files as the command "rm *" is executed under that account. Less wontonly destructive and more interesting attacks are left to the reader's imagination.

1.4 Compounding the Problem

The attack above relies on lines of trust being defined either in hosts.equiv or .rhosts files. Unfortunately, many systems "help" the users by permitting all access from the local host.

Therefore, assuming the system has such a file, and neither the rsh nor ftp servers provide any explicit defence against these attacks, then any user on that system can get into any other user's account.

2. Finding and Fixing the Problem

While this problem exists in the standards, some systems already protect against it. Rsh/rlogin servers can refuse to play with port 20. FTP servers can refuse to connect to the rsh/rlogin ports.

2.1. Rsh/Rlogin Implementations

This problem was noticed in early BSD systems and quietly fixed. As well as rejecting connects from ports >1023, rlogind & rshd reject all attempts to connect from ports <512. Therefore, any system where rshd and rlogind are based on the original BSD code is not vulnerable.

Systems which are vulnerable are those where the rlogin & rsh servers do not share the common code base (or have been "fixed" to permit connects from ports <512, although I have seen no evidence that this has happened). This includes many non-Unix implementations, and many System V based systems.

2.2. FTP Implementations

FTP servers can do two things to prevent this sort of misuse:

3. Ducking the Problem

There are several things that can be done without fixing the software involved. Some of these involve installing new software.

3.1. Don't trust FTP

The simplest defense therefore is to place the FTP server outside a firewall, which in turn does not permit rsh/rlogin through it to inside systems. Inside systems in turn should not permit FTP from untrusted sources.

3.2. Turn off rlogin/rsh

Where no firewall exists, the options are more limited. Simply turning off rsh/rlogin will solve it, but if rsh/rlogin are used extensively they must be replaced. SSH (Secure SHell) is a good drop-in replacement which uses cryptographic mechanisms rather than IP addresses to do its authentication.

3.3. Turn off FTP

Alternatively, FTP can be turned off. FTP has two major classes of user; unauthenticated remote users accessing public data, and local authenticated users transferring files.

For the first class, consider placing publicly available files on an HTTP server. HTTP is rapidly overtaking FTP in popularity, and for the most part provides equivalent functionality.

For the second class, rcp can be used (assuming rsh is turned on), or scp, part of the SSH package. The latter is recommended. Unfortunately, neither of these, nor various file-sharing mechanisms, provide the kind of ad-hoc access that FTP provides, eg to access files from remote sites. Mailing MIME-encoded files can help.

Don Stokes
6 February 1997