Medium (dependent on customer configuration)
Symantec is aware of a potential FTP Bounce Attack vulnerability reported in Bugtraq ID# 267784 (http://online.securityfocus.com/archive/1/267784). This vulnerability could affect some Symantec Enterprise Firewall deployments. By exploiting this FTP protocol-based vulnerability, an attacker could, potentially, hide an attack by using the firewall identity against an unsuspecting and unprotected external machine. In addition, by overwriting the PORT command with its own internal address, the firewall overwrites the FTP-server's built-in protection mechanism that protects against this type of attack.
Raptor Firewall V6.5.3 (Solaris)
Raptor Firewall 6.5 (Windows NT)
Symantec Enterprise Firewall V7.0 (Solaris)
Symantec Enterprise Firewall 6.5.2 (Windows 2000 and NT)
Symantec Enterprise Firewall 7.0 (Windows 2000 and NT)
Symantec Gateway Security 1.0
The FTP Bounce Attack exploits a known design flaw in the FTP standard. All RFC compliant FTP servers must support the PORT command. The PORT command is used between an FTP client and server to coordinate the data channel connection between the two devices. The RFC dictates that a connection for the data channel should be allowed to any IP address and any port. However, this RFC compliancy renders FTP servers vulnerable to misuse of the PORT command. For a more detailed explanation of this issue, please see CERTŪ Advisory CA-1997-27 FTP Bounce and the related technical tip.
The Symantec Enterprise Firewall automatically rewrites the PORT command with either the address of the client machine or the firewall address. In either case, when the PORT request reaches the FTP server, the PORT command will match the source address of the FTP client. If configured, the FTP server scans the packet to make sure the PORT command matches the IP address of the client, which it does in all cases. The FTP server then attempts to open a data connection to the client IP address, which gets translated by the firewall to the victim's IP address. This is not a desired behavior because it gives the security administrator a false sense of protection from an FTP Bounce Attack.
If the FTP Bounce Attack vulnerability affects your deployment, make sure that you apply the related hotfix available from the Symantec Enterprise Support site. The hotfix is an enhanced version of our FTPd module for the affected platforms that extends the protection provided by the firewall.
The module update is available for download from the Symantec Enterprise Support site (http://www.symantec.com/techsupp) for all affected versions and platforms. The following enhancements have been made:
Symantec verified these security enhancements. In addition, ICSA Labs verified these enhancements for the Symantec products that are ICSA Certified Firewall Products. The new features will extend the enterprise-level protection provided by our FTP proxy which among other checks already includes protection against FTP Bounce attacks off the firewall itself, blocking PORT commands that select a well-known port, FTP strong/weak user authentication methods, GET/PUT granular security policies, FTP protocol and command verification, and transparent address hiding.
- By default, if the firewall detects a PORT request destined for an IP address other than the IP address of the FTP client, it will log the following warning:
"353 Warning: PORT command referenced a destination (x.x.x.x) that doesn't match control channel (y.y.y.y): possible Bounce attack? To enforce strict PORT checking please set "ftpd.allow_address_mismatch=False" in the Config.cf file."
If firewall administrators decide that this is not a problem in their environment, they can disable the Warning message by setting the following Config.cf variable:
ftpd.suppress_address_mismatch_warning=True (default is False)
- If firewall administrators want to enforce strict PORT command checking and block any PORT requests that reference a different address than the original FTP client IP, they can set the following Config.cf variable:
ftpd.allow_address_mismatch=False (default is True)
By enforcing "strict" PORT checking on the firewall, security administrators do not have to make sure that all of their FTP servers are patched or configured to block the FTP Bounce Attack.
Symantec takes the security and proper functionality of our products very seriously. As founding members of the Organization for Internet Safety (OISafety), Symantec supports and follows the principles of responsible disclosure. Symantec also subscribes to the vulnerability disclosure guidelines outlined by the National Infrastructure Advisory Council (NIAC).
Please contact firstname.lastname@example.org if you feel you have discovered a security issue in a Symantec product. A Symantec Product Security team member will contact you regarding your submission. Symantec strongly recommends using encrypted email for reporting vulnerability information to email@example.com. The Symantec Product Security PGP key can be found at the end of this message.
Symantec has developed a Product Vulnerability Response document outlining the process we follow in addressing suspected vulnerabilities in our products. This document is available below.
Copyright © by Symantec Corp.
Permission to redistribute this alert electronically is granted as long as it is not edited in any way unless authorized by Symantec Security Response. Reprinting the whole or part of this alert in any medium other than electronically requires permission from firstname.lastname@example.org.
The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.
Symantec, Symantec products, Symantec Security Response, and email@example.com are registered trademarks of Symantec Corp. and/or affiliated companies in the United States and other countries. All other registered and unregistered trademarks represented in this document are the sole property of their respective companies/owners.
Last modified on: Monday, 25-Oct-2004 14:52:08 PDT