COMMAND

    WFTPD

SYSTEMS AFFECTED

    WFTPD 32-bit (X86) 3.00 R5, probably others

PROBLEM

    'ByteRage' found following.

    Directory Traversal
    ===================
    WFTPD v3.00  R5 is  vulnerable to  a directory  traversal bug that
    allows  remote  users  to  browse  through  any  directory  on the
    victim's harddrive.  This is possible by sending the command:

        CD .../

    as much as needed to go up in the directory tree then you can  map
    out the current directory contents via

        LS

    and dive into the subdirs with CD, using GET to retrieve the files
    of your liking.

    For the examples given here,  we used windows' FTP.EXE program  as
    the client, most commands are not the ones interpreted by the  ftp
    server, but  commands to  FTP.EXE, actually  LS would  be LIST, ls
    would be NLST, CD would be CWD, LS -d would be LIST -d, etc...

    Buffer Overflow / DoS
    =====================
    WFTPD also  contains a  buffer overflow  condition when  trying to
    map out a directory containing a very long filename, combined with
    our path full of dots : an internal buffer overflow will overwrite
    some registers at about 250  chars.  Users that have  write access
    (to their home dir for  example, default permission) can create  a
    special 'overflow' file, and then map out the directory using  LS,
    effectively causing a DoS. The buffer overflow may be  exploitable
    and be used to gain SYSTEM privileges to the remote host.

    In brief, when we would want to exploit the bof we would:
    - First have to find out what our homedir's name is on the  victim
      machine, because our buffer consists of something like:

        C:\OUR_HOMEDIR_BUT_WE_DONT_KNOW_THE_LENGTH\............\OUR_HOMEDIR_BUT_WE_DONT_KNOW_THE_LENGTH\FILE_WITH_LONG_FILENAME_WHICH_WE_HAVE_CREATED_THAT_MAKES_THE_OVERFLOW_HAPPEN

      So, basically, we need to know the length of the home  directory
      to know where our EIP is at... Using the traversal bug,  listing
      out the directory contents, we can figure this out.  In practice
      it might be  easier to find  this out but  this is just  a first
      idea...
    - Then we would login as  the same user, create the file  with the
      long filename in our homedirectory, go to root (\) using as much
      dots as  needed to  position our  new EIP,  going back  into our
      homedirectory  and  issuing  an  LS  command, causing the buffer
      overflow.

    So,

        CD .................................................................../
        CD homedir
        LS

    or even easier just doing something like

        CD ............../
        LS
        CD ....................................................................................../
        LS
        CD ......................................./
        LS

    etc... will make  wftpd crash eventually,  as the dots  always get
    appended to the buffer.  We have tested this bug on Windows 98.

    There is also  a similar buffer  overflow (at another  place) when
    doing this:

        MKDIR AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        CD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        LS -d

    (the  homedir  of  the  user  was  C:\RESTRICTED\, this also might
    affect the  buffer overflow  results) As  you can  see, here,  the
    directory traversal bug is not needed, hence it is likely to  work
    under NT / 2k...

SOLUTION

    The vendor has found a workaround for the directory traversal  bug
    and put the following information on their site (www.wftpd.com):

        "5/24/2001 - Directory traversal vulnerability - Windows 95, 98, ME.
        As  noted  in  the  "What's  New"  section  of our most recent
        version,  3.00  R5,  there  is  indeed  an  effect  on WFTPD's
        behaviour caused  by the  new path  name expansion  code.   On
        Windows 95, 98, and ME, the string "..." is understood by  the
        operating system to  mean "up two  directories" - this  is not
        currently expanded out in our  code, and is hence passed  into
        the operating  system, leading  to the  ability of  a user  to
        venture  outside  of  his/her  restrictions,  and  possibly to
        touch files not in accordance with defined rights.  Again,  as
        noted in the "What's New"  section of our help file,  this can
        be  disabled  by  adding  the  entry  "GFPNMethod=0"  to  your
        WFTPD.INI file,  in the  "[Server]" section.   If you  do  not
        have a "[Server]" section, then it can be created anywhere  in
        the file.  Do not  create two sections labeled "[Server]",  as
        only the first will be accessed.