hosts.equiv Username Problem

If a username was specified in the hosts.equiv file, in addition to the hostname, that user on that remote host could specify the username of any user on the system and gain access. For example, if the system george had an /etc/hosts.equiv that contained the line halifax julie, the user julie on the remote system halifax could gain access as any user on system george. This was caused by the ruserok() libc routine, which tried to leverage the code from the .rhosts check using a goto call.

SSL httpd Randomization Problem

The Netscape Navigator implementation of SSL had a flaw of using a predictable random number generator. (SSL stands for Secure Sockets Layer, a protocol that permits authentication and encryption—the implementations of this protocol involve the use of a library of routines that permit a nearly drop-in replacement of standard socket calls. SSL is more fully explained later in this chapter in the section “SSL.”) So, even though the encryption used IDEA, RC4-120, or Triple-DES, in which the key size is over 120 bits, the key was generated with a random number chosen from a 16- to 32-bit space. A brute force search of all possible random numbers could quickly find the chosen value and therefore find the session key. The problem with session keys is that they depend on good random numbers, and no computer can currently easily create a good random number. This is a weakness for all cryptographic systems. RFC 1750, Randomness Requirements for Security, attempts to address this issue. Interestingly, Netscape offered their implementation to public review via the Internet (ftp://ftp2.netscape.com/pub/review/RNGsrc.tar.Z) to try to strengthen the randomness of the algorithm.

TCP Sequence Guessing Problem

Even though a system has turned off support for the IP source routing option, an intruder can fool that system into believing that it is communicating with a trusted host. The intruder first initiates a TCP connection to the target system using a true IP address, then exits the connection. The intruder now initiates a new connection using the IP address of a trusted system. For example, the target has a hosts.equiv file that indicates host B to be trusted. The intruder makes connection to the remshd port (shell 512/TCP) with the IP address of the trusted system. To carry on the masquerade, the intruder needs to acknowledge (ACK) each TCP packet from the target. Because the algorithm for choosing the next sequence number for a new TCP connection was predictable, the intruder could easily guess it. So, when the target system sent the response packet to the real trusted system, which discarded it because no active listener was available, the intruder quickly sent back the appropriate acknowledge packet to complete the TCP connection. The intruder would then gain access through the rcmds and the hosts.equiv trust by hostname mechanism.

The solution to this problem is to make the sequencing between new TCP connections more difficult to guess, by randomizing it. Although this does not prevent an intruder from guessing it, it does make guessing much more difficult. Most intruders do not have direct access to the physical network via a sniffer, so they cannot hijack existing connections using this mechanism. If they do have physical access, hijacking of existing connections can be done. For a deeper analysis, see the paper by Bellovin (Bellovin, 1993).

ftpd Server Bounce Problem

The proxy server feature of ftpd was created to permit third-party transfers of files. A user can request a proxy transfer from one ftpd to another remote ftpd. This feature, actually specified in the RFC requirements, when combined with the quote command, the PORT statement, and the PASV statement, permits a user to avoid IP access controls and traceability.

The core of the problem is that a user can request a remote ftpd server to send a file to any IP address and TCP port. So, the user could request the remote ftpd to send a file containing valid network protocol commands to a server program listening on any TCP port on any host, causing that server to believe that the source of the network protocol connection is the remote ftpd.

Imagine, for example, that a user in France wants to FTP a file from MIT that is available only to U.S. users. The MIT ftpd screens out IP addresses from outside the U.S., in an attempt to comply with U.S. export restrictions of cryptographic material. The French user connects to another U.S. ftpd and logs in as an anonymous user. The French user ftps to her own machine and puts it into a PASV mode, then does a STOR of a new file, say foobar. The French user now anonymously sends a text file containing FTP protocol statements to the U.S. ftpd. These statements include a PORT command with the IP address and port number of the French ftpd that is doing a passive listen and STOR, as well as a subsequent RETR to retrieve the desired file.

The French user now specifies a quote PORT command to the U.S. ftpd that indicates the FTP control port (21) on the MIT machine. Finally, the French user specifies a quote RETR command to the U.S. ftpd for the text file containing the command statements. The U.S. ftpd sends this file containing the port address of the waiting French ftpd in a PORT command, along with the appropriate commands for getting the desired files, to the MIT machine, which approves the U.S. IP address and sends the file to the French ftpd, which is still waiting with the STOR command to retrieve the file called foobar. The MIT file is therefore sent to the French ftpd and stored as foobar on that site, whereas the MIT ftpd logs indicate that the file was sent to the U.S. ftpd.

This same approach could be used to send protocol packets to any port on any system through the bouncing ftpd, thereby hiding the true IP address of the originating sender. Completely untraceable e-mail or Usenet news postings could be done this way, which would be a benign use of this hole. A malicious user would be able to completely fool any IP address restrictions on a target system.

The only way to avoid this is to turn off proxy functionality completely. See the paper at ftp://avian.org/random/ftp-attack for full details on this hole and the suggested fix to ftpd.