Pages in the Historical section of this site are provided for historical purposes, they are no longer maintained. Links may not work.

Original issue date: December 10, 1997
Last revised: July 26, 2002
Updated links, wu-ftpd, SGI, and HP information

A complete revision history is at the end of this file.

In some implementations of FTP daemons, the PORT command can be misused to open a connection to a port of the attacker's choosing on a machine that the attacker could not have accessed directly. There have been ongoing discussions about this problem (called "FTP bounce") for several years, and some vendors have developed solutions for this problem.

The CERT/CC staff urges you to install a comprehensive patch if one is available. Until then, we recommend the wu-ftpd package identified in Section III.B. as a workaround.

We will update this advisory as we receive additional information. Please check our advisory files regularly for updates that relate to your site.


I. Description

In the past few years there have been ongoing discussions about a problem known as "FTP bounce." In its simplest terms, the problem is based on the misuse of the PORT command in the FTP protocol.

To understand the FTP bounce attack, please see the tech tip at

http://www.cert.org/tech_tips/ftp_port_attacks.html

The core component of the problem is that by using the PORT command in active FTP mode, an attacker may be able to establish connections to arbitrary ports on machines other than the originating client. This behavior is RFC compliant, but it is also potentially a source of security problems for some sites. The example attacks described in the tech tip demonstrate the potential of this vulnerability.

II. Impact

An attacker may be able to establish a connection between the FTP server machine and an arbitrary port on another system. This connection may be used to bypass access controls that would otherwise apply.

III. Solution

Because the core element of the attack (the FTP server can establish connections to arbitrary machines and arbitrary ports) is also a required component for RFC compliance, there is no clear-cut solution. With this in mind, we urge you to carefully consider the type of service that your site offers.

The best solution solely from a security perspective is to ensure that your FTP server software cannot establish connections to arbitrary machines. However, sites that rely on the RFC-compliant behavior may find that implementing this solution will affect applications that they use. (We have not received any first-hand reports of such cases.) Consequently, many vendors offer solutions that allow sites offering the FTP service to make the choice that best suits them. You should check to see what type of behavior your vendor's FTP daemon adopts (Section A).

If you wish to implement an FTP service that does not allow this attack and your vendor does not offer a daemon with this functionality, consider using the wu-ftpd package described in Section B. Other steps you can take are described in Section C.

  1. Vendor Information
  2. It is our experience that vendor implementations fall into one of these groups:

    1. strict conformance with RFC functionality: The PORT command may be used to connect directly to a third-party machine, and this is the only functionality allowed. Some vendors who choose to maintain strict conformance have addressed this problem by modifying all other network services to reject connections originating from the FTP data port (port 20).
    2. strict suppression of the PORT command: The PORT command may be used to connect to the originating client, and this is the only functionality allowed.

    3. variable PORT command behavior: The PORT command may be used in either of the above two ways, with one way being the default. Switching between them is usually achieved with a command line parameter. You should be careful to verify which is the default.

    Appendix A contains a list of vendors who have provided information about this problem. We will update the appendix as we receive more information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact your vendor directly.

  3. Use the wu-ftpd package as a workaround.
  4. The wu-ftpd package addresses the FTP bounce problem by ensuring that the PORT command cannot be used to establish connections to machines other than the originating client.

    The latest version of wu-ftpd is available from

    http://www.wuftpd.org/

  5. FTP Configuration
  6. Some attacks rely on an intermediate file being uploaded to one or more server machines via (usually anonymous) FTP. This file is used in a later phase of the attack.

    Your site should offer anonymous upload facilities only if it is absolutely necessary. Even then, you must carefully configure the incoming area. For further details, see "Anonymous FTP Configuration Guidelines" at

    http://www.cert.org/tech_tips/anonymous_ftp_config.html

    Note that these steps only repel attacks that rely on intermediate uploads. The steps are not effective against other attacks.

    If your site allows file uploads, we urge your to ensure that the FTP service restricts the PORT command so that it can only be used to connect to the originating client.


Appendix A - Vendor Information

Below is a list of the vendors who have provided information for this advisory. We will update this appendix as we receive additional information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact the vendor directly.

Caldera, Inc.

Caldera OpenLinux(tm) 1.2 ships with wu-ftpd-2.4.2 beta 15. For those with earlier versions of wu-ftpd, updates to this package can be obtained from:

ftp://ftp.caldera.com/pub/openlinux/updates/1.1/current/

Other Caldera security resources are located at:

http://www.caldera.com/tech-ref/security/

Cray Research - A Silicon Graphics Company

The ftpd supplied with Unicos and Unicos/mk is currently in category 1. We are working to make it category 3.

DATA GENERAL


DGUX documents a "-p" switch for ftpd, which appears to prevent exploitation of the problem described. Revision R4.20MU04 and later will be configured to include this switch in the /etc/inetd.conf file. Customers running earlier revisions should change the ftp line in their inetd.conf file to the following: ftp stream tcp nowait root /usr/bin/ftpd ftpd -p -t900

DIGITAL EQUIPMENT CORPORATION

A DIGITAL EQUIPMENT CORPORATION ADVISORY  VB#SSRT0452, concerning "DIGITAL UNIX
ftpd  V3.2g, V4.0, V4.0a, V4.0b, V4.0c" was issued APR  30,  1998. For more
information, please see
 
    the World Wide Web at the following FTP address:
 
       http://www.service.digital.com/html/patch_service.html
 
    Use the FTP access option, select DIGITAL_UNIX directory
    then choose the appropriate version directory 
    and download the patch accordingly.

The FreeBSD Project

FreeBSD 2.2.0 and all later releases do not allow the FTP bounce attack (unless explicitly allowed by the -R option). FreeBSD 2.1.7 and earlier releases can be abused by the bounce attack.

Hewlett-Packard Company

   This problem is addressed HP Security Bulletin 028. This bulletin can
   be found at one of these URLs:

     http://us-support.external.hp.com
       (for US, Canada, Asia-Pacific, & Latin-America)

     http://europe-support.external.hp.com
       (for Europe)

   ************************************************************************
   Current patches for SB#28 as of 11/5/97 from security patch matrix
   ************************************************************************

   Security Bulletin 028: Security Vulnerability in FTP

                 Current                             Original
           --------------------                --------------------
           s300  8.00: None                    s300  8.00: None
           s300  9.00: PHNE_6146               s300  9.00: PHNE_6146
           s300  9.03: PHNE_6146               s300  9.03: PHNE_6146
           s300  9.10: PHNE_6146               s300  9.10: PHNE_6146
           s700  8.05: None                    s700  8.05: None
           s700  8.07: None                    s700  8.07: None
           s700  9.01: PHNE_10008              s700  9.01: PHNE_6013
           s700  9.03: PHNE_10008              s700  9.03: PHNE_6013
           s700  9.05: PHNE_10008              s700  9.05: PHNE_6013
           s700  9.07: PHNE_10008              s700  9.07: PHNE_6013
           s700  9.09: PHNE_6169               s700  9.09: PHNE_6169
                       PHNE_6170                           PHNE_6170
           s700 10.00: PHNE_10009              s700 10.00: PHNE_6014
           s700 10.01: PHNE_10009              s700 10.01: PHNE_6014
           s700 10.09: PHNE_5965               s700 10.09: PHNE_5965
           s700 10.10: PHNE_10009              s700 10.10: None
           s700 10.16: None                    s700 10.16: None
           s700 10.20: None                    s700 10.20: None
           s700 10.24: None                    s700 10.24: None
           s700 10.30: None                    s700 10.30: None
           s800  8.00: None                    s800  8.00: None
           s800  8.02: None                    s800  8.02: None
           s800  8.06: None                    s800  8.06: None
           s800  9.00: PHNE_10008              s800  9.00: PHNE_6013
           s800  9.04: PHNE_10008              s800  9.04: PHNE_6013
           s800  9.08: PHNE_6171               s800  9.08: PHNE_6171
           s800 10.00: PHNE_10009              s800 10.00: PHNE_6014
           s800 10.01: PHNE_10009              s800 10.01: PHNE_6014
           s800 10.09: None                    s800 10.09: None
           s800 10.10: PHNE_10009              s800 10.10: None
           s800 10.16: None                    s800 10.16: None
           s800 10.20: None                    s800 10.20: None
           s800 10.24: None                    s800 10.24: None
           s800 10.30: None                    s800 10.30: None

   ***************************************************************************
   Accessing the HP ESC
   ***************************************************************************
   Hewlett Packard's HP-UX patches/Security Bulletins/Security
   patches are available via email and/or WWW (via the browser
   of your choice) on HP Supportline (HPSL).
   ---------------------------------------------------------------------
   To subscribe to automatically receive future NEW HP Security Bulletins from
   the HP SupportLine Digest service via electronic mail, do the following:

   1)  From your Web browser, access the URL:

         http://us-support.external.hp.com (US,Canada,Asia-Pacific,
         and Latin-America)

         http://europe-support.external.hp.com  (Europe)


      Login with your user ID and password, or register for one (remember
      to save the User ID assigned to you, and your password). Once you are
      on the Main Menu, Click on the Technical Knowledge Database, and it
      will connect to a HP Search Technical Knowledge DB page. Near the
      bottom is a hyperlink to our Security Bulletin archive. Once in the
      archive there is another  link to our current security patch matrix.
      Updated daily, this matrix is categorized by platform/OS release,
      and by bulletin topic.

This is resolved on HP-e3000 MPE/iX systems - fix: 8606-204841 in the following patches to FTP Server:

  • FTPGD62 for C.60.00
  • FTPGD63 for C.65.00
  • FTPGD49 for C.70.00

IBM Corporation

All AIX ftp servers are vulnerable to the FTP bounce attack. The following fixes are in progress:

AIX 3.2: upgrade to v4
AIX 4.1: IX73075
AIX 4.2: IX73076
AIX 4.3: IX73077

To Order

APARs may be ordered using Electronic Fix Distribution (via FixDist) or from the IBM Support Center. For more information on FixDist, reference URL:

http://www.ibm.com/support/

or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist".

MadGoat

This problem is fixed in MGFTP V2.2-2, which was released several months ago. That version restricts the port numbers to ports above 1024. However, it does not block access to third-party machines. V2.2-4, scheduled for release next week, will do that as well.

Microsoft Corporation

We prevent this attack by disallowing "third party" transfers. This is done via a modification to our implementation of the PORT command. When the FTP server receives a PORT command, the specified IP address *must* match the client's source IP address for the control channel.

In other words, then the client sends a PORT command to the FTP server, giving the server an IP address & port number to connect back to the client for the data transfer, the IP address *must* be the client's original IP address.

We have one other fix in which we disallow the PORT command from specifying reserved ports (those less than 1024) except port 20 (the default data port). By default, any client attempt to issue a port command with (port < 1024 && port != 20) will cause the PORT command to fail. This check can be disabled setting the EnablePortAttack registry value.

NEC Corporation

Several NEC Unix systems have proven vulnerable. Work is currently underway to identify all affected systems. Patches are forthcoming.

NCR Corporation

NCR is delivering a set of operating system dependent patches which contain an update for this problem. Accompanying each patch is a README file which discusses the general purpose of the patch and describes how to apply it to your system.

Recommended solution: Apply one of the following patches depending on the revision of the inet package installed on your system. To check its version execute:

    pkginfo -x inet

For inet 5.01.xx.xx: - PINET501 (Version later than 05.01.01.64)
For inet 6.01.xx.xx: - PINET601 (Version later than 06.01.00.24)
For inet 6.02.xx.xx: - PINET602 (Version later than 06.02.00.05)

After installation of the respective patch, the default behavior will be to protect from this vulnerability. A new ftpd man-page describe how to enable the old RFC compliant behavior.

The NetBSD Project

There are no patches for NetBSD 1.2.1 or prior, however the ftpd sources available from:
ftp.netbsd.org:/pub/NetBSD/NetBSD-current/src/libexec/ftpd
should work on a NetBSD 1.2.1 machine.

The OpenBSD project

FTP bounce can be fixed in the operating system by fixing all vulnerable services by checking for connections from port 20. Since this has been done in OpenBSD, OpenBSD is not vulnerable and does NOT NEED the variable port command. The solution applies since OpenBSD 2.1 (ie. it applies for both 2.1 and for 2.2).

Red Hat Software

We ship wu-ftpd, so this isn't a problem for us.

The Santa Cruz Operation, Inc.

SCO has determined that the following Operating systems are vulnerable to the ftp-bounce attack :-

OpenServer5.0.4
UnixWare2.1
ODT3.0
CMW+

We are currently working on a fix to this problem.

Siemens-Nixdorf Informationssysteme AG

ReliantUNIX is vulnerable.
The problem has been corrected in the current sources.
Patches will be developed (as necessary) and made available via your Siemens-Nixdorf customers service.

Silicon Graphics Inc.

Silicon Graphics Inc. has released SGI Security Advisory 20020305-01-I:

ftp://patches.sgi.com/support/free/security/advisories/20020305-02-I

Sun Microsystems, Inc.

Sun's FTP server software in SunOS 4.1.x and 5.x allow PORT requests to make data connections to arbitrary hosts. Prior to SunOS 5.6, Sun's FTP server software also allows data connections to arbitrary ports.

In SunOS 5.6, the FTP server software does not accept PORT requests to make data connections to well-known (privileged) ports. Sun has also released the following patches that prevent Sun's FTP server software from accepting PORT requests to make data connections to well-known ports for the following SunOS releases:

103603-05 SunOS 5.5.1
103604-05 SunOS 5.5.1_x86
103577-06 SunOS 5.5
103578-06 SunOS 5.5_x86
101945-51 SunOS 5.4
101946-45 SunOS 5.4_x86
104938-01 SunOS 5.3
104477-03 SunOS 4.1.4
104454-03 SunOS 4.1.3_U1

Sun recommends that sites that do not require their FTP server make connections to arbitrary hosts consider using wu-ftpd as a workaround.


The CERT Coordination Center thanks AUSCERT and DFN-CERT for helping develop this advisory. We also thank Steve Bellovin, and the vendors who offered valuable comments on the problem and solutions: BSDI, Caldera, Hewlett-Packard, Livingston, NetBSD, OpenBSD, Sun Microsystems.

Copyright 1997, 1998 Carnegie Mellon University.


Revision History
Dec 11, 1997: Vendor updates for Caldera, Digital Equipment Corporation, and NEC Corporation.
Dec 16, 1997: Vendor updates for Sun Microsystems, Inc.
Dec 19, 1997: Updates to Section III-B and Acknowledgments.
Jan 07, 1998: Updated vendor information for NCR. Updates to Section III.B.
Jan 08, 1998: Updates to Section III.B. 
Jul 09, 1998: Updated information for Digital Equipment Corporation
Mar 08, 1999: Added vendor information for Data General.
Feb 28, 2002: Updated invalid IBM link
Feb 28, 2002: Updated broken ftp links
Apr 03, 2002: Updated wu-ftpd information, added HP MPE and SGI information 
Jul 26, 2002: Corrected spelling errors in SGI vendor statement
  • No labels