CERT/CC Vulnerability Note VU#328867

Overview

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.

Description

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.

Impact

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.

Solution

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.

Vendor Information

328867

Filter by status:

Filter by content: Additional information available

Sort by:

Expand all

IP Filter Affected

Updated: October 16, 2002

Status

Affected

Vendor Statement

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

IPFilter FTP update.
====================

Synopsis: In kernel FTP proxy allows access to other ports on FTP server.

Versions affected: All prior to 3.4.29

Affected use: proxying to ftp servers.

Recommended Action: Upgrade to 3.4.29 if running a version prior and
using proxy function to provide FTP server access.
Details.
- --------
It is possible to fool the ftp proxy in earlier versions of IPFilter
into thinking that retransmitted text from the ftp server (or client)
is a new response and should be processed as such.

For people using the inbuilt proxy in the kernel to provide access to
ftp servers, this can be used to open up access to any port on the ftp
server. For this to be a problem, your ftp server must respond in a
manner that essentially echoes, verbatim, text sent to it on the end
of a line. See below for a list of known good/bad FTP daemons. If
yours isn't known to be good or bad then you are best assuming that
it is bad.

Monitoring.
- -----------
If you cannot upgrade immediately, or would otherwise like to make sure
you can "keep tabs" on this problem, despite the state/nat table entries
not being created by a rule, they can still be logged. If you are using
ipmon to record all log transactions (-a), its output will include NAT &
state table entries created to enable the rogue connection through. If
you are not collecting log information on NAT or state transactions, you
can enable this by adding "-a" to ipmon's command line options at startup
or optionally, record this information to a separate file (with a
recommended separate .pid file) like this:

ipmon -P /var/run/ipmon-extra.pid -o NS /var/log/ipfnatstate

Workarounds.
- ------------
If you cannot upgrade IPFilter, you are advised to examine how your FTP
server software behaves. Known safe FTP server software, in this regard
are:

+ ftpd in Sun Solaris/SunOS
+ ftpd in FreeBSD (upto and including 4.5)
+ ftpd in OpenBSD (upto and including 3.1)
+ wsftpd

FTP server software that is known to support this attack:

+ proftpd
+ warftpd
+ serv-u
+ pureftpd
+ publicfile
+ ftpd in NetBSD (upto and including 1.6)

Another safe work around is to use a user space ftp proxy, such as that
provided with the Firewall Toolkit. Discussion on how to do this is
beyond the scope of this document.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (SunOS)

iD8DBQE9qaNYP7JIXtvLbFURAuB2AKCKJ0gWwEX3SnYMq/ZlEt8JcRABhACeJkvp
XRz08wWGODquWd6u3dJv7Zk=
=UuHZ
-----END PGP SIGNATURE-----

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

IP Filter (ipf) is included with FreeBSD and NetBSD, although ipfw is the somewhat more default firewall for FreeBSD. Please see:

OpenBSD vendor statement

NetBSD vendor statement

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

NetBSD Affected

WatchGuard Affected

Alcatel Not Affected

Apple Computer Inc. Not Affected

Avaya Not Affected

Borderware Not Affected

Check Point Not Affected

Cisco Systems Inc. Not Affected

Clavister Not Affected

Cray Inc. Not Affected

GNU netfilter Not Affected

Global Technology Associates Not Affected

Hewlett-Packard Company Not Affected

IBM Not Affected

Intoto Not Affected

Microsoft Corporation Not Affected

NEC Corporation Not Affected

NetScreen Not Affected

Nortel Networks Not Affected

OpenBSD Not Affected

Notified: July 23, 2002 Updated: October 16, 2002

Status

Not Affected

Vendor Statement

This says OpenBSD, but should not. The problem is in ipf. We told our users for years and years to not use the ipf ftp proxy. That said, we do not have ipf anymore. We've got our own packet filter, pf, which has a userland side proxy agent which is not vulnerable to this at all.

I didn't install an ipf machine, but from looking at the code, I'm pretty sure it's vulnerable to this attack. So I guess the vendor statement could mention that and urge people to upgrade from pre-3.0 versions :) pf is not vulnerable, since it's not aware of the FTP protocol. ftp-proxy is used only for FTP clients behind the firewall. Even if you're running the reverse-ftp-proxy patch (for servers behind pf), it's not vulnerable, since it can't modify pf rules.

OpenBSD >=3.0 uses pf, these notes do not apply to OpenBSD up to 2.9 which used ipf.

In the presence of fragments, it is impossible to fully check the transport checksum without full reassembly (which is also susceptible to a memory resource attack). The OpenBSD PF firewall includes a variety of mechanisms that each can minimize the exposure to not only this attack but a variety of resource starvation attacks:

The use of the normalizer via a SCRUB rule can resolve many ambiguities in the traffic stream. The normalized traffic results in the identical interpretation of the packet from the end host and the firewall.

A dynamically resizeable state table which can be tuned during runtime (within the constraints of kernel memory). ipf, which was included up to OpenBSD 2.9, was vulnerable to this attack.

A choice of several predefined state optimization levels. By enabling the 'Aggressive' state optimization, idle states will be removed from the state table at a much higher rate.

Run-time control over individual timeouts. The administrator can reduce the 'tcp.first' and the 'udp.first' timeouts to as low as her environment deems acceptable (reducing it below 30s may result in additional log entries as valid connections will start to be expired before the reception of the SYN-ACK).

The upcoming OpenBSD 3.2 supports the specification of individual timeouts and the limitation of the quantity of states on a per rule granularity. Thus the administrator can limit her overall exposure to a resource starvation attack down to other connections which match the same rule as the attack.

connection tracking can be enabled or disabled on a per-rule basis, and thus is of course disableable (sp?) completely, too.

For ftp, we have an userland ftp-proxy(8) daemon that is not vulnerable to any of these attacks for the obvious reasons. ipf, which was included up to OpenBSD 2.9, contains a in-kernel ftp proxy which is significantly flawed in this way. However, we did not compile that into the default system because we considered it so flawed.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Versions of OpenBSD prior to 3.0 included IP Filter. See also:

IP Filter vendor statement

NetBSD vendor statement

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

Secure Computing Corporation Not Affected

SecureWorx Not Affected

Stonesoft Not Affected

Sun Microsystems Inc. Not Affected

Symantec Not Affected

eSoft Not Affected

3Com Unknown

FreeBSD Unknown

ZyXEL Unknown

View all 30 vendors View less vendors

CVSS Metrics

Group	Score	Vector
Base
Temporal
Environmental

References

Acknowledgements

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:	None
Severity Metric:	24.10
Date Public:	2002-10-07
Date First Published:	2002-10-08
Date Last Updated:	2003-03-07 21:59 UTC
Document Revision:	74

Software Engineering Institute

CERT Coordination Center

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

Vulnerability Note VU#328867

Overview

Description

Impact

Solution

Vendor Information

IP Filter Affected

NetBSD Affected

WatchGuard Affected

Alcatel Not Affected

Apple Computer Inc. Not Affected

Avaya Not Affected

Borderware Not Affected

Check Point Not Affected

Cisco Systems Inc. Not Affected

Clavister Not Affected

Cray Inc. Not Affected

GNU netfilter Not Affected

Global Technology Associates Not Affected

Hewlett-Packard Company Not Affected

IBM Not Affected

Intoto Not Affected

Microsoft Corporation Not Affected

NEC Corporation Not Affected

NetScreen Not Affected

Nortel Networks Not Affected

OpenBSD Not Affected

Secure Computing Corporation Not Affected

SecureWorx Not Affected

Stonesoft Not Affected

Sun Microsystems Inc. Not Affected

Symantec Not Affected

eSoft Not Affected

3Com Unknown

FreeBSD Unknown