Exploit for proftpd 1.2.0pre6

From: Tymm Twillman (tymmat_private)
Date: Mon Sep 20 1999 - 12:31:51 PDT

  • Next message: Holger Heimann: "Re: NAI Security Advisory - Windows IP source routing"

    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.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:04:40 PDT