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.
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.)
(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.)
"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.
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:
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.
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.
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.
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.
There are several things that can be done without fixing the software involved. Some of these involve installing new software.
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.
6 February 1997