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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 14 Aug 2003 11:01:50 -0700 (PDT)
From: Jane Smith <incidents2000@...oo.com>
To: Przemyslaw Frasunek <venglin@...ebsd.lublin.pl>,
	bugtraq@...urityfocus.com
Subject: 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@...ebsd.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@...sunek.com ** keyId: 2578FCAD |
> C0613BE3 | EC78FAB5 *
> 


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