zlib security - permanent fix to the real problem?

Philippe Gendreau phil at xmailer.ods.org
Tue Mar 12 16:19:36 PST 2002


* 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



More information about the lfs-security mailing list