Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (File Transfer/Sharing)  >   FTP (Generic) Vendors:   OpenBSD, SGI (Silicon Graphics), Sun, [Multiple Authors/Vendors]
Several FTP Clients Have an Input Validation Flaw That May Let Malicious Servers Write Files to Arbitrary Locations
SecurityTracker Alert ID:  1005794
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Dec 12 2002
Impact:   Modification of system information, Modification of user information

Description:   An input validation vulnerability was reported in several FTP client implementations, including those from Sun Microsystems, OpenBSD, SGI and other vendors. A remote FTP server may be able to write files to arbitrary locations when the wget client retrieves files from the FTP server.

Steve Christey reported that a malicious FTP server containing files with specially crafted filenames could exploit a flaw in several FTP client implementations. When a target user attempts to download a file from a malicious server, the specially crafted filename may cause the client to create a file or overwrite a file in a directory on the target user's system that is located outside of the current working directory. The write location on the target system is specified by the malicious filename and is subject to the permissions of the target user.

While the target user must request that the malicious file be downloaded, the filename may be obscured or the user may be unaware of the filename (e.g., mget requests).

Impact:   A malicious FTP server may be able to cause the target user's client to write a file being downloaded by the target user to an arbitrary location on the target user's computer.
Solution:   Solutions, workarounds, or countermeasures are pending from several vendors. See the Message History section or subsequent follow-up alerts for information on those solutions.
Cause:   Input validation error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   None.

 Source Message Contents

Subject:  Directory Traversal Vulnerabilities in FTP Clients

___ Summary __________________________________________________________

        Title: Directory Traversal Vulnerabilities in FTP Clients
         Date: December 10, 2002
       Author: Steve Christey (
     Revision: 1.3

      Product: Multiple FTP and web clients
  OS/Platform: Multiple
       Vendor: Multiple
Vendor Status: Vendors informed individually and through CERT/CC
         Risk: Medium.  A malicious server could potentially overwrite
               key files to cause a denial of service or, in some
               cases, gain privileges by modifying executable files.
               The risk is mitigated because non-default
               configurations are primarily affected, and the user
               must be convinced to access the malicious server.
               However, web-based clients may be more easily exploited
               using server-side vulnerabilities such as XSS.

FTP clients, including those that may be embedded in web clients, can
be vulnerable to certain directory traversal attacks by modified FTP
servers.  If successful, the attacks could allow the server to
overwrite or create arbitrary files outside of the client's working
directory, subject to file/directory permissions and the privilege
level of the client.

Multiple clients are affected.  See "Test Results" for the list of

___ Introduction _____________________________________________________


  A colleague of mine selected a bunch of files from an "ftp://" URL
  and copied them to a folder en masse.


  FTP clients haven't been reported as being vulnerable to directory
  traversal conditions.

Correction based on further investigation:

  In 1997, some FTP clients were reported as being vulnerable to
  directory traversal conditions [1].


  Some FTP clients are still vulnerable to directory traversal


  The task would involve creating a malicious FTP server that would
  send filenames with "../" and other sequences as the result of a
  "LIST" request, or a "multiple GET" request.  The client might then
  download these files into some parent directory.

___ Testing Methodology ______________________________________________

This methodology is a simplification of the PROTOS methodology as
developed by the Oulu University Secure Programming Group [2], in
which a test suite is developed for a particular protocol, and the
suite is then used against specific implementations.  The PROTOS
methodology has proven effective in finding large numbers of
vulnerabilities in many different products that implement standard
networking protocols.

For a simple test suite, the "ftp4all" FTP server was modified to
return filenames of various forms that might cause files to be created
outside a client's working directory.  ftp4all was chosen because it
was easy to install and it allowed non-root users to run an FTP server
on a port other than 21.

The files src/ftps/list.c, serverd.c, and transfer.c were changed to
produce modified filenames, and to return the same test file for any
filename that the client requests.

When a client sends a LIST or NLST command, the test server returns
filenames containing the following sequences:

  "../"   - classic traversal
  "/path" - an absolute pathname
  "..\"   - backslash traversal pattern (Windows systems)
  "C:"    - Drive letter traversal (Windows systems)
  "..."   - "triple-dot" (Windows systems, equivalent to ../..)

When downloading a group of files using wildcards, the FTP client
typically performs an "NLST" command, reads the list of files returned
by the server, and uses those filenames to make individual requests.

Note that web clients may also be affected if they can process
"ftp://" URLs.

Demonstration Session

Following is a simulated session to demonstrate how a vulnerable
client may behave.

  220 FTP4ALL FTP server ready. Local time is Tue Oct 01, 2002 20:59.
  Name (server:username): test
  331 Password required for test.
  230-Welcome, test - I have not seen you since Tue Oct 01, 2002 20:15 !
  230 At the moment, there are 0 guest and 1 registered users logged in.

  257 "/" is current directory.

CLIENT> ls -l
  200 PORT command successful.
  150 Opening ASCII mode data connection for /bin/ls.
  total 1
  -rw-r-----   0 nobody    nogroup          0 Oct 01 20:11 ...\FAKEME5.txt
  -rw-r-----   0 nobody    nogroup          0 Oct 01 20:11 ../../FAKEME2.txt
  -rw-r-----   0 nobody    nogroup          0 Oct 01 20:11 ../FAKEME1.txt
  -rw-r-----   0 nobody    nogroup          0 Oct 01 20:11 ..\..\FAKEME4.txt
  -rw-r-----   0 nobody    nogroup          0 Oct 01 20:11 ..\FAKEME3.txt
  -rw-r-----   0 nobody    nogroup          0 Oct 01 20:11 /tmp/ftptest/FAKEME6.txt
  -rw-r-----   0 nobody    nogroup          0 Oct 01 20:11 C:\temp\FAKEME7.txt
  -rw-r-----   0 nobody    nogroup         54 Oct 01 20:10 FAKEFILE.txt
  -rw-r-----   0 nobody    nogroup          0 Oct 01 20:11 misc.txt
  226 Directory listing completed.


  Opening ASCII data connection for FAKEFILE.txt...
  Saving as "FAKEFILE.txt"

  Opening ASCII data connection for ../../FAKEME2.txt...
  Saving as "../../FAKEME2.txt"

  Opening ASCII data connection for /tmp/ftptest/FAKEME6.txt...
  Saving as "/tmp/ftptest/FAKEME6.txt"


If a client is vulnerable, it saves files outside of the user's
current working directory.

Testing Notes

For command-line FTP clients, the client was tested in the following

  - log onto FTP server
  - set no-interactive prompt
  - perform "mget" (multiple GET) or equivalent command

In some cases, an FTP client would produce an error as soon as it
encountered a suspicious filename, and skip the remaining filenames.
Thus one could not be certain if the client was vulnerable to other
filenames.  If a client demonstrated this behavior, then the server
was modified to send a single suspicious filename at a time, and the
client would be executed multiple times.

Other variants of directory traversal sequences were not tested, as
there were not sufficient resources to conduct such a comprehensive
analysis in a timely fashion.  See [3] for examples.

It is possible that web clients may be vulnerable to the same type of
issue from malicious HTTP servers, when the clients are used to
automatically download web pages.  However, this was not tested.

___ Test Results _____________________________________________________

The following products were specifically tested by the author.
Descriptions of this class of problem were reported to CERT/CC and
major vendors.  Most vendors did not report results back to the
author.  Consult your vendor, or the associated CERT vulnerability
note, if your product is not listed here.


   Product              ../  ..\    C:   /path    ...
   -------------        ---  ---    ---  -----    ---
   wget 1.8.1           yes   no     no    yes{4}  no
   wget 1.7.1           yes   no     no     no{2}  no
   OpenBSD 3.0 FTP      yes   no{1}  no{1} yes     no
   Solaris 2.6, 7       yes   no     no    yes     no

   The ftp command on SGI systems is also subject to one or more
   flavors of directory traversal attacks.  However, details were not
   available at the time that this advisory was published.

Not Vulnerable:

   Product              ../  ..\    C:   /path    ...
   -------------        ---  ---    ---  -----    ---
   Red Hat 7.1          no{3} no{3}  no{3}  no{3}  no
   Debian 2.4.16        no{3} no{3}  no{3}  no{3}  no
   NT SP5 command line  no    no     no     no     no
   XP command (no SP)   no    no     no     no     no
   lftp 2.6.2           no    no{1}  no{1}  no     no
   NcFTP 3.1.4          no    no     no     no     no
   Lynx 2.8.1           [FTP traversal not available]


  {1} installed the file in the current directory

  {2} created subdirectories within the current directory

  {3} generated error message and/or stopped downloading

  {4} only with the -nH option ("Disable host-prefixed directories")

Other notes on wget:

  1) "wget" was tested with the -r (recursive) option.

  2) When provided with an FTP URL on the command line, it is subject
     to "../" traversal

  3) If there's an FTP link within a web page, it will not follow the
     links, and is not subject to traversal

  4) HOWEVER, if the --follow-ftp option is used, it is subject to
     "../" traversal

  5) When both --follow-ftp and -nH are used, wget is also subject to
     "/path" traversal

  6) wget 1.7.1 was not tested for the -nH absolute path issue, or for
     FTP URL's in web pages

___ Patches, Workarounds, and Vendor Statements ______________________


  Some clients may have one or more of the following features.  If so,
  then enabling these features could notify the user if an attack
  occurs, and allow the user to take defensive action.

  These features may be explicitly disabled if the client is being
  called from a script or other program that does not require user

  1) The user may be able to set the client to prompt the user when an
     existing file is to be overwritten.  This is typically a default

  2) A command such as "runique" may be available to force the client
     to use a different filename instead of overwriting an existing

Sun FTP client:

   Statement from Sun

   We have investigated this directory traversal issue and do not
   think it is a bug.  
   The user has several means of protection against this issue.

   1. By default prompting is turned on, so the user gets a chance to
   decide if they want a file returned by mget before it is
   downloaded. So files will not be overwritten without prompting the

   2. When running as an ordinary user, Unix access controls will stop
   system files being over written. If a user must run as root, care
   needs to be taken which would include not turning off interactive

   3. The user may run the "runique" command to force the Solaris ftp
   client to avoid overwriting files that already exist.

   The Solaris ftp mget behaviour is consistent with other BSD derived
   ftp clients, for example on Linux and FreeBSD.  Changing the
   existing behaviour will cause problems.

SGI FTP client:

  SGI acknowledged the vulnerability via email and is likely to have a
  public acknowledgement near the time of this disclosure.


   Vendor statement (Theo de Raadt):

    "I've forwarded the report to the person who copes with that
     stuff.  I do not consider this all that serious."


  Red Hat Linux has released advisory RHSA-2002:229 at:

  The status of other Linux vendors was unknown at the time this
  advisory was published.

___ Vulnerability Identifiers ________________________________________

The following identifiers have been assigned to these issues.


    CVE - CAN-2002-1344  [4]
    CERT VU - VU#210148  [5]

  FTP command-line clients (UNIX):

    CVE - CAN-2002-1345  [6]
    CERT VU - VU#210409  [7]

The CVE numbers were assigned by the Common Vulnerabilities and
Exposures (CVE) project.  These are candidates for inclusion in the
CVE list, which standardizes names for security problems

The CERT VU numbers were assigned by CERT/CC and will be accessible in
the Vulnerability Notes database (

Additional identifiers will be assigned to separate packages if

___ Research and Disclosure History __________________________________

The disclosure of this issue has been conducted in accordance with the
Christey/Wysopal "Responsible Vulnerability Disclosure Process" draft,
which has expired [8].

Since multiple vendors and products were affected, the research and
disclosure history for this issue is extensive.  The total amount of
time required for research, vendor notification, and coordination is
estimated to be 50 hours.

Research and General Notification
Sep 25, 2002 - issue theorized
Sep 27, 2002 - modified FTP server created; initial tests
Oct  1, 2002 - notified vendor-sec with various responses
Oct 10, 2002 - sent update to CERT/CC
Oct 11, 2002 - CERT/CC reply
Dec  2, 2002 - notified CERT/CC of status
Dec  2, 2002 - set release date of December 10, notified all parties
Dec  5, 2002 - received CERT ID (VU#210409) for issue
Dec  9, 2002 - more edits
Dec  9, 2002 - CVE ID's sent to vendor-sec

Sun (CVE: CAN-2002-1345)
Sep 27, 2002 - Sun ftp client issue discovered
Sep 30, 2002 - Notified Sun
Sep 30, 2002 - CERT/CC notified of Sun issue
Oct  1, 2002 - initial response from Sun (within 1 day)
Oct  1, 2002 - provided fake FTP server to Sun
Oct  7, 2002 - additional info from Sun
Nov 18, 2002 - response from Sun; will not address issue, as other
               protections are already available
Dec  2, 2002 - suggested "vendor statement" to Sun
Dec  4, 2002 - Sun provides final statement

SGI (CVE: CAN-2002-1345)
Oct  1, 2002 - provided fake FTP server to SGI
Nov  5, 2002 - inquiry by SGI on release status
Nov 27, 2002 - SGI inquires about release date
Dec  2, 2002 - response to SGI; set release to Dec 10?
Dec  9, 2002 - CVE candidate acquired, sent to SGI

OpenBSD (CVE: CAN-2002-1345)
Oct  1, 2002 - OpenBSD client issue discovered
Oct  1, 2002 - notified OpenBSD (
Dec  2, 2002 - second notification to OpenBSD
Dec  2, 2002 - response from Theo de Raadt (original message was lost)
Dec  2, 2002 - report forwarded to other OpenBSD maintainers

wget  (CVE: CAN-2002-1344)
Note: notification and resolution of the wget issue was handled
primarily through Mark Cox of Red Hat Linux, not the package

Sep 30, 2002 - wget issue discovered
Sep 30, 2002 - notified Mark Cox (Red Hat) of wget issue
Oct  1, 2002 - found wget absolute path issue
Oct  2, 2002 - provided fake web server to Red Hat
Oct  6, 2002 - notified wget developer (
Nov  7, 2002 - inquiry by Red Hat on release status for wget; still
               haven't heard back from, need to
               consider other options
Nov 25, 2002 - Red Hat notifies that wget patches are ready
Dec  2, 2002 - notification to wget developer; new email address
               found by Red Hat; developer is mostly inactive
Dec  9, 2002 - CVE ID acquired, sent to Red Hat

Other Activities
Oct  1, 2002 - provided fake FTP server to Solar Designer
Oct  1, 2002 - briefly tested lftp
Oct  9, 2002 - received report that ncftp is vulnerable to /abs/path
               in the -R option; checked 3.1.4, doesn't seem to be an
               issue - "-R /" is interpreted as / on local system, so
               all pathnames would be "legal"; no response to followup

___ References _______________________________________________________

[1] "security hole in mget (in ftp client)"
    Bugtraq mailing list
    August 5, 1997

[2] OUSPG: Oulu University Secure Programming Group

[3] "A 'straw man' vulnerability auditing checklist"
    Steve Christey
    SecProg mailing list
    December 5, 2002






___ EOF ______________________________________________________________


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC