Posted by
michael
on from the sauce-for-the-gander dept.
SirTimbly writes: "CNET is reporting that there is a buffer overflow problem with zlib in linux, which is used for network compression. Supposedly, someone could remotely cause a buffer overflow through mozilla, X11 and many other programs." The advisory from Red Hat is available.
Re:It's not a problem in zlib per se
by
slamb
·
· Score: 5, Informative
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 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.
This is why you clear pointers after freeing them
by
coyote-san
·
· Score: 5, Informative
This is why you ALWAYS set a pointer to NULL after freeing it, even if it's "totally unnecessary" because you're about to free the structure holding the pointer.
This doesn't prevent attempts to free the previously freed pointer, but that will generally do a lot less damage than freeing a real malloc'd address. And during development it's trivial to add an assertion checking for a NULL pointer before any free().
-- For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Re:Should I upgrade my kernel?
by
Mr+Z
·
· Score: 5, Informative
One place kernel uses zlib is to compress the kernel boot image. The kernel image then gets decompressed
during bootup. So, from the standpoint of "the kernel uses zlib", the kernel is affected.
There is, however, no new vulnerability introduced
as far as I can tell. To attack the zlib-based
decompression that the kernel performs, an attacker would need to modify the compressed kernel image that is used to boot the machine.
I can think of far more fruitful ways to
compromise a machine by modifying the kernel
image than by trying to dork the zlib decompression that happens before the kernel even runs.
Another place the kernel uses ZLib is when
mounting compressed filesystems. (Compressed
RAM disks and zisofs come to mind.) In this
case, you're asking a live kernel to decompress arbitrary data. These
are only issues when mounting untrusted media.
If you made the media yourself, then your
only risk is that corrupted media might cause
a kernel oops. And if you don't have cramdisk
and zisofs compiled in, you're safe.
Other places the kernel seems to use ZLib (from a cursory scan of the source -- there may be others):
jffs2 -- Journalling Flash Filesystem version 2
ppp -- used for ppp_deflate option
In any case, the kernel is a statically linked
entity, with a minor exception for modules.
ZLib is not a module, therefore to upgrade
ZLib in the kernel, you'll need to rebuild the
kernel. And it doesn't appear to be as easy as
just upgrading ZLib and rebuilding the kernel.
The kernel has multiple modified copies of ZLib
in its source tree. I'd wait for an official
kernel patch.
Slashdot Mirror
This article gives more information, and links to vendor advisories: http://www.linuxsecurity.com/articles/security_sou rces_article-4582.html.
-mark
If your computer says LINUX, run...computers can't talk! [unless you have text-speech software]
Some More Links.
Here.
Fascism should more properly be called corporatism, since it is the merger of state and corporate power.
The advisory for zlib-1.1.3 is at:
i b Advisory 2002-03-11
1 .4 .tar.gz
http://www.zlib.org/advisory-2002-03-11.txt
Zl
zlib Compression Library Corrupts malloc Data Structures via Double Free
The new zlib (1.1.4) is at:
ftp://ftp.info-zip.org/pub/infozip/zlib/zlib-1.
If you want this behavior, you can get it easily on Linux/glibc. From the malloc(3) manual page:
This is why you ALWAYS set a pointer to NULL after freeing it, even if it's "totally unnecessary" because you're about to free the structure holding the pointer.
This doesn't prevent attempts to free the previously freed pointer, but that will generally do a lot less damage than freeing a real malloc'd address. And during development it's trivial to add an assertion checking for a NULL pointer before any free().
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
One place kernel uses zlib is to compress the kernel boot image. The kernel image then gets decompressed during bootup. So, from the standpoint of "the kernel uses zlib", the kernel is affected. There is, however, no new vulnerability introduced as far as I can tell. To attack the zlib-based decompression that the kernel performs, an attacker would need to modify the compressed kernel image that is used to boot the machine. I can think of far more fruitful ways to compromise a machine by modifying the kernel image than by trying to dork the zlib decompression that happens before the kernel even runs.
Another place the kernel uses ZLib is when mounting compressed filesystems. (Compressed RAM disks and zisofs come to mind.) In this case, you're asking a live kernel to decompress arbitrary data. These are only issues when mounting untrusted media. If you made the media yourself, then your only risk is that corrupted media might cause a kernel oops. And if you don't have cramdisk and zisofs compiled in, you're safe.
Other places the kernel seems to use ZLib (from a cursory scan of the source -- there may be others):
In any case, the kernel is a statically linked entity, with a minor exception for modules. ZLib is not a module, therefore to upgrade ZLib in the kernel, you'll need to rebuild the kernel. And it doesn't appear to be as easy as just upgrading ZLib and rebuilding the kernel. The kernel has multiple modified copies of ZLib in its source tree. I'd wait for an official kernel patch.
--JoeProgram Intellivision!