Likes Likes:  0
Resultaten 1 tot 4 van de 4
Geen
  1. #1
    Janusz Niewiadomski
    wu-ftpd fb_realpath() off-by-one bug
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    wu-ftpd fb_realpath() off-by-one bug


    Synopsis: wu-ftpd fb_realpath() off-by-one bug
    Product: wu-ftpd
    Version: 2.5.0 <= 2.6.2
    Vendor: http://www.wuftpd.org/

    URL: http://isec.pl/vulnerabilities/isec-0011-wu-ftpd.txt
    CVE: http://cve.mitre.org/cgi-bin/cvename...=CAN-2003-0466
    Author: Wojciech Purczynski <cliph@isec.pl>
    Janusz Niewiadomski <funkysh@isec.pl>
    Date: July 31, 2003


    Issue:
    ======

    Wu-ftpd FTP server contains remotely exploitable off-by-one bug. A local
    or remote attacker could exploit this vulnerability to gain root
    privileges on a vulnerable system.


    Details:
    ========

    An off-by-one bug exists in fb_realpath() function. An overflow occurs
    when the length of a constructed path is equal to the MAXPATHLEN+1
    characters while the size of the buffer is MAXPATHLEN characters only.
    The overflowed buffer lies on the stack.

    The bug results from misuse of rootd variable in the calculation of
    length of a concatenated string:

    ------8<------cut-here------8<------
    /*
    * Join the two strings together, ensuring that the right thing
    * happens if the last component is empty, or the dirname is root.
    */
    if (resolved[0] == '/' && resolved[1] == '\0')
    rootd = 1;
    else
    rootd = 0;

    if (*wbuf) {
    if (strlen(resolved) + strlen(wbuf) + rootd + 1 > MAXPATHLEN) {
    errno = ENAMETOOLONG;
    goto err1;
    }
    if (rootd == 0)
    (void) strcat(resolved, "/");
    (void) strcat(resolved, wbuf);
    }
    ------8<------cut-here------8<------

    Since the path is constructed from current working directory and a file
    name specified as an parameter to various FTP commands attacker needs to
    create deep directory structure.

    Following FTP commands may be used to cause buffer overflow:

    STOR
    RETR
    APPE
    DELE
    MKD
    RMD
    STOU
    RNTO

    This bug may be non-exploitable if size of the buffer is greater than
    MAXPATHLEN characters. This may occur for example if wu-ftpd is compiled
    with some versions of Linux kernel where PATH_MAX (and MAXPATHLEN
    accordingly) is defined to be exactly 4095 characters. In such cases,
    the buffer is padded with an extra byte because of variable alignment
    which is a result of code optimization.

    Linux 2.2.x and some early 2.4.x kernel versions defines PATH_MAX to be
    4095 characters, thus only wu-ftpd binaries compiled on 2.0.x or later 2.4.x
    kernels are affected.


    Exploit:
    ========

    We investigated and successfully exploited this vulnerability on x86 based
    Linux system running 2.4.19 kernel. We believe that exploitation of other
    little-endian systems is also possible.


    Impact:
    =======

    Authenticated local user or anonymous FTP user with write-access could
    execute arbitrary code with root privileges.


    Vendor Status:
    ==============

    June 1, 2003 security@wu-ftpd.org has been notified
    June 9, 2003 Request for confirmation of receipt sent to security@wu-ftpd.org
    June 11, 2003 Response received from Kent Landfield
    July 3, 2003 Request for status update sent
    July 19, 2003 vendor-sec list notified
    July 31, 2003 Coordinated public disclosure


    The Common Vulnerabilities and Exposures project (cve.mitre.org) has
    assigned the name CAN-2003-0466 to this issue.

    --
    Janusz Niewiadomski
    iSEC Security Research
    http://isec.pl/



  2. #2
    mteshome
    wu-ftpd fb_realpath() off-by-one bug
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: wu-ftpd fb_realpath() off-by-one bug

    > We believe that exploitation of other little-endian systems is also
    possible.

    Are big-endian systems vulnerable as well, or just little-endina systems?


  3. #3
    Przemyslaw Frasunek
    wu-ftpd fb_realpath() off-by-one bug
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: wu-ftpd fb_realpath() off-by-one bug

    U¿ytkownik Janusz Niewiadomski napisa³:
    > This bug may be non-exploitable if size of the buffer is greater than
    > MAXPATHLEN characters. This may occur for example if wu-ftpd is compiled
    > with some versions of Linux kernel where PATH_MAX (and MAXPATHLEN
    > accordingly) is defined to be exactly 4095 characters. In such cases,
    > the buffer is padded with an extra byte because of variable alignment
    > which is a result of code optimization.


    Actually, this bug is (probably) also non-exploitable when wu-ftpd is
    compiled using the gcc 3.x, which aligns stack variables in a different way:

    (gdb) b fb_realpath
    Breakpoint 1 at 0x8063c72: file realpath.c, line 103.
    (gdb) cont
    Continuing.
    (gdb) x/bx &resolved[4096]
    0xbfffc770: 0x00
    (gdb) awatch *0xbfffc770
    Hardware access (read/write) watchpoint 2: *3221210992
    (gdb) cont
    Continuing.
    Hardware access (read/write) watchpoint 2: *3221210992

    Value = 0
    0x400d81d9 in strcat () from /lib/libc.so.6

    In my example (wu-ftpd 2.6.2 compiled on Debian with gcc 3.3.1), the
    address of NULL-overflowed byte is 0xbfffc770 and the saved %ebp is located
    at 0xbfffc788:

    (gdb) info frame 2
    Stack frame at 0xbfffc788:
    eip = 0x8063ae4 in wu_realpath (realpath.c:60); saved eip 0x8053b35
    called by frame at 0xbfffe7d8, caller of frame at 0xbfffb748
    source language c.
    Arglist at 0xbfffc788, args: path=0x808cef0 'A' <repeats 200 times>...,
    resolved_path=0xbfffc7a0 "\001\001", chroot_path=0x8082e60 ""
    Locals at 0xbfffc788, Previous frame's sp in esp
    Saved registers:
    ebx at 0xbfffc784, ebp at 0xbfffc788, eip at 0xbfffc78c

    I have tested the generic RedHat 8.0 (which provides wu-ftpd-2.6.2-5
    compiled with gcc 3.x) and the behaviour was exactly the same.

    Wu-ftpd suppiled with Debian Woody also seems to be non-exploitable -- it's
    compiled on kernel 2.2 with PATH_MAX 4095.

    --
    * Fido: 2:480/124 ** WWW: http://www.frasunek.com/ ** NIC-HDL: PMF9-RIPE *
    * Inet: przemyslaw@frasunek.com ** keyId: 2578FCAD | C0613BE3 | EC78FAB5 *


  4. #4
    Jane Smith
    wu-ftpd fb_realpath() off-by-one bug
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: wu-ftpd fb_realpath() off-by-one bug

    Hi,

    I've got an AIX 5.2 server running wu-ftp 2.6.2. I
    found the "patch" for wu-ftp in the www.wu-ftpd.org
    website. I modified my source as they indicated for
    the off-by-one vulnerability and the DOS vulnerability
    they described. I then re-compiled (./configure;
    make; make install). The problem is the new ftpd
    binary does not work correctly. When I use it, if I
    type "ls -l" (or ls -<any flag>) I get an error: 550
    Not enough space.
    There's plenty of space in all file systems. Any
    advice on how to fix this problem or how to go about
    troubleshooting it?

    Vania
    --- Przemyslaw Frasunek <venglin@freebsd.lublin.pl>
    wrote:
    > U¿ytkownik Janusz Niewiadomski napisa³:
    > > This bug may be non-exploitable if size of the

    > buffer is greater than
    > > MAXPATHLEN characters. This may occur for example

    > if wu-ftpd is compiled
    > > with some versions of Linux kernel where PATH_MAX

    > (and MAXPATHLEN
    > > accordingly) is defined to be exactly 4095

    > characters. In such cases,
    > > the buffer is padded with an extra byte because of

    > variable alignment
    > > which is a result of code optimization.

    >
    > Actually, this bug is (probably) also
    > non-exploitable when wu-ftpd is
    > compiled using the gcc 3.x, which aligns stack
    > variables in a different way:
    >
    > (gdb) b fb_realpath
    > Breakpoint 1 at 0x8063c72: file realpath.c, line
    > 103.
    > (gdb) cont
    > Continuing.
    > (gdb) x/bx &resolved[4096]
    > 0xbfffc770: 0x00
    > (gdb) awatch *0xbfffc770
    > Hardware access (read/write) watchpoint 2:
    > *3221210992
    > (gdb) cont
    > Continuing.
    > Hardware access (read/write) watchpoint 2:
    > *3221210992
    >
    > Value = 0
    > 0x400d81d9 in strcat () from /lib/libc.so.6
    >
    > In my example (wu-ftpd 2.6.2 compiled on Debian with
    > gcc 3.3.1), the
    > address of NULL-overflowed byte is 0xbfffc770 and
    > the saved %ebp is located
    > at 0xbfffc788:
    >
    > (gdb) info frame 2
    > Stack frame at 0xbfffc788:
    > eip = 0x8063ae4 in wu_realpath (realpath.c:60);
    > saved eip 0x8053b35
    > called by frame at 0xbfffe7d8, caller of frame at
    > 0xbfffb748
    > source language c.
    > Arglist at 0xbfffc788, args: path=0x808cef0 'A'
    > <repeats 200 times>...,
    > resolved_path=0xbfffc7a0 "\001\001",
    > chroot_path=0x8082e60 ""
    > Locals at 0xbfffc788, Previous frame's sp in esp
    > Saved registers:
    > ebx at 0xbfffc784, ebp at 0xbfffc788, eip at
    > 0xbfffc78c
    >
    > I have tested the generic RedHat 8.0 (which provides
    > wu-ftpd-2.6.2-5
    > compiled with gcc 3.x) and the behaviour was exactly
    > the same.
    >
    > Wu-ftpd suppiled with Debian Woody also seems to be
    > non-exploitable -- it's
    > compiled on kernel 2.2 with PATH_MAX 4095.
    >
    > --
    > * Fido: 2:480/124 ** WWW: http://www.frasunek.com/
    > ** NIC-HDL: PMF9-RIPE *
    > * Inet: przemyslaw@frasunek.com ** keyId: 2578FCAD |
    > C0613BE3 | EC78FAB5 *
    >



    __________________________________
    Do you Yahoo!?
    Yahoo! SiteBuilder - Free, easy-to-use web site design software
    http://sitebuilder.yahoo.com

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics