COMMAND

    mget

SYSTEMS AFFECTED

    Most of them

PROBLEM

    On  most  Unix  platforms,  when  an  ftp client processes an mget
    command, it does  not check whether  the ftp server's  response to
    the NLST  command specifies  any directory  information along with
    the simple  list of  filenames required  by the  ftp protocol (RFC
    959,  section  4.1.3).   In  particular,  a malicious ftp server's
    NLST response  might include  lines such  as "../.forward",  which
    may be useful in a later  attack on the client machine by  someone
    who has control over the ftp server.

    Instead of .forward, one might also choose .profile, .cshrc, or
    .rhosts. NLST response lines beginning with '/' also work, which
    is of particular interest in cases where the ftp client is running
    as root.

    For example, if the client's session looks something like:

        % mkdir test
        % cd ~/test
        % ftp malicious-ftp-server
        ...
        ftp> dir
        ...
        total 560
        -rw-r--r--   1   103        22     106975 Jul 11 02:13 docs.tar.gz
        -rw-r--r--   1   103        22     452337 Jul 11 02:12 source.tar.gz
        226 Transfer complete.
        ...
        ftp> prompt
        Interactive mode off.
        ftp> mget .

    there's no guarantee that the files created on the client  machine
    will be limited  to docs.tar.gz and  source.tar.gz in the  current
    directory.  Instead,  files  might  be  created anywhere where the
    client  user  has  write  access,  possibly  including overwriting
    existing files.

    When setting up a malicious ftp server, it would probably be  most
    "useful" to  have a  directory that  contained a  large number  of
    small  files,  and  arrange  for  the  NLST  response  to  contain
    ../.forward somewhere in the middle. In this way, the  ../.forward
    line is not  noticeable when the  mget operation begins,  and will
    probably have scrolled off the user's screen by the time the  mget
    operation finishes. Thus, the client user won't realize that  this
    file has been created unless  they carefully read the entire  mget
    output.  Choosing a pathname other than ../.forward may be helpful
    if you  don't agree  that client  users most  typically start  ftp
    sessions from  a directory  exactly one  level beneath  their home
    directory.

    Also,  the  ftp  server  does  not  necessarily  need  to send the
    contents  of  a  file  named  ../.forward  in  response to a "RETR
    ../.forward"  command.   Instead,  the  ftp  server  may have been
    modified to send other text, perhaps text that isn't contained  in
    any file  accessible via  ftp.   Presumably, the  text will  begin
    with '|' so  that there's some  chance that sending  e-mail to the
    client will be successful in causing some arbitrary command to  be
    run. (if you're  going to write  something to .forward,  you might
    want to write it to .qmail as well).  Credit goes to Matt Power.

SOLUTION

    There is one exception. With the AIX 3.2 ftp client, the mget  did
    not create ../.forward, but instead created a .forward file in the
    client's  current  directory.  Similarly,  with  an AIX ftp client
    running as  root, and  an NLST  response line  of /etc/passwd,  it
    created a  file named  passwd in  the current  directory. In other
    words, it's possible, although not  confirmed, that AIX is not  at
    all vulnerable to this problem.  The 10 other Unix platforms  that
    were tested are all vulnerable.

    Perhaps the easiest  solution is to  fix the ftp  client to ignore
    lines in  an NLST  response that  include a  '/' character.  Until
    your  ftp  client  is  fixed,  it  would  be  best  to avoid doing
    non-interactive mgets from any ftp  server that isn't known to  be
    trustworthy. One  might initially  think that  a useful workaround
    is to  examine the  server's NLST  output by  issuing the  command
    "ls" (rather than only  "dir") before transferring any  files. The
    problem here  is that  the ftp  server might  have a  time-varying
    NLST response  (e.g., possibly  it includes  the line  ../.forward
    only the second time that NLST is sent).