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.
zlib is not os dependent. Many Windows based products/projects use it as well. Is there some linux specific issues related to this overflow issue?... or is it just a headline hype thing
Credit where credit is due...
by
ubiquitin
·
· Score: 4, Interesting
Dumb security question
by
wrinkledshirt
·
· Score: 4, Interesting
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.
My question is this: How feasible would it be for someone to take a computer and have it do nothing but pattern-matching through all the source code in a typical Linux distribution, looking specifically for problem areas like these? Obviously we couldn't rely on it as a foolproof audit, but has something like this ever been considered?
--
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Re:Dumb security question
by
SirSlud
·
· Score: 5, Interesting
Some software packages do this.. purify, etc. They're pretty expensive tho. The problem is that the logic that results in a buffer overflow error can be VERY complicated, and so its extremely difficult to spot sometimes even for the seasoned developer, nevermind a clever regex.
On the flip side, finding lots of memcpy's instead of strncpy might help you find the 'dumb' overflow bugs, but one would hope those arn't the ones we're most concerned about.:P Mostly, when copying and moving and generally playing with memory, if you spot functions without buffer limit or max byte limit arguments, you *might* be openening yourself up for trouble. Unfortunately, as I said, those are the easy ones.:) In reality, buffer overflow errors (and off-by-one bugs generally follow the 'simple errors can result from terribly complicated logic' construct of buffer overflow bugs) can be extremely difficult to spot if your input parsing/copying/moving mechanism is non-trivial.
-- "Old man yells at systemd"
Staticly linked-implication
by
joeflies
·
· Score: 3, Interesting
As the article points out, anything that uses zlib staticly can't be fixed by the new zlib patch until it's recompiled.
As I'm not a programmer, what can I grep to search stuff I've compiled from source to determine what's using staticly linked zlib?
Is it just me, or have there been a really huge amount of security issues with Free/Open Source software this year?
It just seems like there's a new hole (or two) every week. Let's see, we've had openssh, zlib, php, mod_ssl, cvs, cups, rsync, exim, ncurses, glibc and more, just since January. We've still got two-thirds of the year to go. Anyone want to make bets on what other projects will get hit? I think we're going to see problems with XFree86, samba, and apache.
So, my question is this: Do you think that this is simply a bad time for FS/OSS security? Are we at the threshold where there are enough eyes on the code to locate these kinds of bugs? Or is the quality of FS/OSS declining?
Easy Workaround!
by
dtrombley
·
· Score: 5, Interesting
Well, it won't prevent the DoS aspect - but, from the malloc manpage:
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.
Seems worth it while all pour through the symbol tables of our static binaries (and recompile the stripped ones. =( )
On another note, I've always regarded security bulletins as a one-way process... For example, I couldn't find a way to tell RedHat they'd omitted this (seemingly important?) reminder. Any thoughts about this? (admittedly i didn't look very hard for very long)
Re:Should I upgrade my kernel?
by
ceswiedler
·
· Score: 4, Interesting
The only dynamic linking the kernel uses is modules, which aren't used for providing library routines like zlib. The kernel does not link.so files. The code is almost certainly cut-and-pasted into the ppp compression code somewhere.
Re:The article says this is only affecting Linux
by
Ded+Bob
·
· Score: 3, Interesting
I think it does hit FreeBSD. FreeBSD uses zlib v1.1.3. v1.1.4 has the fix (http://www.gzip.org/zlib/). No security announcement has arrived in my mailbox, yet I expect it soon.
Would be impossible in garbage-collected language!
by
Tom7
·
· Score: 5, Interesting
Like most recent security holes in linux software, this one would be unexploitable in a modern safe language. (In fact it would be *impossible* to make this error in a garbage-collected language!)
The typical response I hear to this kind of comment is that "high level languages are inefficient". (I don't belive this is true, but most other people here do.) But whatever, let's pretend they are.
Now, what kind of crazy world do we live in where we value performance more than correctness (security)?? We are seeing more and more security holes as we try to write bigger and bigger packages in C. Why do we accept this? Who here really cares more about the performance of zlib than the time it takes for them to patch all of their statically-linked software, and their risk of being rooted until they do? I sure don't.
Forget about all this "coding practices" stuff. It simply takes too much effort to produce bug-free code in C. The OpenBSD people, kings of code review, just had an exploitable bug in sshd! While we need to use C for some tasks (ie, most parts of the kernel), I think we are seriously unpowered to do this for most applications (as evidenced by the high number of simple errors made, and sometimes caught).
If we simply wrote our software in high level languages, we would automatically rule out the largest classes of security holes, which would give us a lot more time to work on more important things, like high level architecture review and optimizations. I think we'd end up with a better system. So what's keeping us?
Traceroute hack not a double free
by
Huusker
·
· Score: 3, Interesting
I think the traceroute hack is an example of freeing garbage, not a double-free(). The garbage being freed happens to be part of the command line, which is how the hacker injected his/bin/sh. The traceroute exploit description did not give full details, but I don't see how it could be possible to use modify ((int*)p)-1 using the zlib vulnerability. Remember that all mallocs are sizeof(8) aligned and have a minimum size of 16 (with overhead and internal fragmentation).
Slashdot Mirror
zlib is not os dependent. Many Windows based products/projects use it as well. Is there some linux specific issues related to this overflow issue?... or is it just a headline hype thing
Owen Taylor at RedHat found the bug. He works on GTK among other things, as you can see from the GTK+ release notes he posted earlier this month: mail.gnome.org/archives/gtk-devel-list/2002-March/ msg00161.html
http://tinyurl.com/4ny52
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.
My question is this: How feasible would it be for someone to take a computer and have it do nothing but pattern-matching through all the source code in a typical Linux distribution, looking specifically for problem areas like these? Obviously we couldn't rely on it as a foolproof audit, but has something like this ever been considered?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
As I'm not a programmer, what can I grep to search stuff I've compiled from source to determine what's using staticly linked zlib?
Is it just me, or have there been a really huge amount of security issues with Free/Open Source software this year?
It just seems like there's a new hole (or two) every week. Let's see, we've had openssh, zlib, php, mod_ssl, cvs, cups, rsync, exim, ncurses, glibc and more, just since January. We've still got two-thirds of the year to go. Anyone want to make bets on what other projects will get hit? I think we're going to see problems with XFree86, samba, and apache.
So, my question is this: Do you think that this is simply a bad time for FS/OSS security? Are we at the threshold where there are enough eyes on the code to locate these kinds of bugs? Or is the quality of FS/OSS declining?
Well, it won't prevent the DoS aspect - but, from the malloc manpage:
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.
Seems worth it while all pour through the symbol tables of our static binaries (and recompile the stripped ones. =( )
On another note, I've always regarded security bulletins as a one-way process... For example, I couldn't find a way to tell RedHat they'd omitted this (seemingly important?) reminder. Any thoughts about this? (admittedly i didn't look very hard for very long)
The only dynamic linking the kernel uses is modules, which aren't used for providing library routines like zlib. The kernel does not link .so files. The code is almost certainly cut-and-pasted into the ppp compression code somewhere.
I think it does hit FreeBSD. FreeBSD uses zlib v1.1.3. v1.1.4 has the fix (http://www.gzip.org/zlib/). No security announcement has arrived in my mailbox, yet I expect it soon.
Like most recent security holes in linux software, this one would be unexploitable in a modern safe language. (In fact it would be *impossible* to make this error in a garbage-collected language!)
The typical response I hear to this kind of comment is that "high level languages are inefficient". (I don't belive this is true, but most other people here do.) But whatever, let's pretend they are.
Now, what kind of crazy world do we live in where we value performance more than correctness (security)?? We are seeing more and more security holes as we try to write bigger and bigger packages in C. Why do we accept this? Who here really cares more about the performance of zlib than the time it takes for them to patch all of their statically-linked software, and their risk of being rooted until they do? I sure don't.
Forget about all this "coding practices" stuff. It simply takes too much effort to produce bug-free code in C. The OpenBSD people, kings of code review, just had an exploitable bug in sshd! While we need to use C for some tasks (ie, most parts of the kernel), I think we are seriously unpowered to do this for most applications (as evidenced by the high number of simple errors made, and sometimes caught).
If we simply wrote our software in high level languages, we would automatically rule out the largest classes of security holes, which would give us a lot more time to work on more important things, like high level architecture review and optimizations. I think we'd end up with a better system. So what's keeping us?
For more discussion, see our big argument in the story about the OpenSSH root hole. http://slashdot.org/comments.pl?sid=29123&cid=3124 957
I think the traceroute hack is an example of freeing garbage, not a double-free(). The garbage being freed happens to be part of the command line, which is how the hacker injected his /bin/sh. The traceroute exploit description did not give full details, but I don't see how it could be possible to use modify ((int*)p)-1 using the zlib vulnerability. Remember that all mallocs are sizeof(8) aligned and have a minimum size of 16 (with overhead and internal fragmentation).