D. J. Bernstein
Internet publication
FTP: File Transfer Protocol

PASV security and PORT security

FTP is a security disaster, even when it is used with a transparent TCP security mechanism such as IPSEC. I recommend that FTP never be used for anything other than retrieval of public files through PASV.

Unfortunately, as of 1999, FTP remains one of the Internet's most popular file upload mechanisms.

PASV connection theft

After a client sends PASV, an attacker can connect to the server's TCP port before the client does. The severity of this attack depends on what the client does next:

RETR. In this case, the attacker will receive the contents of the file; this is a security violation if the file is not public. Meanwhile, the client will receive an empty file, and will be told by the server that the transfer was successful.
LIST. Similar to RETR.
STOR. In this case, the attacker can replace the legitimate file with data of the attacker's choosing; this is always a security violation. Meanwhile, if the legitimate file fits into the client's TCP buffers, the client will probably not encounter any transmission errors, and will be told by the server that the transfer was successful.

Servers can take several measures to protect against PASV theft:

``PASV IP protection'': Drop the data connection if its IP address does not match the client's IP address. I recommend that all servers do this. However, this does not always stop the attack: the attacker and the client may be using the same multiuser host, or the same multiuser proxy.
``PASV SYN protection'': Arrange to have the operating system reject all SYNs past the first. This stops the attack: the client will not send a transfer request after its connection attempt is rejected. However, most operating systems do not support this feature. (Closing a socket as soon as accept() succeeds is inadequate: the operating system may already have accepted another connection in the background.)
``PASV ACK protection'': Drop the data connection if, at the time of the transfer request, there are two accepted connections on the data connection port. This does not always stop the attack: the client's data connection ACK may be lost or delayed, for example.

Most servers do not have any of these protections, so I recommend that clients avoid all use of FTP to store information or to retrieve private information.

PORT connection theft

After a client sends PORT, an attacker can connect to the client's TCP port before the server does. The severity of this attack depends on what the client does next:

RETR. In this case, the attacker can replace the legitimate file; this is always a security violation. Meanwhile, if the legitimate file fits into the server's TCP buffers, the server will probably not encounter any transmission errors, and will tell the client that the transfer was successful.
LIST. Similar to RETR.
STOR. In this case, the attacker will receive the contents of the file; this is a security violation if the file is not public. Meanwhile, the server will receive an empty file, and will tell the client that the transfer was successful.

Protecting against this attack is even more difficult than protecting against PASV attacks:

The PORT attack does not depend on the client's TCP implementation accepting more than one connection. By the time the server attempts to connect, the client is already reading or writing data.
The attacker may make his own FTP connection to the same server, and have the server make the connection to the targeted port number. It is impossible for the legitimate client to distinguish the resulting connection from a legitimate server connection: it is a legitimate server connection! (Protections against connection laundering, as described below, do not always stop the attack: the attacker and the client may be using the same multiuser host, or the same multiuser proxy.)

I recommend against all use of PORT.

Connection laundering

An attacker can ask an FTP server to make a connection to any port number at any IP address and send a file selected by the attacker.

This is a security hole whenever the server has special authorization to connect to some addresses; it may let the attacker burrow through a firewall, for example, or evade anti-spam IP address checks. The attacker can also thread a connection through many FTP servers, even if none of them have any special authorization, so that he becomes extremely difficult to track down.

RFC 959 exacerbates this problem by requiring that servers make connections from local port 20; connections from low port numbers are often given special privileges. Many servers deliberately disobey this requirement, and make connections from high port numbers instead.

All servers should reject PORT requests that show IP addresses other than the client's address. All servers should also reject PORT requests that show port numbers below 1024. These rules eliminate most, though not all, of the dangerous connection possibilities.

Similar comments apply to clients talking to untrustworthy servers.

Proxy FTP

Once upon a time, all FTP clients used PORT. (At the time, PORT was called SOCK.)

Then PASV was added to support a minor efficiency hack known as third-party FTP or proxy FTP. The client could arrange for one FTP server to transfer files directly to another FTP server, without the client in the middle, by sending PORT to the first server and PASV to the second. RFC 1123, in 1989, required all servers to support PASV, for the sake of proxy FTP.

Of course, from the first server's point of view, proxy FTP is connection laundering. From the second server's point of view, proxy FTP is a file replacement attack.

In early 1995, security-aware servers started to disable connection laundering, restricting PORT to the client's address. ``[This] breaks the concept of "proxy FTP", but hidden somewhere in this paragraph is a very tiny violin,'' said Hobbit, one of the server authors. In 1997, the popular wuftpd server disabled proxy FTP, and CERT recommended upgrading to it for exactly this reason. By 1999, proxy FTP was widely disabled.

Meanwhile, Steve Bellovin had popularized the idea that PASV clients would save time for firewall administrators: a PORT client behind a simple no-incoming-connections firewall will be unable to retrieve files, while a PASV client will work without trouble. By 1999, PASV browsers were extremely widespread, and it became reasonable for server administrators to consider disabling PORT entirely. This is certainly not what the RFC 1123 authors intended!

Which clients use PASV?

In the following list, good means that the client uses PASV by default; mediocre means that the client supports PASV, but you have to go to extra effort to enable PASV; bad means that the client doesn't support PASV.

AIX 4.3 command-line ftp client: Bad.
AnArchie 3.7: Mediocre. Edit the configuration file.
BSD/OS 4.1: Mediocre. -p on the command line.
cftp 0.9.3: Mediocre. passive.
Cobalt Linux 3.0/4.0/5.0 command-line ftp client: Good.
Curl 6.5.2: Good.
Digital UNIX 4.0D command-line ftp client: Bad.
fletch 0.4.6: Mediocre. $FTP_PASSIVE.
FreeBSD 2.2.8/3.3/4.0 command-line ftp client: Good.
ftpcopy: Good.
FTP Explorer: Mediocre. Click on USE PASV.
gFTP 2.0.6a: Good.
GRAB 0.9.2: Mediocre. -m PASV on the command line.
HP-UX 10.20 command-line ftp client: Bad.
Internet Explorer 5 in ``file explorer'' mode: Bad.
Internet Explorer 5 in ``web page'' mode: Good.
IRIX 6.5 command-line ftp client: Bad.
LeechFTP 1.3.1.207: Mediocre. Click on PASV under Firewall.
lftp 2.2.3: Mediocre. Use .lftprc.
Lynx 2.8rel.2: Mediocre. Define NOPORT at compile time.
NcFTP 2.4.3: Mediocre. set ftp-mode 1.
NcFTP 3.0.0b18: Good.
Netscape: Good.
OpenBSD 2.7 command-line ftp client: Good.
Red Hat Linux 5.2 command-line ftp client: Bad.
Red Hat Linux 6.0/6.1 command-line ftp client: Good.
SCO 3.2v5.0.2 command-line ftp client: Bad.
Slackware Linux 3.6 command-line ftp client: Bad.
Solaris 7 command-line ftp client: Bad.
SuSE Linux 6.4 command-line ftp client: Good.
wget 1.5.3: Mediocre. --passive-ftp on the command line.
Windows 98 command-line ftp client: Bad.
Windows NT 4 command-line ftp client: Bad.

Thanks to Chad Dougherty, Brian Edmonds, Edward S. Marshall, Uwe Ohse, and Mikael Olsson for data.