I'm a bit confused now. So FreeBSD, 4.5-RELEASE is vulnerable? I
am a bit unclear on this as I thought phkmalloc was not vulnerable
to the double-free bug. Or does this only affect binaries
statically linked with older revisions of libc and linux binaries?

That's what I would think anyway.

Cheers,
-JD-

--On Monday, March 18, 2002 7:00 AM -0800 FreeBSD Security Advisories
<security-advisoriesfreebsd.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> =========================================================================
> ==== FreeBSD-SA-02:18 Security
> Advisory
> FreeBSD, Inc.
>
> Topic: zlib double-free
>
> Category: core, ports
> Module: zlib
> Announced: 2002-03-18
> Credits: Matthias Clasen <maclasgmx.de>
> Owen Taylor <otaylorredhat.com>
> Affects: All released versions of FreeBSD
> FreeBSD 4.5-STABLE prior to the correction date
> Various ports using or including zlib
> Corrected: 2002-02-22 02:48:40 UTC (RELENG_4)
> 2002-02-23 00:14:28 UTC (RELENG_4_5)
> 2002-02-23 00:15:19 UTC (RELENG_4_4)
> 2002-02-23 00:15:50 UTC (RELENG_4_3)
> CVE: CAN-2002-0059
> FreeBSD only: NO
>
> I. Background
>
> zlib is a compression library used by numerous applications to provide
> data compression/decompression routines.
>
> II. Problem Description
>
> 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 <phkFreeBSD.org>), 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
># echo $MALLOC_OPTIONS
>
> 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 ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:18/zlib.patch
># fetch
># ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:18/zlib.patch.asc
>
> 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 < /path/to/patch
># cd lib/libz
># make depend && make all install
>
> Then rebuild and reinstall your kernel as described in
> http://www.freebsd.org/handbook/kernelconfig.html and reboot the
> system with the new kernel for the changes to take effect.
>
> [ports]
>
> Various ports may statically link zlib or contain their own versions
> of zlib that have not been corrected by updating the FreeBSD libz.
> Efforts are underway to identify and correct these ports.
>
> VI. Correction details
>
> The following list contains the revision numbers of each file that was
> corrected in FreeBSD.
>
> Path Revision
> Branch
> -
> -------------------------------------------------------------------------
> src/lib/libz/infblock.c
> RELENG_4 1.1.1.4.6.1
> RELENG_4_5 1.1.1.4.12.1
> RELENG_4_4 1.1.1.4.10.1
> RELENG_4_3 1.1.1.4.8.1
> src/sys/net/zlib.c
> RELENG_4 1.10.2.1
> RELENG_4_5 1.10.8.1
> RELENG_4_4 1.10.6.1
> RELENG_4_3 1.10.4.1
> -
> -------------------------------------------------------------------------
>
> VII. References
>
> <URL:http://online.securityfocus.com/archive/1/261205>
>
> The Common Vulnerabilities and Exposures project (cve.mitre.org) has
> assigned the name CAN-2002-0059 to this issue.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (FreeBSD)
> Comment: FreeBSD: The Power To Serve
>
> iQCVAwUBPJXXsFUuHi5z0oilAQGjqwP/dozUEpfv3LqUE/uGcG9wzGwmhdAthjKH
> vLmKwoHjJE9v69W007cm4KWEYiF67GDkwYa+mBze+tG3lJknFUP7A3+U7ooGlatt
> 5wxngLIzl9i5bM9x2xeQmzue1xG3e+6j7xANG8O8a9aO08iDc/oSZN+4O3kkJhzf
> 7an7sq5rGQw=
> =P7az
> -----END PGP SIGNATURE-----
>
> To Unsubscribe: send mail to majordomoFreeBSD.org
> with "unsubscribe freebsd-security-notifications" in the body of the
> message

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

iD8DBQE8lhLP01CVlgQ2fAgRAnGPAJ9/0lU5KlA+8MdFMHpwFZVjaCwXDwCgnIG4
N9YkmHsHQ9H8Z2BmzdR6kt8=
=v9HD
-----END PGP SIGNATURE-----

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]