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:more info please
by
Anonymous Coward
·
· Score: 2, Informative
and the slashdot headline is braindead.
Its not a buffer overrun. its a double free. much harder to exploit, but still possible, so you should patch ASAP.
Re:more info please
by
ncc74656
·
· Score: 3, Informative
why the fsck would you statically link in zlib?
Um...because that's the way nearly every package that uses zlib links it? For instance, OpenSSH AFAIK will only statically link it (so if you rebuilt OpenSSH last week to fix this hole, you get to rebuild it again:-) ).
(I'm rebuilding OpenSSH on the work machines right now...I checked to see if it would link to libz.so, but it seems to only want libz.a.)
-- 20 January 2017: the End of an Error.
more information - better article
by
marks
·
· Score: 5, Informative
No buffer overflow!
by
lkaos
·
· Score: 3, Informative
From the zlib.org page:
The vulnerability results from a programming error that causes segments of dynamically allocated memory to be released more than once (aka. "double-freed"). Specifically, when inftrees.c:huft_build() encounters the crafted data, it returns an unexpected Z_MEM_ERROR to inftrees.c:inflate_trees_dynamic(). When a subsequent call is made to infblock.c:inflate_blocks(), the inflate_blocks function tries to free an internal data structure a second time.
Because this vulnerability interferes with the proper allocation and de-allocation of dynamic memory, it may be possible for an attacker to influence the operation of programs that include zlib. In most circumstances, this influence will be limited to denial of service or information leakage, but it is theoretically possible for an attacker to insert arbitrary code into a running program. This code would be executed with the permissions of the vulnerable program.
Duplicate deletions are not the same as buffer overflows and are no where near as easy to exploit. In fact, I have _never_ seen a duplicate deletion exploitation other than a simple DoS. Not to mention the fact that it requires a special series of calls from the calling program.
In summary, the world hasn't come to an end and Free Software is all-the-sudden as vunerable as closed source software. Put the pills down and relax:)
--
int func(int a);
func((b += 3, b));
Re:No buffer overflow!
by
Mike+Shaver
·
· Score: 3, Informative
If the application has the "wrong" pattern of allocations and frees, it may be exploitable. One such pattern is the freeing of x, an allocation -- which gets x-(sizeof void *) -- and then the subsequent double-freeing of x.
Re:Linux only?
by
Anonymous Coward
·
· Score: 1, Informative
it's probably one of the most prevalent libraries around, it's even on my handheld for plucker, the palm-based offline browser; webservers or proxy accelerators using gzip compression could even be at risk.
Why didn't they use 'purify' ?
by
Lord+Hugh+Toppingham
·
· Score: 1, Informative
Surely this kind of problem could be easily avoided if the developers had used 'purify' to check for memory leaks. Or are the open-sourcers too high and mighty to use 'proprietary' software even when it would improve the quality of their code ?
One more bug OpenSSH is affected by...
by
Anonymous Coward
·
· Score: 3, Informative
OpenSSh uses zlib - if you happen to compile OpenSSH statically with zlib (I think thats the default), one more upgrade cycle after the latest OpenSSH 3.0.2p1 bug...:(
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:Staticly linked-implication
by
jezcope
·
· Score: 1, Informative
Try using the ldd command, which prints dynamic library dependencies. Something along the lines of
find/usr/bin | xargs ldd
should give you something to grep through, although because of the way ldd formats it's output, you might need something a bit more intelligent to find exactly what you want (i.e. a list of files linked against libz). I'm not a perl guru, but i don't think it would take too long to knock together a suitable script.
-- Fabricate diem, punc
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:Staticly linked-implication
by
cicadia
·
· Score: 3, Informative
You're absolutely right -- the only thing that a binary download will fix is packages using the libz.so shared library. Most software seems to link with the library statically. This is a huge problem.
I'm currently running this command against my/usr/src directory, just to get a preliminary list of packages to recompile:
Assuming you've still got your source tree intact since you compiled, this should find all makefiles which reference the zip library. If you've deleted any source directories, you will have to untar them and run configure again to build the makefiles.
The packages affected by the double-free() libz bug can be devided into
two categories:
1) packages that link dynamically against the system-provided
compression library. These packages get fixed automatically with
the update of the libz package as described in SuSE-SA:2002:010.
Please note that the processes will continue to use the old
version of the libz.so shared library if the have not been
restarted after the libz package upgrade.
2) packages that contain the compression library in their own
source distribution. These packages need an individual bugfix.
We have prepared update packages for this software that can be
downloaded from the locations as shown below.
The following is a list of the packages in category 2):
gpg
rsync
cvs
rrdtool
freeamp
netscape
vnc
kernel
Re:This is why you clear pointers after freeing th
by
greed
·
· Score: 3, Informative
Calling free() on a NULL pointer is a no-op. No check or assertion is needed.
The assertion lets you catch the logic error that led to the second free during debugging. Presumably, your code path wasn't expecting the pointer to already be free at that point; otherwise, you would have designed it to handle that case already.
Then, in production code, if you do take that path, you'll get the harmless no-op free(0). (You do build production with -DNDEBUG, right?)
Re:Staticly linked-implication
by
umoto
·
· Score: 3, Informative
There are the right ways, then there is the easy, 99% effective way. The easy way is to search for very specific error message strings, which are sort of a fingerprint for most software. I compiled zlib then used "strings libz.a" to find these error messages:
too many length or distance symbols invalid literal/length code
A quick grep for one of those two strings reveals quite a number of statically linked versions of zlib in/usr/bin.
Re:It's not a problem in zlib per se
by
Anonymous Coward
·
· Score: 1, Informative
So, you should download the patched zlib, but you should also email the glibc maintainers
Utter nonsense - the standard regarding C is quite clear and free()'ing a pointer twice is a bug; the behaviour undefined; end of story.
Trying to load off flaws onto others is not insightful but unproffesional and does not solve problems in the real world.
Re:That's better
by
red5
·
· Score: 2, Informative
Cool but it still bugs me when people say Linux just stole it's TCP/IP, VM etc from BSD.
They never offer any evidance of it and all it serves to do is belittle the efferts of the linux community.
I understand that these people don't represent the BSD community. It's still anoying though.
I'm verry thankfull for what Linux/GNU has given me for free. how else would a kid like me get access to UNIX a C compiler etc.
And if the BSD community supplied any of that they diserve there props too. But the guy didn't have to be a dick about it is all I'm trying to say .
-- I know I'm going to hell, I'm just trying to get good seats.
Re:Staticly linked-implication
by
wilhelm
·
· Score: 2, Informative
find / -type f -perm +0111 -print | xargs grep 'too many length or distance symbols' 2>/dev/null
Good info. It's surprising how much stuff gets a hit using this - most of the commercially-produced stuff on my hosts. Real player, Adobe acrobat reader, Netscape, most of the Loki games, the Flash Netscape plugin, among others. I have an old version of commercial ssh, which has linked itself statically as well. That's the one I'm really concerned about; sounds like time to switch to openssh, and make sure it's compiled dynamically.
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.
Re:Then there's still a problem in glibc malloc()
by
Anonymous Coward
·
· Score: 2, Informative
Don't be ridiculous. Get your facts straight. Every good UNIX programmer knows that glibc's malloc is based on Doug Lea's excellent malloc library which one of the fastest and most space efficient single-threaded memory allocators available - much much better than the BSD version. I even recall a BSD mailing list thread not too long ago about wanting to incorporate the Lea-based allocator to replace the inefficient powers-of-two based allocator used in BSD.
Re:Meanwhile back at Microsoft
by
Anonymous Coward
·
· Score: 1, Informative
Nope, my post is still at 1, but since you posted a 2 post in reply to it, which was deemed Interesting (+1), it now shows up as it's the parent.
So, if someone is browsing at x, and you post at y, and someone replies at z - we get the following
x y z 0 2 2 - you see both 1 1 2 - you see both 1 0 2 - you still see both 2 0 2 - you still see both 3 1 3 - you still see both (pretty cool) 3 -1 3 - you still see both
This is why you shouldn't reply to 0 or -1 posts, unless you wish to legitimize them.
Of course, there's the friend/foe bonus too. And in mine, it adds +1 for some posts (Informative) and -1 for others (Troll).
Brings me back to my game design days...
and yes, it's me.
Re:That's better
by
red5
·
· Score: 2, Informative
No, one they stole, one they wrote themselves.
Linux didn't steal shit otherwise someone would post some code comparissions by now. It's not exacly hard to get the code (There both free for download).
So my message to you trolls is put up or shut up.
I want to see proof showing that the code used in the linux kernel was copyed from BSD.
Until then go fuck you self.
-- I know I'm going to hell, I'm just trying to get good seats.
Re:It's not a problem in zlib per se
by
Ed+Avis
·
· Score: 3, Informative
AFAIK: The kernel doesn't use the glibc C library. It has its own memory management code which presumably the kernel zlib code uses. This memory manager may or may not guard against free()ing the same area twice.
But what is the use of zlib in the kernel anyway? Just to uncompress the vmlinuz image before the kernel starts? If so it's not much of a vulnerability, if you can corrupt the vmlinuz file then you can control the whole system anyway.
Slashdot Mirror
could somebody point out where in the source this is? the article was fluff.
https://www.accountkiller.com/removal-requested
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.
it says on http://www.zlibc.org How's that for fast service? :)
Karma: Bad (but who really cares anyway?)
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.
Duplicate deletions are not the same as buffer overflows and are no where near as easy to exploit. In fact, I have _never_ seen a duplicate deletion exploitation other than a simple DoS. Not to mention the fact that it requires a special series of calls from the calling program.
In summary, the world hasn't come to an end and Free Software is all-the-sudden as vunerable as closed source software. Put the pills down and relax
int func(int a);
func((b += 3, b));
it's probably one of the most prevalent libraries around, it's even on my handheld for plucker, the palm-based offline browser; webservers or proxy accelerators using gzip compression could even be at risk.
Surely this kind of problem could be easily avoided if the developers had used 'purify' to check for memory leaks. Or are the open-sourcers too high and mighty to use 'proprietary' software even when it would improve the quality of their code ?
OpenSSh uses zlib - if you happen to compile OpenSSH statically with zlib (I think thats the default), one more upgrade cycle after the latest OpenSSH 3.0.2p1 bug... :(
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
Try using the ldd command, which prints dynamic library dependencies. Something along the lines of
/usr/bin | xargs ldd
find
should give you something to grep through, although because of the way ldd formats it's output, you might need something a bit more intelligent to find exactly what you want (i.e. a list of files linked against libz). I'm not a perl guru, but i don't think it would take too long to knock together a suitable script.
Fabricate diem, punc
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!
I'm currently running this command against my /usr/src directory, just to get a preliminary list of packages to recompile:
grep '-lz' `find . -name 'Makefile'` > ~/zlib-dependencies
Assuming you've still got your source tree intact since you compiled, this should find all makefiles which reference the zip library. If you've deleted any source directories, you will have to untar them and run configure again to build the makefiles.
Living better through chemicals
Part 2: packages containing libz/zlib
From part 2:
Timeo idiotikOS et dona ferentes
The assertion lets you catch the logic error that led to the second free during debugging. Presumably, your code path wasn't expecting the pointer to already be free at that point; otherwise, you would have designed it to handle that case already.
Then, in production code, if you do take that path, you'll get the harmless no-op free(0). (You do build production with -DNDEBUG, right?)
There are the right ways, then there is the easy, 99% effective way. The easy way is to search for very specific error message strings, which are sort of a fingerprint for most software. I compiled zlib then used "strings libz.a" to find these error messages:
/usr/bin.
too many length or distance symbols
invalid literal/length code
A quick grep for one of those two strings reveals quite a number of statically linked versions of zlib in
Utter nonsense - the standard regarding C is quite clear and free()'ing a pointer twice is a bug; the behaviour undefined; end of story.
Trying to load off flaws onto others is not insightful but unproffesional and does not solve problems in the real world.
Cool but it still bugs me when people say Linux just stole it's TCP/IP, VM etc from BSD.
They never offer any evidance of it and all it serves to do is belittle the efferts of the linux community.
I understand that these people don't represent the BSD community. It's still anoying though.
I'm verry thankfull for what Linux/GNU has given me for free.
how else would a kid like me get access to UNIX a C compiler etc.
And if the BSD community supplied any of that they diserve there props too.
But the guy didn't have to be a dick about it is all I'm trying to say .
I know I'm going to hell, I'm just trying to get good seats.
Good info. It's surprising how much stuff gets a hit using this - most of the commercially-produced stuff on my hosts. Real player, Adobe acrobat reader, Netscape, most of the Loki games, the Flash Netscape plugin, among others. I have an old version of commercial ssh, which has linked itself statically as well. That's the one I'm really concerned about; sounds like time to switch to openssh, and make sure it's compiled dynamically.
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.Don't be ridiculous. Get your facts straight. Every good UNIX programmer knows that glibc's malloc is based on Doug Lea's excellent malloc library which one of the fastest and most space efficient single-threaded memory allocators available - much much better than the BSD version. I even recall a BSD mailing list thread not too long ago about wanting to incorporate the Lea-based allocator to replace the inefficient powers-of-two based allocator used in BSD.
Nope, my post is still at 1, but since you posted a 2 post in reply to it, which was deemed Interesting (+1), it now shows up as it's the parent.
...
So, if someone is browsing at x, and you post at y, and someone replies at z - we get the following
x y z
0 2 2 - you see both
1 1 2 - you see both
1 0 2 - you still see both
2 0 2 - you still see both
3 1 3 - you still see both (pretty cool)
3 -1 3 - you still see both
This is why you shouldn't reply to 0 or -1 posts, unless you wish to legitimize them.
Of course, there's the friend/foe bonus too. And in mine, it adds +1 for some posts (Informative) and -1 for others (Troll).
Brings me back to my game design days
and yes, it's me.
No, one they stole, one they wrote themselves.
Linux didn't steal shit otherwise someone would post some code comparissions by now. It's not exacly hard to get the code (There both free for download).
So my message to you trolls is put up or shut up.
I want to see proof showing that the code used in the linux kernel was copyed from BSD.
Until then go fuck you self.
I know I'm going to hell, I'm just trying to get good seats.
AFAIK: The kernel doesn't use the glibc C library. It has its own memory management code which presumably the kernel zlib code uses. This memory manager may or may not guard against free()ing the same area twice.
But what is the use of zlib in the kernel anyway? Just to uncompress the vmlinuz image before the kernel starts? If so it's not much of a vulnerability, if you can corrupt the vmlinuz file then you can control the whole system anyway.
-- Ed Avis ed@membled.com