Vulnerability Note VU#328867

Multiple vendors' firewalls do not adequately keep state of FTP traffic

Original Release date: 08 Oct 2002 | Last revised: 07 Mar 2003


Firewalls and other systems that inspect FTP application layer traffic may not adequately maintain the state of FTP commands and responses. As a result, an attacker could establish arbitrary TCP connections to FTP servers or clients located behind a vulnerable firewall.


Many firewalls perform stateful inspection of application layer traffic, allowing them to support passive FTP and other applications that make connections using dynamically chosen ports. In the case of a passive FTP connection to an FTP server located behind a firewall, the firewall examines the application layer of the FTP control channel and interprets FTP commands and responses in order to determine what TCP ports the server is using for data connections. When a client requests a passive FTP connection by issuing the PASV command, the FTP server responds positively with a string like "227 Entering Passive Mode h1,h2,h3,h4,p1,p2", instructing the client to initiate a TCP connection to IP address h1,h2,h3,h4 on port p1,p2. The firewall monitors this string and creates a dynamic rule allowing an inbound TCP connection from the client to the server on the specified port.

Some firewalls create dynamic rules without assuring that the PASV response string is part of a legitimate FTP connection.

An attacker who is able to log in to an FTP server behind a vulnerable firewall issues an FTP command that echoes the argument of the command back to the attacker (NLST is one example of such a command). The attacker includes a PASV response string as the argument to the command, so that the PASV response "227 Entering Passive Mode h1,h2,h3,h4,p1,p2" is echoed back through the firewall. Using a spoofed IP address and a separate TCP/IP stack (libnet and libpcap), the attacker sends specially crafted TCP packets that acknowledge (ACK) the echoed response from the FTP server up to the start of the PASV response. If the operating system used by the FTP server supports the partial acknowledgement of TCP data segments (RFC 2581), it will resend the unacknowledged data, starting with the beginning of the PASV response. A vulnerable firewall will see a properly terminated PASV response at the start of a packet and create a rule allowing the client to connect to the specified port on the FTP server.

This behavior has been previously discussed in public forums (February 2000):

In the February 2000 discussion, a number of similar techniques are mentioned:
  • using a URL with a properly padded FTP command (HTML email or web page with hostile URL sent to clients)
  • using other FTP commands (STAT) to echo PORT commands or PASV responses back through the firewall
  • using TCP MSS to control/lower the size of a TCP packet and properly align FTP commands and responses
  • uploading a file or creating a directory with a crafted name that contains FTP commands, then using "ls" or similar to echo the command back through the firewall
These techniques, including the use of partial acknowledgement as described above, might also be used with the PORT command by a malicious FTP server to open connections to active FTP clients that are behind a vulnerable firewall.

It is possible that similar vulnerabilities exist in the way firewalls handle other applications that use dynamic ports. FTP application layer gateways and proxy servers may also be affected.

An FTP server or FTP client running on an operating system that does not accept partial acknowledgement of TCP data segments is not susceptible to this specific attack.

FTP servers that do not pad 3-digit numbers within multi-line responses exacerbate this problem by making it difficult for firewalls to recognize legitimate FTP status codes (VU#288905). From section 4.2 of RFC 959:
    If an intermediary line begins with a 3-digit number, the Server must pad the front to avoid confusion.

    In rare cases where these routines are able to generate three digits and a Space at the beginning of any line, the beginning of each text line should be offset by some neutral text, like Space.


A remote attacker may be able to access TCP ports on an FTP server or client that is behind a vulnerable firewall system, which could expose other network services to attack.


Apply Patch or Upgrade
Apply the appropriate patch or upgrade as specified by your vendor.

Disable FTP Inspection

In some products it may be possible to disable the FTP application layer inspection feature, however this will most likely prevent passive FTP sessions from reaching an FTP server located behind a firewall, and may prevent active FTP sessions that originate from clients who are behind a firewall.

Restrict Access

Do not allow anonymous access to FTP servers from untrusted networks like the Internet. Note that this will only limit the number of potential sources of attacks; it will not prevent attacks from networks that are allowed to access the FTP servers.

Disable Active FTP

Do not allow untrusted FTP servers to initiate connections to FTP clients. This will prevent clients from using active FTP for data channel connections.

Secure FTP Servers

Keep exposed FTP servers up-to-date with the latest patches and disable all unnecessary services.

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
IP FilterAffected-16 Oct 2002
NetBSDAffected-11 Nov 2002
WatchGuardAffected-10 Oct 2002
AlcatelNot Affected23 Jul 200208 Oct 2002
Apple Computer Inc.Not Affected23 Jul 200208 Oct 2002
AvayaNot Affected26 Sep 200205 Mar 2003
BorderwareNot Affected-15 Oct 2002
Check PointNot Affected08 Aug 200227 Aug 2002
Cisco Systems Inc.Not Affected23 Jul 200210 Oct 2002
ClavisterNot Affected-14 Oct 2002
Cray Inc. Not Affected23 Jul 200208 Oct 2002
eSoftNot Affected-09 Oct 2002
Global Technology AssociatesNot Affected-16 Oct 2002
GNU netfilterNot Affected-14 Oct 2002
Hewlett-Packard CompanyNot Affected23 Jul 200216 Oct 2002
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A



The CERT/CC thanks Mikael Olsson of Clavister AB and Al Potter of ICSA Labs for reporting this vulnerability and providing information used in this document.

This document was written by Art Manion.

Other Information

  • CVE IDs: Unknown
  • Date Public: 07 Oct 2002
  • Date First Published: 08 Oct 2002
  • Date Last Updated: 07 Mar 2003
  • Severity Metric: 24.10
  • Document Revision: 74


If you have feedback, comments, or additional information about this vulnerability, please send us email.