Users login

Create an account »


Users login

Home » Hacking News » FreeBSD-SA-02:18-zlib double-free

FreeBSD-SA-02:18-zlib double-free

by Nikola Strahija on March 19th, 2002 A programming error in zlib may cause segments of dynamically allocated memory to be released more than once (double-freed). 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 may cause the zlib routines to attempt to free memory multiple times.

Unlike some implementations of malloc(3)/free(3), the malloc(3) and
free(3) routines used in FreeBSD (aka phkmalloc, written by
Poul-Henning Kamp ), are not vulnerable to this type
of bug. From the author:

Most mallocs keep their housekeeping data right next to the
allocated range. This gives rise to all sorts of unpleassant
situations if programs stray outside the dotted line, free(3)
things twice or free(3) modified pointers.

phkmalloc(3) does not store housekeeping next to allocated data,
and in particular it has code that detects and complains about
exactly this kind of double free.

When attempting to double-free an area of memory, phkmalloc will
issue a warning:

progname in free(): error: chunk is already free

and may call abort(3) if the malloc flag 'A' is used.

III. Impact

If an attacker is able to pass a specially-crafted block of invalid
compressed data to an application that utilizes zlib, the attempt to
decompress the data may cause incorrect operation of the application,
including possibly crashing the application. Also, the malloc
implementation will issue warnings and, if the `A' malloc option is
used, cause the application to abort(3). In short, an attacker may
cause a denial of service in applications utilizing zlib.

IV. Workaround

To prevent affected programs from aborting, remove the 'A' from
the malloc flags. To check which malloc flags are in use, issue the
following commands:

# ls -l /etc/malloc.conf

A nonexistent /etc/malloc.conf or MALLOC_OPTIONS environmental variable
means that no malloc flags are in use. See the malloc(3) man page for
more information.

V. Solution

[FreeBSD 4.x base system]

1) Upgrade your vulnerable system to 4.5-STABLE or to one of the
RELENG_4_4 or RELENG_4_5 security branches dated after the respective
correction dates.

2) To patch your present system: download the relevant patch from the
below location, and execute the following commands as root:

# fetch
# fetch

Verify the detached PGP signature using your PGP utility.

This patch has been verified to apply to all FreeBSD 4.x versions.

# cd /usr/src
# patch -p

The Common Vulnerabilities and Exposures project ( has
assigned the name CAN-2002-0059 to this issue.

Version: GnuPG v1.0.6 (FreeBSD)
Comment: FreeBSD: The Power To Serve


Newsletter signup

Signup to our monthly newsletter and stay in touch with IT news!

Free E-books

We've got ebooks! But they're not online. :( Please give us a few days to bring downloads back.


Have something to say or just wanna drop us a line? Please keep this in mind: to spam, we reply with spam.

Contact us »