Subject: [VR17] WU-FTPD-2.4.2-VR17 Released

From: "Mona Wong" <[email-masked]>
Date: Fri, 16 Apr 1999 11:10:39 -0700

Hi Gregory:

	I tried to download VR17 from ftp://ftp.vr.net/pub/wu-ftpd/ but got a
timeout error.  Is there a problem with this site?

	Also, I just heard of a security hole newly discussed by bugtraq and
wanted to know if VR17 fixes that hole.  Do you know anything about this new
hole?

Mona

-- 
==================================================================
Mona Wong
graphics / visualization programmer wanna-be & web fool-arounder
National Center for Microscopy and Imaging Research
University of California, San Diego
http://www-ncmir.ucsd.edu
==================================================================

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 16 Apr 1999 15:10:34 -0400 (EDT)

On Fri, 16 Apr 1999, Mona Wong wrote:

> 	I tried to download VR17 from ftp://ftp.vr.net/pub/wu-ftpd/ but
> got a timeout error.  Is there a problem with this site?
> 
> 	Also, I just heard of a security hole newly discussed by bugtraq
> and wanted to know if VR17 fixes that hole.  Do you know anything
> about this new hole?

Offline for a few.  I'm offsite, my people tell me it was a failure
somewhere.  You're reading this, it's back up.  My reply is taking a while
because I"m having to deal with PSI's typical lossage through NC (how they
can call 80% packet loss 'normal traffic' is beyond me) .. anyway ..

There was a posting yesterday on Bugtraq.  As near as I can tell, it was
about an attack directed at the realpath() bug.  The posting claimed to
work against all versions and derivitives of WU-FTPD, including
specificall VR. I can't get it to. Others on Bugtraq can't get it to.  
The author of the posting hasn't seen fit to do more than make that one
vague claim; no evidence, no daemon version numbers.  We (the wu-ftpd
group) are looking at the code to see if there's something else which
needs fixing.  All I can say right now is only one person has made a
claim, that claim looks unfounded, and he's not sharing. 

My bet, he doesn't even know which version of the daemon he's running.  He
may think he's running a VR version but here's his server's greeting:

220 dumb.admin.edu FTP server (Version wu-2.4.2-academ[BETA-18](1) Mon Aug 3 19:17:20 EDT 1998) ready.

[The name has been changed to protect the foolish.]

Um, isn't that the clean-build date and time from Redhat's RPM?  By golly,
I think it is.  Please, don't tell me the fool is complaining and he's
running a default-install from the RH CD.

Here's how the attack talked about in bugtraq works:

In a loop, MKD/CWD (make directory, create directory) until we're near the
limit MAXPATHLEN.  Do a MKD/CWD with the attack payload.  The payload
itself is not long enough to overflow a buffer.  It's trying to get the
daemon to overflow a buffer inside realpath() when rebuilding the full
pathname.

Let's say this attack does work.  Is there anything you can do to stop it?
Sure.  Don't allow world-writable directories in your FTP site.  Where you
must allow them, use proper upload clauses to limit the user's ability to
create subdirectories.

So, while there may be problems with the daemon (given the sorry state of
the code, can you blame it?) _this_ attack doesn't appear work and nobody
has any evidence there is one which _will_ work.

-- 

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