Date: Tue, 2 Mar 2004 19:34:57 +0000 (GMT) From: =?iso-8859-1?q?Shaun=20Colley?= <shaunige@yahoo.co.uk> Subject: Coreutils 'dir' integer overflow vulnerability. To: bugtraq@securityfocus.com ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Product: Coreutils 'dir' - versions < 5.2.0 http://www.gnu.org Versions: < 5.2.0 (**see "Vulnerable Versions" for very important info on versions vulnerable!**) Bug: DoS / possible arbitrary code execution. Impact: Attacker's can cause MASS consumption of CPU utilisation and usage of memory, by corrupting the stack. Possible code execution. Date: March 02, 2004 Author: Shaun Colley Email: shaunige@yahoo.co.uk WWW: http://www.nettwerked.co.uk ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Introduction ############# GNU Coreutils is a set of standard utilities included in all Linux distributions, with a set of useful tools. These include: - ls - cat - date - yes - who - wc - dir - vdir - chown - chmod - echo and so on... A while ago, an integer overflow vulnerability was found in 'ls' by Georgi Guninski, allowing an attacker to consume CPU resources due to stack corruption, and *potentially* execute arbitrary code remotely (due to usage of 'ls' by Internet daemons like 'WU-FTPD'). Fixed packages were supplied by major Linux distribution vendors (and other UNIX-like OSes and UNIX variants), which fixed the integer overflow issue. After auditing 'dir' on a slightly older version of Coreutils, 4.1.11, I discovered 'dir' to be vulnerable to an almost identical attack. On the updated Coreutils packages supplied by Linux distribution vendors, and on the latest version of Coreutils (5.2.0), this issue in 'dir' *HAS* been fixed (likely because 'dir' uses some of 'ls's code), but for some reason, the community *WAS NOT* alerted of this vulnerability. The bug ######## This bug occurs in the handling of arguments passed to 'dir' via the '-w' flag (the 'width' flag) at the shell. If an overly long integer is passed to 'dir' with the -w flag, the stack is corrupted, and large amounts of CPU utilisation are consumed. Although unlikely, if programs which invoke 'dir' allow passing of arguments via the '-w' flag, it is possible that arbitrary code execution is possible, although unconfirmed. CPU utilisation mass consumed by 'dir' due to the corruption of the stack can reach close to, or equal to, 100% usage, allowing complete DoS to be performed by a potential attacker. The vulnerability is due to bad handling of command line arguments, causing an integer overflow - causing the program stack and memory to be corrupted. The exploit ############ A proof-of-concept to verify the issue in your version of Coreutils is the command shown below: ## bash$ dir -w 1073741828 ## If the host's version of Coreutils is vulnerable, mass CPU utilisation will be used, and if invoked via a debugging tool such as 'Valgrind', one can see the consequences of the integer overflow taking place. The fix ######## The solution for this issue is to upgrade to the latest GNU Coreutils package. www.gnu.org Optionally, you can use the Coreutils packages supplied by your Linux distribution vendor. Grab the RPMs, and issue the following command: ## root# rpm -Uhv <coreutils-rpm> ## Re-invoke the proof-of-concept 'dir' command shown above, and the issue should be resolved. Vulnerable Versions #################### During October 2003, Georgi Guninski discovered a similar (almost identical) integer overflow in 'ls', which led the the release of fixed Coreutils packages, fixing the 'ls' integer overflow, AND THE INTEGER OVERFLOW IN 'dir'. Perhaps it was never realised that 'dir' was vulnerable, but the fact remains is that it is. (The caps below are to ensure that the important information is read, not to imply shouting.) USERS WHO UPGRADED WHEN FIXED Coreutils PACKAGES WERE RELEASED TO FIX THE 'ls' INTEGER OVERFLOW VULNERABILITY ARE IMMUNE TO THIS VULNERABILITY, AND THEREFORE DO NOT NEED TO UPGRADE! Users who did not upgrade are *still* vulnerable to this similar (but different, since 'dir' is a different program) vulnerability. I advise you upgrade, as recommended above. Credit ####### This vulnerability was discovered by Shaun Colley / shaun2k2. Thank you for your time. Shaun.
waiting for pebenito to test 5.2.0 before I release it into portage
dir was fixed when ls was fixed. This doesn't affect us currently.
it doesn't seem like our coreutils have this, and 5.2.0 is in portage now (well, in half an hour on rsync systems)
