No information is available for this file.
96141788d27c818f4b55f8faffc95316a17b70b22264d5425ce92d9e5487cd1d<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (X11; I; SunOS 5.5.1 sun4c) [Netscape]">
<TITLE>CERT* Advisory CA-97.27 FTP Bounce</TITLE>
</HEAD>
<BODY>
<!--<A HREF="/"><IMG SRC="/images/certbanner.gif" ALT="CERT* Coordination Center" ALIGN=TOP></A>
<HR> -->
<P>
<h1>CERT* Advisory CA-97.27</h1>
Original issue date: Dec. 10, 1997<br>
Last revised: January 8, 1998 - Updates to Section III.B.
<Br>
<P>
A complete revision history is at the end of this file.
<P>
<HR>
<P>
<h1>FTP Bounce</h1>
<P>
<HR>
<P>
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.
<P>
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.
<P>
We will update this advisory as we receive additional information. Please
check our advisory files regularly for updates that relate to your site.
<P>
<HR>
<P>
<h2>I. Description</h2>
<P>
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.
<P>
To understand the FTP bounce attack, please see the tech tip at
<P>
<a href ="ftp://ftp.cert.org/pub/tech_tips/FTP_PORT_attacks">ftp://ftp.cert.org/pub/tech_tips/FTP_PORT_attacks</a>
<P>
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.
<P>
<h2>II. Impact</h2>
<P>
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.
<P>
<h2>III. Solution</h2>
<P>
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.
<P>
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).
<P>
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.
<P>
<ol><h3><li type = "A">Vendor Information</h3>
<P>
It is our experience that vendor implementations fall into one of
these groups:
<P>
<ol><li type = "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).
<P>
<li>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.
<P>
<li>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.
</ol><P>
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.
<P>
<h3>
<li>
Use the wu-ftpd package as a workaround.</h3>
<P>
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.
<P>
The latest version of wu-ftpd, which we recommend, is available
from
<P>
<a href ="ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-16.tar.Z">ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-16.tar.Z</a>
<P>
MD5 (wu-ftpd-2.4.2-beta-16.tar.Z) = c18c083c2a82eef1ccba6df9a406f026
<P>
Further information on this package can be obtained from
<P>
http://www.academ.com/academ/wu-ftpd
<h3><li>FTP Configuration</h3>
<P>
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.
<P>
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
<P>
<a href ="ftp://ftp.cert.org/pub/tech_tips/anonymous_ftp_config">ftp://ftp.cert.org/pub/tech_tips/anonymous_ftp_config</a>
<P>
Note that these steps only repel attacks that rely on intermediate
uploads. The steps are not effective against other attacks.
<P>
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.
</ol>
<P>
<HR>
<P>
<h2>Appendix A - Vendor Information</h2>
<P>
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.
<P>
<h3>
Caldera, Inc. </h3>
<P>
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:
<P>
<a href ="ftp://ftp.caldera.com/pub/openlinux/updates/1.1/current/">ftp://ftp.caldera.com/pub/openlinux/updates/1.1/current/</a>
<P>
Other Caldera security resources are located at:
<P>
<a href ="http://www.caldera.com/tech-ref/security/">http://www.caldera.com/tech-ref/security/</a>
<P>
<h3>Cray Research - A Silicon Graphics Company</h3>
<P>
The ftpd supplied with Unicos and Unicos/mk is currently in category 1.
We are working to make it category 3.
<P>
<h3>DIGITAL EQUIPMENT CORPORATION</h3>
<P><pre>
DIGITAL UNIX V3.2c thru V3.2g
DIGITAL UNIX V4.0 thru V4.0c
At the time of writing this document, patches(binary kits) are in
progress and final testing has been completed. Distribution of the
fix for this problem is expected to begin soon (BL9 and possibly
as early release patches). Digital will provide notice of the
completion/availibility of the patches through AES services (DIA,
DSNlink) the DIGITAL Patch Service WEB site, and be available from
your normal Digital Support channel.
DIGITAL EQUIPMENT CORPORATION 12/97
----------------------------- ------
</pre><P>
<h3>The FreeBSD Project</h3>
<P>
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.
<P>
<h3>Hewlett-Packard Company</h3>
<P><pre>
This problem is addressed HP Security Bulletin 028. This bulletin can
be found at one of these URLs:
<a href ="http://us-support.external.hp.com">http://us-support.external.hp.com</a>
(for US, Canada, Asia-Pacific, & Latin-America)
<a href ="http://europe-support.external.hp.com">http://europe-support.external.hp.com</a>
(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:
<a href ="http://us-support.external.hp.com">http://us-support.external.hp.com</a> (US,Canada,Asia-Pacific,
and Latin-America)
<A href = "http://europe-support.external.hp.com">http://europe-support.external.hp.com</a> (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.
</pre><P>
<h3>IBM Corporation</h3>
<P>
All AIX ftp servers are vulnerable to the FTP bounce attack. The
following fixes are in progress:
<P>
AIX 3.2: upgrade to v4<br>
AIX 4.1: IX73075<Br>
AIX 4.2: IX73076<Br>
AIX 4.3: IX73077<br>
<P>
<B>To Order</b>
<P>
APARs may be ordered using Electronic Fix Distribution (via FixDist)
or from the IBM Support Center. For more information on FixDist,
reference URL:
<P>
<A href ="http://service.software.ibm.com/aixsupport/">http://service.software.ibm.com/aixsupport/</a>
<P>
or send e-mail to <a href ="mailto:aixserv@austin.ibm.com">aixserv@austin.ibm.com</a> with a subject of "FixDist".
<P>
<h3>MadGoat</h3>
<P>
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.
<P>
<h3>Microsoft Corporation</h3>
<P>
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.
<P>
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.
<P>
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.
<P>
<h3>NEC Corporation</h3>
<P>
Several NEC Unix systems have proven vulnerable. Work is currently
underway to identify all affected systems. Patches are forthcoming.
<P>
<h3>NCR Corporation</h3>
<P>
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.
<P>
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:
<P><pre>
pkginfo -x inet
</pre><P>
For inet 5.01.xx.xx: - PINET501 (Version later than 05.01.01.64) <br>
For inet 6.01.xx.xx: - PINET601 (Version later than 06.01.00.24) <br>
For inet 6.02.xx.xx: - PINET602 (Version later than 06.02.00.05)<br>
<P>
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.
<P>
<h3>The NetBSD Project</h3>
<P>
There are no patches for NetBSD 1.2.1 or prior, however the ftpd
sources available from:<br>
<a href ="ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/libexec/ftpd">ftp.netbsd.org:/pub/NetBSD/NetBSD-current/src/libexec/ftpd</a><br>
should work on a NetBSD 1.2.1 machine.
<P>
<h3>The OpenBSD project</h3>
<P>
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).
<P>
<h3>Red Hat Software</h3>
<P>
We ship wu-ftpd, so this isn't a problem for us.
<P>
<h3>The Santa Cruz Operation, Inc.</h3>
<P>
SCO has determined that the following Operating systems are vulnerable
to the ftp-bounce attack :-
<P>
<table>
<tr><td>OpenServer</td><td>5.0.4</td></tr>
<tr><Td>UnixWare</td><td>2.1</td></tr>
<tr><td>ODT</td><td>3.0</td</tr>
<tr><td>CMW+</td><td></td></tr>
</table>
<P>
We are currently working on a fix to this problem.
<P>
<h3>Siemens-Nixdorf Informationssysteme AG</h3>
<P>
ReliantUNIX is vulnerable.<br>
The problem has been corrected in the current sources.<br>
Patches will be developed (as necessary) and made available via your
Siemens-Nixdorf customers service.
<P>
<h3>Sun Microsystems, Inc.</h3>
<P>
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.
<P>
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:
<P>
103603-05 SunOS 5.5.1<br>
103604-05 SunOS 5.5.1_x86<br>
103577-06 SunOS 5.5<br>
103578-06 SunOS 5.5_x86<br>
101945-51 SunOS 5.4<br>
101946-45 SunOS 5.4_x86<br>
104938-01 SunOS 5.3<br>
104477-03 SunOS 4.1.4<br>
104454-03 SunOS 4.1.3_U1
<P>
Sun recommends that sites that do not require their FTP server make
connections to arbitrary hosts consider using wu-ftpd as a workaround.
<P>
<HR>
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.
<HR><P>
If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (see <A HRef= "http://www.first.org/team-info/">http://www.first.org/team-info/</a>)</P>
<H3>CERT/CC Contact Information</H3>
<P>Email <A HREF="mailto:cert@cert.org">cert@cert.org</A>
<P>Phone +1 412-268-7090 (24-hour hotline)</P>
<P>
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) and are
on call for emergencies during other hours. </P>
<P>Fax +1 412-268-6989 </P>
<P>Postal address:</P>
<P>CERT Coordination Center<BR>
Software Engineering Institute<BR>
Carnegie Mellon University<BR>
Pittsburgh PA 15213-3890<BR>
USA </P>
<P><strong>Using encryption</strong></P>
<P>We strongly urge you to encrypt sensitive information sent by email.
We can support a shared DES key or PGP. Contact the CERT/CC for more information.
</P>
<P>Location of CERT PGP key</P>
<P><A HREF="ftp://ftp.cert.org/pub/CERT_PGP.key">ftp://ftp.cert.org/pub/CERT_PGP.key</A>
</P>
<P><strong>Getting security information</strong></P>
<P>CERT publications and other security information are available from</P>
<P><A HREF="http://www.cert.org/">http://www.cert.org/</A> <BR>
<A HREF="ftp://ftp.cert.org/pub/">ftp://ftp.cert.org/pub/</A> </P>
<P>CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce <BR>
To be added to our mailing list for advisories and bulletins, send email
to</P>
<P><A HREF="mailto:cert-advisory-request@cert.org">cert-advisory-request@cert.org</A>
</P>
<P>In the subject line, type</P>
<P>SUBSCRIBE your-email-address </P>
<HR WIDTH="100%">
<p>Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in <a href="http://www.cert.org/legal_stuff.html">http://www.cert.org/legal_stuff.html</a> and <a href="ftp://ftp.cert.org/pub/legal_stuff">ftp://ftp.cert.org/pub/legal_stuff</a>. If you do not have FTP or web access, send mail to <a href="mailto:cert@cert.org">cert@cert.org</a> with "copyright" in the subject line. </p>
<p>* CERT is registered U.S. Patent and Trademark Office</p>
<hr>
<p>Comments or suggestions about technical content? Questions about the
CERT/CC? Send them to <a href="mailto:cert@cert.org">cert@cert.org</a>.</p>
<p>Comments or suggestions about the web site? Send them to <a
href="mailto:web\
master@cert.org">webmaster@cert.org</a>.</p>
<HR>
<P>
Revision history
<P>
<pre>
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.
</pre>
<BODY>
</HTML>
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed