Date: Mon, 15 Feb 1999 12:00:00 -0500 (EST) From: Gregory A Lundberg To: WU-FTPD Discussion List 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 posted a claim on the WU-FTPD Discussion List 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 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 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 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 lundberg@vr.net --------------------------------------------------------------------------- Bret McDanel 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 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 points out the reason debug doesn't work in daemon-mode is it's initialized too late. Oliver Billmann discovered the anti-NOOP code didn't work. The timer was being restarted too often. Viljar Tulit 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 noted there were points where multiple replies due to realpath() returning an error could hang the remote client. Removed the extra replies. Ian Willis submitted corrections for SecureWare systems so the daemon can build on SCO OpenServer 5. Jordan Ritter reported a compile error for quotas on Linux; seems Redhat or someone forgot to #include a file. His patch should fix that. Jacques Distler noted dumb coding mistakes in realpath.c and provided updates for building on NextStep 3.3 (nx3). Ayamura Kikuchi 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 lundberg+wuftpd@vr.net Kettering, OH 45409-1615 USA 1-800-809-2195