[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
- read forum
- new topic
- search

- meetings list
- recent additions
- add your info
 top 100 sites
- visit top sites
- sign up now
- members

- add your url
- add domain
- search box
- link to us

- our projects
- free email
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : FTP Bounce

Title: FTP Bounce
Released by: CERT
Date: 10th December 1997
Printable version: Click here

Hash: SHA1

CERT Advisory CA-97.27.FTP_bounce

   Original issue date: Dec. 10, 1997

   Last revised: March 08, 1999   Added vendor information for Data



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



FTP Bounce



   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



   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




   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



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.

    A. Vendor Information 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.


     Use the wu-ftpd package as a workaround.


   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. Please read the wu-ftpd README file

   "FIXES-2.4-HOBBIT" before installing the package.


   The latest version of wu-ftpd, which we recommend, is available from




   MD5 (wu-ftpd-2.4.2-beta-16.tar.Z) = c18c083c2a82eef1ccba6df9a406f026


   Further information on this package can be obtained from




     FTP Configuration


   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




   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:




   Other Caldera security resources are located at:




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.



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



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:


    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:


       (for US, Canada, Asia-Pacific, & Latin-America)


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

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:




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



   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

   For inet 6.01.xx.xx: - PINET601 (Version later than

   For inet 6.02.xx.xx: - PINET602 (Version later than


   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:


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


   OpenServer 5.0.4

   UnixWare 2.1

   ODT 3.0



   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.


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




   This document is available from:




CERT/CC Contact Information

   Email: cert@cert.org

          Phone: +1 412-268-7090 (24-hour hotline)

          Fax: +1 412-268-6989

          Postal address:

          CERT Coordination Center

          Software Engineering Institute

          Carnegie Mellon University

          Pittsburgh PA 15213-3890



   CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)

   Monday through Friday; they are on call for emergencies during other

   hours, on U.S. holidays, and on weekends.


Using encryption

   We strongly urge you to encrypt sensitive information sent by email.

   Our public PGP key is available from http://www.cert.org/CERT_PGP.key.

   If you prefer to use DES, please call the CERT hotline for more



Getting security information

   CERT publications and other security information are available from

   our web site http://www.cert.org/.


   To be added to our mailing list for advisories and bulletins, send

   email to cert-advisory-request@cert.org and include SUBSCRIBE

   your-email-address in the subject of your message.


   Copyright 1999 Carnegie Mellon University.

   Conditions for use, disclaimers, and sponsorship information can be

   found in http://www.cert.org/legal_stuff.html.


   * "CERT" and "CERT Coordination Center" are registered in the U.S.

   Patent and Trademark Office




   Any material furnished by Carnegie Mellon University and the Software

   Engineering Institute is furnished on an "as is" basis. Carnegie

   Mellon University makes no warranties of any kind, either expressed or

   implied as to any matter including, but not limited to, warranty of

   fitness for a particular purpose or merchantability, exclusivity or

   results obtained from use of the material. Carnegie Mellon University

   does not make any warranty of any kind with respect to freedom from

   patent, trademark, or copyright infringement.



   Revision history


Mar. 8, 1999  Added vendor information for Data General.

Jul. 9, 1998  Updated information for Digital Equipment Corporation

Jan. 8, 1998  Updates to Section III.B.

Jan. 7, 1998  Updated vendor information for NCR. Updates to Section III.B.

Dec. 19, 1997 Updates to Section III-B and Acknowledgments.

Dec. 16, 1997 Vendor updates for Sun Microsystems, Inc.

Dec. 11, 1997 Vendor updates for Caldera, Digital Equipment

              Corporation, NEC Corporation.


Version: PGP for Personal Privacy 5.0

Charset: noconv





(C) 1999-2000 All rights reserved.