Fwd: buffer overrun in zlib 1.1.4

Kelledin kelledin+LFS at skarpsey.dyndns.org
Sun Feb 23 17:24:26 PST 2003


On Sunday 23 February 2003 06:51 pm, Kelledin wrote:
> I thought we should take note of this and make sure we take
> appropriate measures in the LFS book.  This apparently hasn't
> spawned any thread on BugTraq, although I think it might be
> significant.
 >snip<
> Attached below is a patch that should fix the problem for
> vsnprintf()-enabled builds.  We should all test it as much as
> possible...I've built zlib with it (and ensured that
> -DHAS_vsnprintf has the desired preprocessor effect), but I
> haven't done any testing on it yet.  Non-vsnprintf()-enabled
> builds are just stuck with a (possibly unavoidable)
> vulnerability, but we should at least fix it for Linux.

Testing efforts with the patched zlib, compiled with CFLAGS="-O2 
-march=i486 -fPIC -DHAS_vsnprintf":

[ root at valhalla /usr/src ] # gcc -O2 crashzlib.c -o crashzlib -lz
[ root at valhalla /usr/src ] # ./crashzlib
gzprintf -> 0
gzclose -> 0 [25]

(At this point, it seems the vulnerability is fixed for the 
proposed test case.)

[ root at valhalla /usr/src ] # file -z zlib-1.1.4.tar.gz
zlib-1.1.4.tar.gz: tar archive (gzip compressed data, from Unix, 
max compression)

(The effect here is obvious; "-z" makes file un-gzip the input 
first and examine the uncompressed output.  Since file is 
dynamically linked to zlib, the fix should take effect 
immediately with the zlib update.  I removed gzip, zcat et al to 
make absolutely sure it wasn't just turning around and calling 
one of those binaries.  This simple testcase passes.)

I say the patch should immediately go into LFS-CVS _after_ the 
upcoming book release.  I'd almost say before, but we really 
haven't done extensive testing of the patch yet, nor do we know 
how much would be enough.  It's too close to the upcoming 
release for immediate inclusion.

I also say the patch should go back to the zlib developers for 
evaluation and possible inclusion in a new version.  The 
HAS_vsnprintf macro should also be implemented automatically 
when appropriate, or at least described in a README.vsnprintf 
included with the zlib source release.  Having zlib limp along 
with vsprintf() on systems with a working vsnprintf() is rather 
inexcusable.

-- 
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list