PASV security

FTP can prove to be a security disaster, even when it is used with a transparent TCP security mechanism such as IPSEC. It is highly recommended that FTP never be used for anything other than retrieval of public files through PASV.

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

PASV connection theft can occur relatively simply (Please do not try this at home!!):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.