Re: poc zlib sploit just for fun :)
From: Kelledin (kelledin+BTQ@skarpsey.dyndns.org)
Date: 02/25/03
- Previous message: EAB: "RE: Ericsson HM220dp ADSL modem Insecure Web Administration Vulne rability"
- In reply to: Crazy Einstein: "poc zlib sploit just for fun :)"
- Next in thread: Ralf S. Engelschall: "Re: poc zlib sploit just for fun :)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Kelledin <kelledin+BTQ@skarpsey.dyndns.org> To: bugtraq@securityfocus.com Date: Mon, 24 Feb 2003 17:51:25 -0600
On Sunday 23 February 2003 12:38 pm, Crazy Einstein wrote:
> /*
> \ PoC local exploit for zlib <= 1.1.4
> / just for fun..not for root :)
> \
> / Usage: gcc -o zlib zlib.c -lz
> \
> / by CrZ [crazy_einstein@yahoo.com] lbyte
> [lbyte.void.ru]
> */
Ok, one simple proof of concept is enough. A second potentially
dangerous one (even for fun)...time to address this. ;)
Attached below is a patch RK and I whipped up yesterday, after I
caught wind of this problem sometime in the afternoon. It adds
extra code to properly gather the vsnprintf() return code if
available, and some ./configure checks to automatically set
macro definitions when it detects the requisite features. zlib
will still build if the host doesn't have the requisite
functions for full security, but ./configure will tell you about
how far you're bending over. The patch went through two
revisions to get to this level of completeness; it works as it
should on Linux==2.4.18/glibc>=2.2.5 but has not been tested on
other platforms.
RK and I both considered just completely dropping the vulnerable
codepaths; environments where zlib would have to fall back to
these codepaths honestly just don't deserve breathing rights.
But...I figure a fix isn't truly robust unless the fixed product
will still build on all the systems where it would build before.
At least now zlib builds secure-where-possible, instead of
broken-by-default.
During zlib ./configure, you should now see the following lines:
Checking whether to use vsnprintf() or snprintf()... using \
vsnprintf()
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
> #include <zlib.h>
> #include <errno.h>
> #include <stdio.h>
<snip harmless but potentially wicked Proof-of-Concept code>
>
>
> [crz@blacksand crz]$ gcc -o zlib zlib.c -lz
> [crz@blacksand crz]$ ./zlib
> [>] exploiting...
> [>] xret = 0xbffff8f0
> sh-2.05b$ exit
> exit
> [crz@blacksand crz]$
On vulnerable system:
[ kelledin@valhalla ~ ] # gcc -o zlibexp zlibexp.c -lz
[ kelledin@valhalla ~ ] # ./zlibexp
[>] exploiting...
[>] xret = 0xbffffaf0
sh-2.05a$ exit
exit
[ kelledin@valhalla ~ ] #
On patched system:
[ kelledin@valhalla /usr/src ] # ./zlibexp
[>] exploiting...
[>] xret = 0xbffffb50
>Sent!..
gzprintf -> 0
gzclose -> 0 [1]
[ kelledin@valhalla /usr/src ] #
The vulnerability consists of a buffer overflow and a
string-format vulnerability (in case something feeds '("Hello%c
there\n", '\0')' to gzprintf). Both should be fixed by the
patch below. How exploitable is this? Well, not very. The
gzprintf() function is seldom used, even on a fully loaded
system, so a would-be 0wner would likely have to code his own
app and trick the 0wnee into running it. I've got reliable
anecdotal evidence that ImageMagick calls gzprintf(), though I
haven't checked for myself.
-- Kelledin "If a server crashes in a server farm and no one pings it, does it still cost four figures to fix?"
- text/x-diff attachment: zlib-1.1.4-3-vsnprintf.patch
- Next message: Marc Ruef: "Re: Riched20.DLL attribute label buffer overflow vulnerability"
- Previous message: EAB: "RE: Ericsson HM220dp ADSL modem Insecure Web Administration Vulne rability"
- In reply to: Crazy Einstein: "poc zlib sploit just for fun :)"
- Next in thread: Ralf S. Engelschall: "Re: poc zlib sploit just for fun :)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
