Re: wu-ftpd overflow.

[lundberg+wuftpd () VR NET (Gregory A Lundberg)]

On Sun, 21 Mar 1999, CyberPsychotic wrote:

> (cc'ed to bugtraq since I haven't seen yet any patches fixing this
> problem were posted there)

Yes, the exploit recently posted to Bugtraq takes advantage of the
realpath() buffer overflows .. as they exist in the Redhat RPM version
shipped on their 5.<something> CD.  The exploit may require some
modification to be successfully used against other Linux/Intel systems
and, of course, will need major changes to be used against other hardware
or software platforms.

About the exploit posted on Bugtraq: my read-through of the shows it does
use the vulnerability through the MKD command.  You are correct that some
Academ beta versions do not use the source-provided vulnerable realpath()
function for MKD.  ISTM it should be fairly easy to modify the exploit to
make use of other commands where a given Academ beta version _does_ use
realpath().  Remember, the exploit is an _example_ of the problem, it does
not reveal the true magnetude of the vulnerability.  A positive test
proves vulnerability while a negative test proves nothing.

The vulnerable and non-vulnerable versions were outlined in the advisories
which _were_ posted on Bugtraq.

The realpath() problem was openly discussed on Bugtraq weeks (months? ..
I'd have to look through the Bugtraq archives again) before the release of
the advisories.  The actively maintained versions of the wu-ftpd daemon
were immedeately corrected as a result of the realpath() vulnerability
discussions on Bugtraq, so they had been corrected for quite some time
prior to Netect's research indicating there may be a problem.

At the time of publication of the Netect/CERT Advisories, patches for
wu-ftpd were unnecessary since the current, maintained, versions were not
vulnerable.

My patch file for wu-ftpd, which corrects the problem, is presently 644162
bytes in length, fixes several hundred other problems with the daemon, and
is available via FTP from ftp://ftp.vr.net/pub/wu-ftpd/ for those silly
enough to want it (I rather doubt it Aleph would allow it through to the
Bugtraq the mailing list).  I am not inclined to pull out the patches for
realpath() because the entire pile of male bovine by-product was replaced.

A patch file for the other major, maintained, version of wu-ftpd
(BeroFTPD) is not available at all.  Since today it would probably run
well over 1 Meg, the maintainer sees no point in the fiction of
'patching'.  He is also dis-inclined to pull out the realpath() changes
since he and I co-operated on the complete replacement of the function
(actually he did most of the initial work; I just debugged it).

At about the time of the Netect/CERT Advisorie Redhat released updated
RPMs for the vulnerable Academ 2.4.2-betas they distribute.  I don't know
whether they released before or after, but I do recall it was just a few
hours before their availability was discussed on Bugtraq.

Other versions (from wu-stl and academ) are not actively maintained and
should not be used in production environments.  Anyone running versions of
wu-archive / the wu-ftpd daemon older than Academ's 2.4.2-beta-18 has more
severe problems than this buffer overrun, so I see no point posting the
patch.  For them the correct solution is either updating to a more current
version or manual operation of the power switch.

The only current version still vulnerable when the CERT advisory was
issued the Academ version 2.4.2-beta-18, which is (almost) not actively
maintained.  A week or two following the CERT advisory Academ silently
released 2.4.2 (final).

My knowledge of the code, and my direct research indicates:

   The 2.4.2 (final) version does not completely solve the problem.  Nor
   does your patch.  (Nor, for that matter, does the Redhat patch but
   that's a moot point since their patch does fix the problem for their
   Linux systems.)

   For systems using the realpath() function supplied with the source kit,
   a patch will work to correct, or at least hide, most, if not all, of
   the vulnerability.  For other systems, whether or not the daemon is
   vulernable depends upon whether or not your vendor-supplied realpath()
   function is vulnerable (back to the original discussion on Bugtraq).

   The only change here from my recommendations appearing in the Netect
   and CERT advisories is that the number of potentially vulnerable
   systems has been reduced by those using the daemon-supplied realpath()
   function to only those with vendor-supplied vulnerable realpath()
   functions.

   To determine if your daemon uses the supplied function, look in
   <wuftpd>/src/config/config.<ostype> for a line reading something like:

#define realpath realpath_on_steroids

   If this #define does NOT appear, contact your vendor concerning the
   vulnerability of the realpath() function, or upgrade to a more-current
   version of the daemon (yes, there are versions much more current that
   Academ's 2.4.2/final).

Those wishing further information may contact me via the wu-ftpd support
mailing list at mailto:wu-ftpd () wugate wustl edu .. subscription and
unsubscription information for that mailing list are in the FAQ.

The location of the latest versions of wu-ftpd can be found in the
directory

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

wu-ftpd Resource Center:  http://www.landfield.com/wu-ftpd/
wu-ftpd FAQ:              http://www.cetis.hvu.nl/~koos/wu-ftpd-faq.html
wu-ftpd list archive:     http://www.landfield.com/wu-ftpd/mail-archive/
                          (The html version of the wu-ftpd list archive is
                          currently not working, use the Unix mailbox
                          format instead.)

--

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              lundberg+wuftpd () vr net
Kettering, OH 45409-1615 USA    1-800-809-2195