[ale] zlib security problem -- immediate and permanent fix?

[Kevin Krumwiede]

>From a /. post by slamb:

[quoted]This bug causes zlib to free() a malloc'ed block of memory more than
once. free() on most other OS's (including Windows, FreeBSD and OpenBSD) is
smart enough to check for this and will print a warning instead of
destroying the heap; glibc's malloc (and by extension, Linux's) does not and
will gleefully make a mess out of the whole memory space. This can cause all
sorts of buggery when the next malloc() occurs, including what amounts to a
buffer overflow exploit.

If you want this behavior, you can get it easily on Linux/glibc. From the
malloc(3) manual page:

Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include
a malloc implementation which is tun­able via environment variables. When
MALLOC_CHECK_ is set, a special (less efficient) implementation is used
which is designed to be tolerant against simple errors, such as double calls
of free() with the same argument, or overruns of a single byte (off-by-one
bugs). Not all such errors can be proteced against, however, and memory
leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption
is silently ignored; if set to 1, a diag­nostic is printed on stderr; if set
to 2, abort() is called immediately. This can be useful because otherwise a
crash may happen much later, and the true cause for the problem is then very
hard to track down.

> -----Original Message-----
> From: Ken Kennedy [mailto:kkennedy at kenzoid.com]
> Sent: Monday, March 11, 2002 9:00 PM
> To: ale at ale.org
> Subject: Re: [ale] zlib security problem
>
>
> On Mon, Mar 11, 2002 at 04:42:01PM -0500, jenn at colormaria.com wrote:
>
> > >From what I understand it's a linux-specific zlib problem
> (zlib runs on may
> > os's but free() is fubar'd on linux.  i don't know what any of
> that means, I
> > just repeat it).  So it would affect all linux distros, from what I
> > understand, not just RH.
>
> Correct. There's even a place in the kernel code that's affected,
> according to the RH release. Once you've updated your zlib, apps that
> dynamically link to that library will be ok (after a
> restart). Unfortunately, there are numerous apps running around
> statically linked to a vulerable version of zlib. They'll have to be
> replaced/rebuilt as well.
>
> > Has anyone heard of any non-RPM's that patch this yet??  AFAIK,
> it hasn't
> > even hit bugtraq yet, which I find odd.
>
> Non-RPM's? You mean non-RPM-based distributions? Well, Debian has
> already released a patch...
>
> --
>
> Ken Kennedy	| http://www.kenzoid.com	| kenzoid at io.com
>


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.