Fw: Re: poc zlib sploit just for fun :)

[Niki Guldbrand]

Begin forwarded message:

Date: Mon, 24 Feb 2003 17:51:25 -0600
From: Kelledin <kelledin+BTQ at skarpsey.dyndns.org>
To: bugtraq at securityfocus.com
Subject: Re: poc zlib sploit just for fun :)


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 at 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 at blacksand crz]$ gcc -o zlib zlib.c -lz
> [crz at blacksand crz]$ ./zlib
> [>] exploiting...
> [>] xret = 0xbffff8f0
> sh-2.05b$ exit
> exit
> [crz at blacksand crz]$

On vulnerable system:

[ kelledin at valhalla ~ ] # gcc -o zlibexp zlibexp.c -lz
[ kelledin at valhalla ~ ] # ./zlibexp
[>] exploiting...
[>] xret = 0xbffffaf0
sh-2.05a$ exit
exit
[ kelledin at valhalla ~ ] #

On patched system:

[ kelledin at valhalla /usr/src ] # ./zlibexp
[>] exploiting...
[>] xret = 0xbffffb50
>Sent!..
gzprintf -> 0
gzclose -> 0 [1]
[ kelledin at 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?"


-- 
Med Venlig Hilsen / Best Regards
                              |  Teleservice Esbjerg A/S
Niki Guldbrand                |  Salingsundvej 4
IT-Administrator              |  6715 Esbjerg N
                              |  Denmark
Phone         : +45 79144544  |
Direct Phone  : +45 79144589  |  Web : http://www.teleservice.com
Fax           : +45 79144599  |

E-Mail        : Niki.Guldbrand at teleservice.com

--------------
enhance, v.:
	To tamper with an image, usually to its detriment.
--------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib-1.1.4-3-vsnprintf.patch
Type: text/x-diff
Size: 10190 bytes
Desc: not available
Url : http://lunar-linux.org/mailman/private/lunar-dev/attachments/20030226/327d940f/zlib-1.1.4-3-vsnprintf-0001.bin