zlib bug, possible remote root hole :/

[n0cmonkey]

csn article

It looks like the free BSDs (Open, Net, Free) are not vulnerable (with the tests I know of), but Linux, Solaris, AIX, HPUX, and IRIX are. Its a tough hack, but causing things to crash seems to be much easier.

I currently see information from SuSE, EnGarde, Mandrake, and RedHat about fixes. Debian shouldnt be too far behind (I may have missed it), and Slackware folks should check the site (cant find it right off).

zlib site

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Zlib Advisory 2002-03-11
zlib Compression Library Corrupts malloc Data Structures via Double Free

Original release date: March 11, 2002
Last revised: March 11, 2002
Source: This advisory is based on a CERT advisory written
by Jeffrey P. Lanza. See original on http://www.cert.org

Systems Affected

* Any software that is linked against zlib 1.1.3 or earlier
* Any data compression library derived from zlib 1.1.3 or earlier

Overview

There is a vulnerability in the zlib shared library that may introduce
vulnerabilities into any program that includes zlib. This
vulnerability has been assigned a CVE candidate name of CAN-2002-0059
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0059

I. Description

There is a vulnerability in the decompression algorithm used by the
popular zlib compression library. If an attacker is able to pass a
specially-crafted block of invalid compressed data to a program that
includes zlib, the program's attempt to decompress the crafted data
can cause the zlib routines to corrupt the internal data structures
maintained by malloc.

The vulnerability results from a programming error that causes
segments of dynamically allocated memory to be released more than once
(aka. "double-freed"). Specifically, when inftrees.c:huft_build()
encounters the crafted data, it returns an unexpected Z_MEM_ERROR to
inftrees.c:inflate_trees_dynamic(). When a subsequent call is made to
infblock.c:inflate_blocks(), the inflate_blocks function tries to free
an internal data structure a second time.

Because this vulnerability interferes with the proper allocation and
de-allocation of dynamic memory, it may be possible for an attacker to
influence the operation of programs that include zlib. In most
circumstances, this influence will be limited to denial of service or
information leakage, but it is theoretically possible for an attacker
to insert arbitrary code into a running program. This code would be
executed with the permissions of the vulnerable program.

II. Impact

This vulnerability may introduce vulnerabilities into any program that
includes the affected library. Depending upon how and where the zlib
routines are called from the given program, the resulting
vulnerability may have one or more of the following impacts: denial of
service, information leakage, or execution of arbitrary code.

III. Solution

Upgrade your version of zlib

The maintainers of zlib have released version 1.1.4 to address this
vulnerability. Any software that is linked against or derived from an
earlier version of zlib should be upgraded immediately. The latest
version of zlib is available at http://www.zlib.org

The md5 sums of the source archives are:
abc405d0bdd3ee22782d7aa20e440f08 zlib-1.1.4.tar.gz
ea16358be41384870acbdc372f9db152 zlib-1.1.4.tar.bz2

IV. Acknowledgments

Thanks to Owen Taylor and other people at Redhat Inc. for the
reporting and research of this vulnerability.


This document is available from
http://www.gzip.org/zlib/advisory-2002-03-11.txt

The public PGP key of zlib author Jean-loup Gailly is available from
http://www.gzip.org/zlib/jloup.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8jRnX2aJ9JQGWcacRAiBcAJ9LiYJm/Nk4EbnD6qBJUsHUmgrk/QCdG5br
M8WeqzcAwikwlEFSPHpt790=
=0/cN
-----END PGP SIGNATURE-----

 

[Armitage]

Yea, just upgraded my RedHat box @ work this a.m.

The good news:
- While it may be fairly easy to crash a program using the old zlib, from what I've read it would be exceeedingly difficult (but not impossible) to exploit the problem beyond this DoS. This is because it is a double-free bug, and not an overflow bug.
- Fixes were available within hours of the announcment (some were actually available before the announcement I think)
- RedHat at least is changing alot of their stuff to dynamically link zlib. The reason the updates for this are so big is because many apps statically link this library. Hopefully this will be a wakeup call that system maintenance like this is much easier if widely used libs are dynamically linked.

 

[n0cmonkey]

<< Yea, just upgraded my RedHat box @ work this a.m.

The good news:
- While it may be fairly easy to crash a program using the old zlib, from what I've read it would be exceeedingly difficult (but not impossible) to exploit the problem beyond this DoS. This is because it is a double-free bug, and not an overflow bug. >>



Mentioned that, but thanks for providing more information. The best information I found on this was "confidential" so I couldnt say too much



<< - Fixes were available within hours of the announcment (some were actually available before the announcement I think) >>



I heard about the bug last night (although I may have heard something earlier but cant find it now...). The first announcement I have in my inbox is from SuSE a ittle while before the zlib announcement I linked to. Great response times.



<< - RedHat at least is changing alot of their stuff to dynamically link zlib. The reason the updates for this are so big is because many apps statically link this library. Hopefully this will be a wakeup call that system maintenance like this is much easier if widely used libs are dynamically linked. >>



To me, there are a lot of things I like static. /sbin, /bin should all be static, and maybe /usr/bin, /usr/sbin too. Most everything else could be dynamic for all I care. But you definitely need the necessary applications to be static incase your libs die for some reason.

 

[Barnaby W. Füi]

i just upgraded to zlib 1.1.4-1, as soon as debian gets other stuff updated i will promptly apt-get upgrade =)

 

[Armitage]

<< To me, there are a lot of things I like static. /sbin, /bin should all be static, and maybe /usr/bin, /usr/sbin too. Most everything else could be dynamic for all I care. But you definitely need the necessary applications to be static incase your libs die for some reason. >>



Yea, that's a good point.
You need to be judicious in your use of dynamic linking, or one screw up of a major lib incapacitates your whole system. But when I look at some of the stuff that had to be upgraded here, there was little reason not to make it dynamic.

 

[bubba]

the folks at zlib provided a tool here: http://www.gzip.org/zlib/apps.html
that should allow one to scan binaries for the bad zlib.

I scanned my ssh.com ssh (v3.1.0) and got the following result:

$ ./find-zlib.pl /usr/local/bin/ssh2
/usr/local/bin/ssh2: inflate version: "1.1.3 Copyright 1995-1998 Mark Adler"
/usr/local/bin/ssh2: zlib cplens table, little endian
/usr/local/bin/ssh2: zlib cplext table (version 1.0.5 to 1.1.4)

Is this bad or good???

I am confused... Is ssh.com's v3.1.0 ssh vulnerable???

 

[n0cmonkey]

<< the folks at zlib provided a tool here: http://www.gzip.org/zlib/apps.html
that should allow one to scan binaries for the bad zlib.

I scanned my ssh.com ssh (v3.1.0) and got the following result:

$ ./find-zlib.pl /usr/local/bin/ssh2
/usr/local/bin/ssh2: inflate version: "1.1.3 Copyright 1995-1998 Mark Adler"
/usr/local/bin/ssh2: zlib cplens table, little endian
/usr/local/bin/ssh2: zlib cplext table (version 1.0.5 to 1.1.4)

Is this bad or good???

I am confused... Is ssh.com's v3.1.0 ssh vulnerable??? >>



Maybe, but why worry about it?

 

[bubba]

<< Maybe, but why worry about it? >>



Well, because I have not had to upgrade ssh in a long time because I don't use OpenSSH. That and the fact that cert said OpenSSH is also vulnerable. Plus I would have to change from ssh to openssh on tons of machines scattered across many departments and two buildings.

So, is ssh.com's ssh vulnerable or not?

 

[n0cmonkey]

<<

<< Maybe, but why worry about it? >>



Well, because I have not had to upgrade ssh in a long time because I don't use OpenSSH. That and the fact that cert said OpenSSH is also vulnerable. Plus I would have to change from ssh to openssh on tons of machines scattered across many departments and two buildings.

So, is ssh.com's ssh vulnerable or not? >>



Well I see nothing about it on ssh.com's site, but their layout sucks and I would never buy their product so maybe I was looking in the wrong place. I re-read the beginning of the zlib advisory I linked at the top (although my link has an extra character in it) and that said if it is compiled with zlib 1.1.3 or earlier the program should be vulnerable. It looks like, from your output there, that ssh.com's ssh was compiled with 1.1.3 so I would say yes, it is probably vulnerable. Give me a billing address

 

[Agamar]

I compiled the new zlib on our RH 6.x boxes this morning, but for our 7.2 boxes I am waiting for a RedHat u2date install. Anybody know when they will have it ready?

 

[kellygirlbeads]

<<
To me, there are a lot of things I like static. /sbin, /bin should all be static, and maybe /usr/bin, /usr/sbin too. Most everything else could be dynamic for all I care. But you definitely need the necessary applications to be static incase your libs die for some reason. >>



The whole difference between /sbin and /bin is that one set is statically linked (hence the S). Many things in bin are too complex to statically link, or you'd have a lot of HUGE binaries.


I hate to be a zealot (slight lie), but this really is evidence of the benefits of *bsd over linux: the simple things, like the c library, are done more carefully. Calls to malloc() zero the memory before giving it to the application (whereas you'd have to call bzero() in linux) and calls to free() make sure there really is memory to free. Its these little things that are overlooked in linux that make *bsd infinitely more secure.

 

[n0cmonkey]

<<

<<
To me, there are a lot of things I like static. /sbin, /bin should all be static, and maybe /usr/bin, /usr/sbin too. Most everything else could be dynamic for all I care. But you definitely need the necessary applications to be static incase your libs die for some reason. >>



The whole difference between /sbin and /bin is that one set is statically linked (hence the S). Many things in bin are too complex to statically link, or you'd have a lot of HUGE binaries. >>



I figured S was for system, as in system binaries.



<< I hate to be a zealot (slight lie), but this really is evidence of the benefits of *bsd over linux: the simple things, like the c library, are done more carefully. Calls to malloc() zero the memory before giving it to the application (whereas you'd have to call bzero() in linux) and calls to free() make sure there really is memory to free. Its these little things that are overlooked in linux that make *bsd infinitely more secure. >>



Watch out for Nothinman, he doesnt like anyone saying that *BSD is better. I just cringe when I hear FreeBSD

 

[Nothinman]

Calls to malloc() zero the memory before giving it to the application

So you're saying there's no delayed allocation of memory in FreeBSD?

calls to free() make sure there really is memory to free. Its these little things that are overlooked in linux that make *bsd infinitely more secure

I'm not saying that's a bad thing, but I think most people feel it's the programmers responsibility to make sure he frees all the memory he allocates, no more no less, atleast with C.

 

[n0cmonkey]

OpenBSD released a patch.

OpenBSD errata explaining a little bit about this on OpenBSD.

EDIT: it looks like a fairly hefty patch as far as OpenBSD patches go

 

[n0cmonkey]

Microsoft applications affected?

 

[DaHitman]

FYI.. CERT team announcement came out yesterday..
CERT® Advisory CA-2002-07 Double Free Bug in zlib Compression Library

Apple Computer, Inc.
Mac OS X and Mac OS X Server do not contain this vulnerability

FreeBSD
FreeBSD is not vulnerable, as the FreeBSD malloc implementation detects and complains about several programming errors including this kind of double free.

Hewlett-Packard Company
HPUX is not vulnerable.

OpenBSD
OpenBSD is not vulnerable as OpenBSD's malloc implementation detects double freeing of memory. The zlib shipped with OpenBSD has been fixed in OpenBSD-current in January 2002.

Microsoft - Look like totally complete dumbasses again... I guess taking that month (shortest) off to audit code helped alot.

 

[manly]

<< Calls to malloc() zero the memory before giving it to the application >>



That's how calloc works. Theoretically speaking, aren't there some applications where this decision impacts performance. Obviously, I'm not referring to 99.9% of situations.



<< calls to free() make sure there really is memory to free. Its these little things that are overlooked in linux that make *bsd infinitely more secure >>



See above comment.

 

[n0cmonkey]

<<

<< Calls to malloc() zero the memory before giving it to the application >>



That's how calloc works. Theoretically speaking, aren't there some applications where this decision impacts performance. Obviously, I'm not referring to 99.9% of situations.



<< calls to free() make sure there really is memory to free. Its these little things that are overlooked in linux that make *bsd infinitely more secure >>



See above comment. >>



There is an OpenBSD tweak that Im going to look into (keep meaning to but never remember when its convenient) that will "hinder" performance, but will increase security. Thats a tradeoff I can live with.