Bugtraq mailing list archives
Re: poc zlib sploit just for fun :)
From: Kelledin <kelledin+BTQ () skarpsey dyndns org>
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?"
Attachment:
zlib-1.1.4-3-vsnprintf.patch
Description:
Current thread:
- poc zlib sploit just for fun :) Crazy Einstein (Feb 24)
- Re: poc zlib sploit just for fun :) Kelledin (Feb 25)
- <Possible follow-ups>
- Re: poc zlib sploit just for fun :) Ralf S. Engelschall (Feb 27)