Fwd: buffer overrun in zlib 1.1.4

Richard Kettlewell rjk at greenend.org.uk
Sun Feb 23 16:22:30 PST 2003

Kelledin writes:
> The first issue that's relevant to us:
> 1) vsnprintf() supposedly isn't used by default.

You can verify whether it is actually used by the compiled library
with e.g.:

  nm -D /usr/lib/libz.so | grep printf

(indeed something like this was what alerted me to the problem in the
first place, albeit in Debian rather than LFS.)

> At first glance, zlib does not do sufficient checking.  It does 
> not gather the return value of vsnprintf() at all.  It instead 
> tries to do an strlen() on the buffer filled by vsnprintf();  
> this is VERY much the Wrong Thing(tm) to do:
>    a) If the buffer would have a NULL character written in the     
>       middle, this would cause the relevant code to return an 
>       incorrect value.  This opens us up to a possible string 
>       format vulnerability.

I hadn't thought of that one.

>    b) If the buffer was not large enough to hold all the data,  
>       that opens up the code to a bounds checking failure--AFAIK 
>       vsnprintf() does not write a NULL character to the end of 
>       the buffer in this case,

vsnprintf and snprintf always write the terminating 0 unless the
buffer has zero size (which isn't the case here).  The relevant C99
text is:

    The snprintf function is equivalent to fprintf, except that the
    output is written into an array (specified by argument s) rather
    than to a stream. If n is zero, nothing is written, and s may be a
    null pointer. Otherwise, output characters beyond the n-1st are
    discarded rather than being written to the array, and a null
    character is written at the end of the characters actually written
    into the array. If copying takes place between objects that
    overlap, the behavior is undefined.

> 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.

Personally I would make it refuse to build if vsnprintf wasn't

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