zlib security - permanent fix to the real problem?

Kevin Krumwiede krum at smyrnacable.net
Wed Mar 13 00:08:25 PST 2002


Yes, someone with more know-how please comment on this, for I am
only-an-egg.

Compile and run the following program to see the effects of setting
MALLOC_CHECK_ (WARNING: this program deliberately corrupts your heap):

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char* argv[]) {
   void* foo = malloc(16);
   free(foo);
   free(foo);
   printf("Program ran to completion.\n");
}

With MALLOC_CHECK_ unset: Immediate segfault; printf statement not reached.
(But version without the printf did not segfault!)

With MALLOC_CHECK_=1: Error message with hex address of foo, followed by
printf message.

With MALLOC_CHECK_=2: Prints "Abort" and immediately terminates; printf
statement not reached.

The question is: Do either of these settings (1 or 2) actually prevent the
program from corrupting the heap?  If so, does this address the zlib issue,
at least as an interim fix?  Or maybe this is something we should all do by
default, zlib issues aside?

Krum


> -----Original Message-----
> From: lfs-security-bounce at linuxfromscratch.org
> [mailto:lfs-security-bounce at linuxfromscratch.org]On Behalf Of Philippe
> Gendreau
> Sent: Tuesday, March 12, 2002 7:20 PM
> To: lfs-security at linuxfromscratch.org
> Subject: Re: zlib security - permanent fix to the real problem?
>
>
> * Kevin Krumwiede (krum at smyrnacable.net) wrote:
> > >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.
> >
> >
> > [response]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.
>
> Can somebody comment on this?
> Does it means you can fix the bug by setting this variable in
> /etc/profile?
>
> Even with the performance problem, it could be used as
> a temporary solution for those packages that are not yet identified or
> have no update available.
>
> thanks,
> phil
> --
> Stupidity has a certain charm - ignorance does not.
> --
> Unsubscribe: send email to listar at linuxfromscratch.org
> and put 'unsubscribe lfs-security' in the subject header of the message
>

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-security' in the subject header of the message



More information about the lfs-security mailing list