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-ftpdat_private .. 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+wuftpdat_private Kettering, OH 45409-1615 USA 1-800-809-2195
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:40:03 PDT