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

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):

* <http://online.securityfocus.com/archive/1/47688/2000-02-12/2000-02-18/1>
* <http://online.securityfocus.com/archive/82/45571/2000-02-08/2000-02-14/1>
* <http://online.securityfocus.com/archive/82/45758/2000-02-08/2000-02-14/1>

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: All Affected Not Affected Unknown

Filter by content: __ Additional information available

__ Sort by: Status Alphabetical

Expand all

Javascript is disabled. Click here to view vendors.

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](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

NetBSD __ Affected

Updated: November 11, 2002

Status

Affected

Vendor Statement

I’ve done some more testing of the proxy and have come to the conclusion that whilst the proxy in ipfilter currently shipped may be vulnerable to the attack described by cert, I don’t have an FTP daemon which responds in a manner that makes the attack possible. I’ve tested against Solaris, SunOS4 and NetBSD. The proxy in 3.4.29 drops the packets that cause the problem with this exploit.

I’ve tested IPFilter 3.4.27 (same as in -current and is scheduled for 1.6). Whilst this version does allow the sel-ack’d 227 back through, it does not appear to create the necessary state/nat sessions to allow the second data connection through.

In short, IPFilter 3.4.27 does not appear to be vulnerable to this exploit. It may be possible to write others which are, but the FTP proxy in IPFilter will progressively become stricter in what it allows, further narrowing opportunities to exploit it in this kind of manner (as can already be seen with 3.4.29.)

[Darren Reed]

Vendor Information

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

Addendum

NetBSD includes IP Filter. Please see:

* NetBSD Security Advisory 2002-024:



* OpenBSD vendor statement:



* IP Filter vendor statement:

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

WatchGuard __ Affected

Updated: October 10, 2002

Status

Affected

Vendor Statement

After analyzing the FTP issue described in VU#3328867, WatchGuard’s Rapid Response team found that WatchGuard’s Firebox Model II and III families of products are not affected. However, WatchGuard SOHO products running firmware v5.1.6 and earlier, as well as WatchGuard Vclass/RSSA products using v3.2 SP1 and earlier, are susceptible to this type of attack. WatchGuard has released patches for both the Vclass and SOHO products to correct this vulnerability.

* For WatchGuard SOHO Users: SOHO firmware v5.1.7 and SOHO 6 firmware v6.0.14, both released in September, correct this FTP vulnerability. Registered LiveSecurity users can download these firmware upgrades from our [LiveSecurity Web site](<https://www3.watchguard.com/archive/softwarecenter.asp>).
* For WatchGuard Vclass and Legacy RSSA Users: Hotfix 1 for WatchGuard Vclass v3.2 SP1, released in July, corrects this vulnerability. However, we recommend Vclass and Legacy RSSA users download the Hotfix 2 to correct this issue (Hotfixes are cumulative). Registered LiveSecurity users can download this firmware upgrade from our [LiveSecurity Web site](<https://www3.watchguard.com/archive/softwarecenter.asp>). Legacy RSSA users should obtain Hotfix 2 from our [Legacy RSSA software download center](<http://watchguard.com/vars/rssa.asp>). 

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Alcatel __ Not Affected

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

Status

Not Affected

Vendor Statement

In relation to this vulnerability on FTP traffic handling, Alcatel has conducted an immediate assessment to determine any impact this may have on our portfolio. A first analysis has shown that Alcatel products, in particular the OmniAccess 200-series, are not affected. Customers who make use of third-party vendor firewall solutions should check with that vendor. Customers may contact their Alcatel support representative for more details. The security of our customers’ networks is of highest priority for Alcatel. Therefore we continue to test our product portfolio against these potential security vulnerabilities in our products and will provide updates if necessary.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Apple Computer Inc. __ Not Affected

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

Status

Not Affected

Vendor Statement

Mac OS X and Mac OS X Server do not contain the vulnerabilities described in this report.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Avaya Not Affected

Notified: September 26, 2002 Updated: March 05, 2003

Status

Not Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Borderware __ Not Affected

Updated: October 15, 2002

Status

Not Affected

Vendor Statement

Our investigations have determined that no BorderWare products are susceptible to the type of attack described in VU#328867.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Check Point __ Not Affected

Notified: August 08, 2002 Updated: August 27, 2002

Status

Not Affected

Vendor Statement

We have reviewed the issues raised in VU#3328867. Check Point engineering, after analyzing the information, has concluded that our currently shipping versions, both 4.1 and NG are not vulnerable to this attack. When we fixed the original stateful inspection FTP attack in February of 2000, it addressed this derivative as well.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Cisco Systems Inc. __ Not Affected

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

Status

Not Affected

Vendor Statement

Cisco has confirmed that their products are not affected by VU#328867.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Clavister __ Not Affected

Updated: October 14, 2002

Status

Not Affected

Vendor Statement

Clavister Firewall: Not vulnerable.

This finding was an extended result of our initial work in early 2000 to determine if the command channel of protocols using ephemeral data channels could be safely analyzed without fully reassembling the TCP stream. Our conclusion then was that it is not. There were, and are simply too many hard-to-predict attack vectors.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Cray Inc. __ Not Affected

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

Status

Not Affected

Vendor Statement

Cray, Inc. is not vulnerable as we provide no software that performs this type of function.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

GNU netfilter __ Not Affected

Updated: October 14, 2002

Status

Not Affected

Vendor Statement

The netfilter core team “can positively confirm that we are not affected.”

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Global Technology Associates __ Not Affected

Updated: October 16, 2002

Status

Not Affected

Vendor Statement

Global Technology Associates, Inc. has examined this issue and is pleased to report this issue does not impact any versions (current and past) of the GTA firewall products.

Products Not Vulnerable:

GB-1000 Firewall/VPN Appliance
GB-100 Firewall Appliance
GB-Flash Firewall
RoBoX Firewall Appliance
GB-Pro Firewall System
GNAT Box Light Firewall System

To report potential security vulnerabilities in GTA products, send an E-mail message to: [email protected].

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Hewlett-Packard Company __ Not Affected

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

Status

Not Affected

Vendor Statement

SOURCE: Hewlett-Packard Company and Compaq Computer Corporation, a wholly-owned subsidiary of Hewlett-Packard Company

RE: x-reference SSRT2343

Not Vulnerable:

HP-UX
HP-MPE/ix
HP Tru64 UNIX
HP NonStop Servers
HP OpenVMS

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

IBM __ Not Affected

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

Status

Not Affected

Vendor Statement

The vulnerability that is being referred, is for the firewalls that monitor the application layer data and open the ports. In IBM Firewall’s Dynamic PASV ftp, the filter rules for data connections are activated dynamically by monitoring the ftp control connection. The activation of these rules is state based, where in the filter rule needed for a data connection is opened only after the “PASV ----> 227…” handshake completes between the end points. That is, firewall considers “227 …” reply to a ftp client as valid, only after the corresponding “PASV” command from that ftp client is observed. So, I think IBM-SecureWay firewall is not vulnerable to the attack being referred.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Intoto __ Not Affected

Updated: October 09, 2002

Status

Not Affected

Vendor Statement

iGateway firewall’s TCP re-transmission engine does not let partially acknowledged TCP segment’s re-transmissions pass through the firewall, which is a root cause of this vulnerability. This design philosophy makes iGateway firewall withstand these kinds of TCP re-transmission attacks.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Microsoft Corporation __ Not Affected

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

Status

Not Affected

Vendor Statement

Our investigations have shown that this vulnerability relies on the firewall behavior to inspect TCP resend packets. ISA makes the inspection in user mode, above the TCP/IP stack, and the resend packets will be ignored silently by TCP/IP and will not pass to ISA inspection (in this case FTP application filter inspection).

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

NEC Corporation __ Not Affected

Notified: July 23, 2002 Updated: March 07, 2003

Status

Not Affected

Vendor Statement

sent on December 4, 2002
[Router Products]

* IX 1000 / 2000 / 5000 Series  

- is NOT vulnerable.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

NetScreen __ Not Affected

Notified: September 18, 2002 Updated: October 04, 2002

Status

Not Affected

Vendor Statement

NetScreen has examined the behavior of NetScreen firewalls when exposed to this traffic, and our products are not vulnerable to this specific attack.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Nortel Networks __ Not Affected

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

Status

Not Affected

Vendor Statement

The following Nortel Networks products use state-based firewall technology but are not affected by the vulnerabilities noted in VU#328867:

The Alteon Switched Firewall is not affected.

There are no issues with the Contivity Platform, this includes the:

> Contivity 600/1500/1600/2000/2500/2600/4500/4600
Contivity 1010/1050/1100
Contivity 1700/2700
Contivity software releases 3.5 and beyond including the CVC Client

The Shasta 5000 Broadband Services Node is not affected.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

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:

1. 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.

2. 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.

3. 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.

4. 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).

5. 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.

6. 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](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Secure Computing Corporation __ Not Affected

Notified: September 26, 2002 Updated: October 16, 2002

Status

Not Affected

Vendor Statement

This is the official Secure Computing response to CERT Vulnerability Note VU# 328867 “Multiple vendors’ firewalls do not adequately keep state of FTP traffic.”

GAUNTLET ™ FIREWALL & VPN (5.X and 6.0)
Not vulnerable.

GAUNTLET E-PPLIANCE FIREWALL & VPN (EPL 1.X and 2.0)
Not vulnerable.

SIDEWINDER™ FIREWALL & VPN (all releases including SIDEWINDER APPLIANCE)
Not vulnerable.

Secure Computing’s defense-in-depth architecture including the SecureOS™ operating system and application level proxies protect against this attack and another recent CERT vulnerability that affected lesser firewalls. Please see <http://www.securecomputing.com/index.cfm?skey=232&gt; for additional information.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

SecureWorx __ Not Affected

Updated: March 05, 2003

Status

Not Affected

Vendor Statement

We hereby attest that SecureWorx Basilisk Gateway Security product suite (Firmware version 3.4.2 or later) is NOT VULNERABLE to FTP Vulnerability VU#328867.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Stonesoft __ Not Affected

Notified: September 26, 2002 Updated: October 08, 2002

Status

Not Affected

Vendor Statement

Stonesoft’s StoneGate high availability firewall and VPN product handles the FTP protocol with its FTP protocol agent. No versions of StoneGate and its FTP protocol agent are vulnerable to the attacks described in this advisory.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Sun Microsystems Inc. __ Not Affected

Notified: September 24, 2002 Updated: October 08, 2002

Status

Not Affected

Vendor Statement

The in.ftpd(1M) daemon shipped with Solaris 2.6, 7, 8, and 9 is not affected by the issue described here.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

Symantec __ Not Affected

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

Status

Not Affected

Vendor Statement

Symantec has fully tested against this issue and is pleased to report this issue does not impact any of our currently supported products.

Versions/Platforms Not Vulnerable:

* Symantec Enterprise Firewall
* Symantec Enterprise VPN
* Symantec VelociRaptor
* Symantec Gateway Security 

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

eSoft __ Not Affected

Updated: October 09, 2002

Status

Not Affected

Vendor Statement

eSoft InstaGate is not vulnerable.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

3Com Unknown

Updated: October 10, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

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

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

FreeBSD __ Unknown

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

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

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

Addendum

FreeBSD includes support for IP Filter (ipf), and can be configured to use IP Filter and/or ipfw. The status of ipfw is currently unknown. For information concerning IP Filter (ipf), please see:

* IP Filter vendor statement



* OpenBSD vendor statement

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

ZyXEL __ Unknown

Updated: March 07, 2003

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

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

Addendum

It has been reported that the ZyXEL ZyWALL is not vulnerable, possibly if running firmware version 3.50 or higher.

This is a annoucement that our ZyWALL firewall series, including ZYWALL-1, ZyWALL-10, ZyWALL-50 and ZyWALL-100, are not vulnerable to the special FTP attack reported in CERT website (<http://www.kb.cert.org/vuls/id/328867&gt;). ZyWALL firmware from day one v3.50 can prevent from this FTP vulnerability.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23328867 Feedback>).

View all 30 vendors __View less vendors __

CVSS Metrics

Group	Score	Vector
Base
Temporal
Environmental

References

• <http://www.ietf.org/rfc/rfc959.txt&gt;
• <http://www.ietf.org/rfc/rfc2581.txt&gt;
• <http://online.securityfocus.com/archive/1/47688/2000-02-12/2000-02-18/1&gt;
• <http://online.securityfocus.com/archive/82/45758/2000-02-08/2000-02-14/1&gt;

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: