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:

Servers can take several measures to protect against PASV theft:

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:

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

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. Thanks to Chad Dougherty, Brian Edmonds, Edward S. Marshall, Uwe Ohse, and Mikael Olsson for data.