zlib security - permanent fix to the real problem?
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 tunable 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 diagnostic 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
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.
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