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:Dumb security question
by
Carnage4Life
·
· Score: 4, Informative
On the stuff I've been reading about finding and fixing buffer overflows, it seems like it's generally not too hard to spot where these things could potentially happen.
From this statement I assume you are not a programmer. Buffer overflows caused by using known unsafe library functions (e.g. strcpy, strcat, gets, etc.) can be handled by simple pattern matching but actually investigating the code to make sure every memory/array access does not go out of bounds is not a simple pattern matching problem.
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:Staticly linked-implication
by
Stonehand
·
· Score: 4, Informative
You could write a script using 'nm' and 'grep' -- once you identify some functions in zlib. If they have a common prefix, search on that.
Of course, if you stripped the symbols out of the binaries, then the function names won't be there for nm to find and you're quite screwed -- basically you'd have to go grab the sources again and scan the Makefiles and perhaps the code itself for zlib references.
-- Only the dead have seen the end of war.
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.
Re:Remote upgrades : be careful
by
Electrum
·
· Score: 4, Informative
So if you don't have access to the console, open a classical 'telnet' port for a few minutes, just during the upgrade. Once you've checked that SSH is still ok, you can remove the telnet daemon.
Since the SSH server forks after you've connected, you can safely stop the server while connected via SSH. You never need to use telnet. Just make sure that you can still connect before disconnecting from the original SSH connection.
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.
This was a reference on the RedHat advisory [RHSA-2002:027-22] Vulnerability in zlib library (powertools):
Mitre
Gnome
The Mitre page says it's still under review.
The little guy just ain't getting it, is he?
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.
On the stuff I've been reading about finding and fixing buffer overflows, it seems like it's generally not too hard to spot where these things could potentially happen.
/GS switch in Visual C++.NET.
From this statement I assume you are not a programmer. Buffer overflows caused by using known unsafe library functions (e.g. strcpy, strcat, gets, etc.) can be handled by simple pattern matching but actually investigating the code to make sure every memory/array access does not go out of bounds is not a simple pattern matching problem.
However some automated techniques have been developed to discover buffer overflows and similar errors in a generic manner. The most significant efforts I have seen are the Stanford Meta-level Compilation Project and the
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
You could write a script using 'nm' and 'grep' -- once you identify some functions in zlib. If they have a common prefix, search on that.
Of course, if you stripped the symbols out of the binaries, then the function names won't be there for nm to find and you're quite screwed -- basically you'd have to go grab the sources again and scan the Makefiles and perhaps the code itself for zlib references.
Only the dead have seen the end of war.
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!
So if you don't have access to the console, open a classical 'telnet' port for a few minutes, just during the upgrade. Once you've checked that SSH is still ok, you can remove the telnet daemon.
Since the SSH server forks after you've connected, you can safely stop the server while connected via SSH. You never need to use telnet. Just make sure that you can still connect before disconnecting from the original SSH connection.