zlib security - permanent fix to the real problem?
krum at smyrnacable.net
Tue Mar 12 00:52:31 PST 2002
>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.
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