Date: Mon, 15 Feb 1999 12:00:00 -0500 (EST)
From: Gregory A Lundberg <[email protected]>
To: WU-FTPD Discussion List <[email protected]>
Subject: [VR14] Security update for wu-ftpd 2.4.2 (beta 18) VR13

The VR14 updates for WU-FTPD 2.4.2 (beta-18) is now available.

This is a security update.  If you are running any version of wu-ftpd
prior to this version, you are STRONGLY encouraged to upgrade.  There
are no new features in this version.

Four separate security issues are corrected by this update.  All are
described below; all but the last were discovered since the release of
the VR13 update on Feburary 1, 1999.  Due to the nature of the three
recently discovered problems, it was felt prudent to put out a mid-month
update rather than wait until the normal update on the 1st of the month.
I can only say I wish the recent Netect Advisory and subsequent CERT
Advisory had been released a little later so these issues could have been
addressed prior to the massive downloading of VR13 over the past week.

===========================================================================

                             SECURITY UPDATE

PASV Port Race Attack
---------------------
On Monday, February 8, 1999, Bret McDanel <[email protected]> posted a claim
on the WU-FTPD Discussion List <[email protected]> that he "wrote a
program and released it last week" which implemented a PASV port-race
attack utilizing a well-known vulnerability in the FTP protocol.

Furthermore, he claimed to have an "unreleased version [which] ... loops
forever logging to files, and changes the port range that it scans so that
it keeps up with the new ports that the server issues."  As proof, he
claims, "My program against [a large, well-known commercial FTP site]
worked quite well ...  it got a hit every second or two.  This is quite
high (I knew [the site] would have a lot of activity so it seemed a good
'final test' area)."

CONTEXT OF THE ATTACK

The FTP protocol uses two TCP connections: the control connection where the
client issues commands to the server, and the data connection.  There are
two modes of operation for the data connection: PORT and PASV.  Using PORT
mode, the client listens on a non-privileged port for a TCP connection from
the server.  With PASV mode, the server listens for a connection from the
client.  Both modes are required by the RFC to provide for the possibility
of server-to-server transfers (mirrors).

Since virtually all web browsers use PASV mode data connections, the number
of PASV data transfers has increased dramatically over the past few years.

An attacker may make use of this behavior to steal a PASV data connection
to the server in the interval between the server's openning of the port and
the client's attempt to connect to the server on that port.  When this
occurs, the client will most likely get a 'connection refused' or 'port
already in use' error and retry the transfer (or, more likely, the human
operator will retry).

A successful attack CANNOT be used to directly break into the server.  This
is a attack against the data transfer, using a vulnerability designed into
the FTP protocol, and does not rely upon any errors in the design or
implementation of the server.

This attack can be used to gain unauthorized access to sensitive
information being transmitted from the server to the client.  In all
likelihood, neither the server nor the client would be aware the theft had
occurred.  Such an attack could be used, for instance, to obtain copies of
paid-for, licensed software updates or circumvent the export-controls used
by the FTP site to restrict the distribution of cyrptographic software.

A successful attack can also be used to transmit information of the
attacker's choosing into the server.  Unless some external means of
verification is used, the FTP site could process or re-distribute this
bogus information.  The attack could be used, for instance, to randomly
replace files transferred between public FTP sites during mirror runs, or
to insert Trojaned programs into an author's site for later distribution.

WHO IS VULNERABLE

Most FTP servers rely upon the operating system to choose the actual TCP
port for use by the PASV data connection.  Unfortunately, many systems use
a linear search for an available port making it possible for a third party
to guess which port will be used for a future transfer.  Some FTP servers
choose the port themselves, but suffer from the same deficiency.

The WU-FTPD server traditionally has relied upon the underlying system to
assign the PASV port.  In version 2.4.2 (Beta 18) VR5, the ability to limit
the range of ports used for PASV data connections was added which used a
linear search to select a port number within the range.

Prior to the VR14 update, the wu-ftpd daemon would report when a PASV
connection was received from a client IP-address which did not match the
IP-address of the client's control connection.

DEFENSES

The FTP Security Extensions (FTP-SEC, RFC 2228) provide for cryptographic
authentication and encryption of the FTP session rendering the PASV port
race attack ineffective.  Other methods, such as tunnelling FTP through the
Secure Socket Layer (SSL, http://www.netscape.com/newsref/std/SSL.html )
can also be used.  Unfortunately, none of these methods have achieved
widespread use.

Using a randomly selected TCP port for the PASV data connection makes the
attack much more difficult.  While not eliminating the possibility of
success, the attacker must either wait for a given port to be used or
attempt to scan a large number of ports very quickly.  The success of this
defense depends upon the attacker not being able to guess the port number
which will next be used by the server.  With this VR14 update, the daemon
always uses a randomly selected port number.

The FTP server can also prevent a PASV race attack from third party sites
by refusing to tranfer any information when the IP-address of the client on
the control connection does not match the IP-address of the client on the
PASV data connection.  Traditionally, wu-ftpd has reported this condition
but taken no other action.  With the VR14 update, the server will no longer
accept data when the addresses to not match.  Since this makes the server
not strictly compliant with the RFC, a compile-time option is provided to
disable this feature.

===========================================================================

                             SECURITY UPDATE

Stack buffer overruns
---------------------
Ian Willis <[email protected]> discovered that extremely long file pathnames
could result in an overrun of the stack buffer used to record the transfer
log.  These errors were discovered during a code read-through.

This error appears in all versions of wu-ftpd prior to this VR14 update.

There are no known tests or attacks for this overrun.  It is unknown, and
appears very unlikely, the server could be compromised by this means.



Viljar Tulit <[email protected]> discovered during a code read-through
that a number of stack buffers were defined using BUFSIZ rather than
MAXPATHLEN and were being used in a context where MAXPATHLEN was correct.

This error appeared in the VR5 update as part of the network throughput
limiting feature.  Servers compiled without this feature do not have this
error.

There are no known tests or attacks for this overrun.  It is unknown, but
appears it may be possible, the server could be compromised by this means.

===========================================================================

                             SECURITY UPDATE

NOOP denial of service
----------------------
The VR3 update disabled the use of the NOOP command to bypass the idle time
limits enforced by the server.  The VR8 update made this a compile-time
option.

Oliver Billmann <[email protected]> discovered this feature was not
working.

The effect of this error is simply that users may use the NOOP command to
hold a control connection open indefinitely, thus reducing the number of
available slots for the connection class (limit clause) and denying others
access to the server.  A number of popular FTP clients provide a NOOP
anti-idle feature.

===========================================================================

                             SECURITY UPDATE

Slowing password guessers
-------------------------
In the VR8 update, a number of changes were made to prevent probing the
server to determine valid usernames.  Earlier versions of the daemon
responded differently to valid, invalid usernames and valid names which
are allowed to log in via FTP (listed in /etc/ftpusers).  This behavior
could be used by an attacker to determine whether certain usernames exist
on the FTP host.

The wu-ftpd server has traditionally used an increasing-period sleep after
each unsuccessful login attempt in an effort to slow password guessers.
Unforunately, with the VR8 changes, this sleep was occuring at a point when
the alarm signal was masked, causing the daemon to freeze permanently.
While the causes of this were researched, the VR versions did not include
this sleep.  Most FTP sites limit the number of login attempts (loginfails)
to some small number (typically 3 or 5) so the risk of password guessers
being undetected was judged to be relatively low.

This VR14 update re-institutes the sleep after each failed login attempt.

===========================================================================

The VR updates for WU-FTPD include additional features requested over the
years by the user community and includes a number of bug fixes for both the
base 2.4.2 (beta-18) release and earlier VR updates.

These are available as both patches and pre-patched tarballs at:

 ftp://ftp.vr.net/pub/wu-ftpd/

 MD5                               Package
 ---                               -------
 572233edabebba5077b7ad317058192f  wu-ftpd-2.4.2-beta-18-vr14.tar.Z
 db4403de07667babbadbbd1ae72f0799  wu-ftpd-2.4.2-beta-18-vr14.tar.gz

 bcd74875a953676ba9f8de4c315f9712  wu-ftpd-2.4.2-beta-18-vr3.patch
 863e294eddfe2c772cd9c541372c7e1d  wu-ftpd-2.4.2-beta-18-vr4.patch
 8f7d523eff5785a901d8ec9330e7b2a4  wu-ftpd-2.4.2-beta-18-vr5.patch
 891ea301ab535e3aa55c5da4c3b3dd37  wu-ftpd-2.4.2-beta-18-vr6.patch
 dc1672289c2da25880f7c63f21b37122  wu-ftpd-2.4.2-beta-18-vr7.patch
 602b1431727261a4b16340853f6d81c3  wu-ftpd-2.4.2-beta-18-vr8.patch
 9eee17b78a3a245dd71476e9426baaa0  wu-ftpd-2.4.2-beta-18-vr9.patch
 c85059908d124be5a6a9c8331c5322c0  wu-ftpd-2.4.2-beta-18-vr10.patch
 fb9596c5950cee6bad0e0d70fa168ccf  wu-ftpd-2.4.2-beta-18-vr11.patch
 caaeceacb995768c8f99628fe54af798  wu-ftpd-2.4.2-beta-18-vr12.patch
 1ee90ee4ba0df2be01c7b3151584e5d4  wu-ftpd-2.4.2-beta-18-vr13.patch
 06a7bb970ae9a0f0223851b28337638f  wu-ftpd-2.4.2-beta-18-vr14.patch

If you take just the patch files, please remember: they are cumulative.
you cannot apply fixes from one set without earlier sets already having
been applied.  The first set for BETA-18 is VR3; VR1 and VR2 were for
BETA-17 only.

Pre-compiled binaries for VR14 are not yet available.  The earlier binaries
will remain available until newer versions are ready.  Check the binaries
directory to see if a pre-compiled version is has become available for your
platform since this notice was drafted.



This is a list of fixes to BETA 18 with VR13 applied from [email protected]
---------------------------------------------------------------------------
Bret McDanel <[email protected]> claims to have written and released to the
wild an attack utilizing the old, well-known PASV port race designed into
the FTP protocol.  To make it harder for this race to succeed, do not
depend upon the underlying system to randomly choose the PASV port.

Disallow PASV connections from IP addresses different than the control
connection.  This is not a complete fix, but it will stop connection theft
where the attacker is on a different machine than the victim-client.

Ian Willis <[email protected]> has discovered still more buffer-overflow points
which can cause problems.  This time it's in the writing of the xferlog.
Sigh.  This really should be rewritten but his quick fix is good enough.

Back in VR8 I turned off the sleep slowing down password guessers because
there are times when signals can be off when the sleep occurs and that
would hang the daemon.  Let's fix that and re-enable the sleep.

Coranth Gryphon <[email protected]> points out the reason debug doesn't
work in daemon-mode is it's initialized too late.

Oliver Billmann <[email protected]> discovered the anti-NOOP code
didn't work.  The timer was being restarted too often.

Viljar Tulit <[email protected]> points out the size of a buffer used by
the *_realpath() functions is BUFSIZ and should be MAXPATHLEN.  Actually,
this is the case many places in extensions.c so I changed 'em all.

Ian Willis <[email protected]> noted there were points where multiple replies
due to realpath() returning an error could hang the remote client.  Removed
the extra replies.

Ian Willis <[email protected]> submitted corrections for SecureWare systems so
the daemon can build on SCO OpenServer 5.

Jordan Ritter <[email protected]> reported a compile error for quotas on
Linux; seems Redhat or someone forgot to #include a file.  His patch should
fix that.

Jacques Distler <[email protected]> noted dumb coding mistakes in
realpath.c and provided updates for building on NextStep 3.3 (nx3).

Ayamura Kikuchi <[email protected]> notes that the correction for SCO has
an effect on Digital Unix with C2 (SECUREOSF) and provided a correction.


--

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email protected]
Kettering, OH 45409-1615 USA    1-800-809-2195

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.