Slashdot Mirror
Zlib Security Flaw Could Cause Widespread Trouble
BlueSharpieOfDoom writes "Whitedust has an interesting article posted about the new zlib buffer overflow. It affects countless software applications, even on Microsoft Windows. Some of the most affected application are those that are able to use the PNG graphic format, as zlib is wildely used in compression of PNG images. Zlib was also in the news in 2002 because of a flaw found in the way it handled memory allocation. The new hole could allow remote attackers to crash the vulnerable program or even the possiblity of executing arbitrary code."
Why are we still having buffer overflows? There's a compile option in Visual C++ that allows automatic buffer overflow protection. Does GCC have this switch? If so, why not? And why are people not using this? We have enough processing power on a typical PC to spend on these security such as this. Performance is not an excuse.
Looking further, this is an interesting example of the problems with monoculture. The BSD TCP/IP stack was copied for Windows and Mac OSX - this is great, it saves a tonne of time but you also means you inherit the exact same bugs as the BSD stack. This gives you an impression of how difficult it is to design secure operating system. If you borrow code such as this, you have to make sure it's secure. You can't really do that without line by line analysis which is unrealistic. In libraries the problem is especially accute. If you make a mistake in a well used library it could effect hundreds of pieces of software, as we've seen here.
We can't modularise security either, like we can modularise functionality, because you can take two secure components and put them together and get insecurity. Despite the grand claims people make about formal verification, even this isn't enough. The problem with formal verification is that the abstraction of the language you're using to obtain your proof may not adequately represent the way the compiler actually compiles the program. Besides, it's possible to engineer a compiler that deliberately miscompiles itself such that it compiles programs with security flaws in it.
What i'm trying to say is that despite what the zealots say, achieving security in software is impossible. The best we can do migitate the risk the best we can. The lesson to learn from security flaws such as this is that while code-reuse is good for maintainability and productivity, for security it's not great. As always, security is a trade-off and the trade-off here is whether we want to develop easy to maintain software quickly or whether we want to run the risk of these exploits being exploited. Personally, I fall in the code-reuse camp.
Simon.
Because Firefox renders PNG completely, it is prone to these sort of errors. However there is one browser that won't need a patch issued to be safe from this bug, which is Internet Explorer. While IE can render PNG a little, it hasn't implemented the full technology. By using IE, you ensure that you will be safe from any bugs that arise from new technologies, such as PNG.
So next time someone recommends a browser. Stop and wonder about what technology the latest browser has implemented properly without regard to any security issues, and remember that it will be decades before IE implements the technology (if it ever does) so it will be safe for quite some time, by being a stable browser that rarely changes.
Mods: This is not an attempt at troll, but a parody of the typical "This is why you should switch to Firefox" posts whenever a vulnerability involving IE. It should be painfully obvious, but then again most of you are on crack.
Both Debian and Ubuntu released the patch for this problem 2 days ago. I assume the other big names in the Linux world have or will follow suit shortly.
/Mikael
Greylisting is to SMTP as NAT is to IPv4
even on Microsoft Windows
NOT WINDOWS! I was just about to move to it from this Linux thing!
I like muppets.
http://forums.gentoo.org/viewtopic-t-356659.html
I'm running RHN alert notification on Fedora Core 3, and my version of zlib has already been updated with a patch for CAN-2005-2096, the zlib overflow bug.
It's interesting to read about these as they occur, but it's a nice feeling that my operating system is so well taken care of. Too bad that all personal computers aren't set up for this kind of timely response. I wonder about those millions of library computers, home PCs, small business computers, and other institutional setups where no one even understands the concept of an update, let alone regularly runs the Windows "security" update program.
Another reason to use Linux!
it's = "it is"; its = possessive. E.g., it's flapping its wings.
Opera 8.01 works fine. But what else would you expect from Scandinavians.
Revolution = Evolution
We've seen many posts on slashdot recently explaining why the packaging systems are no longer desirable (if they ever were), that dependencies are a PITA (even with systems à la APT), etc.
But when you have a flaw in a very popular library like this, you'll be happy to know that all 354 programs using this library on your system will be safe once the shared library is upgraded... Windows users must upgrade every software manually, and they often won't be able to know precisely what software may be affected...
And this, my friends, is why 'dependency hell' is a good thing. A flaw is found in zlib - no trouble, just run the normal update program that comes with your distribution, 'yum update' or whatever, the centrally installed zlib library will be updated, and all applications will start using it.
The trouble comes with those software authors that wanted to be clever and to 'cut down on dependencies' and included a whole copy of zlib statically linked into their application. Now you have to replace the whole app to remove the zlib security hole. The dependency on zlib is still there, just better hidden, and in a way that makes upgrading a lot harder.
If Microsoft had any sense, a zlib.dll would be bundled with Windows and then Office (and many other apps) could use it. But they wouldn't want to do that, partly because it would involve admitting that they use such third-party libraries.
-- Ed Avis ed@membled.com
It is really something that this flaw impacts so many applications.
This situation is unnecessary; the problem is that C is not a type-safe language, like ML, CAML, Haskell, Common Lisp, Scheme, Java, etc.
You could write that code in SML/CAML/Common Lisp and likely get it to run as fast or faster than the original (particularly if you did some space/time tradeoffs ala partial evaluation). Integration with the applications in the form of a library would be the tough part.
Here's a provocative bit from Paul Graham (Lisp expert entrepreneur) on buffer overflows.
http://www.thebricktestament.com/the_law/when_to_
Slander! I only mod people down when I'm off crack!
sig? Oh, that sig...
Yes, both Visual C++ and the GCC ProPolice extensions provide stack and heap protection. And in general these techniques have a minimal impact on execution speed. Unfortunately, this does not solve the problem. There are still viable attacks that can be preformed by avoiding the stack canaries or heap allocation headers and overwriting other vulnerable data. The probability of developing a successful exploit is lower, but it's still there.
I don't disagree that building secure applications is hard, but it's certainly not impossible. Modularized code just adds another layer of compilcation and potentially confusion. Most of this can be addressed by documenting the design and interface constraints, and ensuring that they're followed. At that point even most security vulnerabilities are primarily implementation defects. Defects will of course still occur, but the trick is to build systems that fail gracefully.
Developers must to account for defects and expect that every form of security protection will fail given enough time and effort. This is why the concept of "Defense in Depth" is so important. By layering protective measures you provide a level of security such that multiple layers have to fail before a compromise becomes truly serious. Combine that with logging and monitoring, and a successful attack while usually be identified before damage is done.
Take the above vulnerabiliy and assume it exists in an exploitable form in a web app running on Apache with a Postgres backend. If the server had been configured from a "Defense in Depth" perspective it would be running in a chroot jail as a low privilege account. Any database access required would be performed through a set of stored procedures or a middleware component that validates the user session and restricts data access. SELinux or GRSecurity would be used for fine grained user control on all running processes. All executables would also be compiled with stack and buffer protection.
In the above scenario, you see that this single exploit wouldn't get you much. However, most systems are deployed with one layer of security, and that's the problem.
Has anyone read the zlib code? While the author clearly tried to make it readable it's still very complex and it's very hard to see at a glance or even after many glances where potential buffer overflow problems may exist (or even where it might fail to implement the deflate algorithm). C is great language for writing an operating system where all you care about is setting bits in a machine register but this algorithm really taxes its abilties.
For comparison here is the deflate algorithm written in Common Lisp. It all fits neaty into a few pages. This is a far better language comparison example than the oft-cited hello world comparison.
or does it seem the end of the world will be caused by a buffer overflow?
For the undead crowd out there:
OpenBSD is affected, and was patched on the 6th of June
FreeBSD is affected, and was patched on the 6th of June
NetBSD base system is not affected, but a zlib from pkgsrc is, and was patched on the 8th of June
...instead of looking for information on the NX bit from the buffer overflow page in Wikipedia, look up the thing specifically here. Yeah.
Happy people make bad consumers.
It's all very good advocating the use of languages that mitigate against heap and stack overflows et al. But as the recent XML RPC vulnerability in PHP applications should reinforce, the bad guys are migrating to higher level language attacks too.
The fundamental problem is that all too often, different components of a system have are implemented with different input validation. For example a web browser component running an web application may accept all text input, whereas the backend database is only expecting a subset of text inputs.
Developers should establish what input the lowest level component and highest level components will require to get the job done and validate input into all components subject to these requirements. Where the lowest and highest level components have different requirements then the developer needs to define some method of encoding values that would otherwise be considered invalid, and ensure that all components enforce this encoding.
Tim Brown
If anything, this story is about how good modularization is. Simply updating one shared library (libz.so or zlib.dll) will fix the problem for all of your installed applications. No?
In Soviet Washington the swamp drains you.
If the argument were that simple, static linking would never occur.
The flip side of the argument is that installing a broken zlib will break all application that are dynamically linked, but have no effect on those that are statically linked.
Remember too that an upgrade to a dynamically linked function means that proper testing must include all software that uses that function. A statically linked application can be tested as a standalone unit.
The resulting isolation of points of failure and lower MTTR is often seen as an advantage in production environments.
I remember this specific situation occurring in a production environment I worked in. A common library was updated, causing the failure of multiple critical applications. The ones not impacted? Statically linked.
Both sides of the discussion clearly have advantages and disadvantages; they have to be weighed to determine the proper risk/benefit.
Can You Say Linux? I Knew That You Could.
Not in the least bit, observe, just verified with ldd that Xorg and firefox have libz dynamically linked in on my system, which means on program restart, it will pick up the code from the shared library at runtime. It's the whole point of a dynamicly linked library.
Now once upon a time, a lot of distributions (and open source projects out of the box even) would just static link in libz for some reason or another, but after some security issues in the past that caused massive headaches for package maintainers, that practice has largely ceased.
XML is like violence. If it doesn't solve the problem, use more.
A company of that size doesn't sneakily use 3rd party software.
I see. That must be why they not only use zlib, but also remove the copyright strings.
(Search for "microsoft")
In fact, this flaw was found by a security audit of an open source project, not by any of the closed source projects (like Microsoft Office) that make use of it.
The flip side of the argument is that installing a broken zlib will break all application that are dynamically linked, but have no effect on those that are statically linked.
That's why some people like to use (say) debian stable in production environments: security fixes are backported to the well-tested version of the lib, making a breakage quite unlikely.
If your post isn't total bullshit, I'm pissed! I think there should be repercussions for this totally irresponsible attitude we see coming from NASA. When you say "the developers" I'm assuming you mean the developers of the SWIFT mission software, not the developers of zlib, because otherwise we wouldn't be seeing this article on Slashdot!
If, for some reason this turns into another Sasser or Code Red, I think penalties aught to be sought against these fuckwads. Using OSS has responsibilities associated with it too, you know!
"terrorism" and "pedophilia" are the root passwords to the Constitution
Here is a sample of the Scan log.
Input is just one interface... every internal interface in a system also needs to be designed so that it only accepts known safe or encapsulated data, and if there's limits on safe input they need to be something that the upper layer can reasonably check without having to effectively replicate the component it's passing the data to.
Let's say, for example, that this overflow involves a pathological artificially created compressed stream. To test for it, you may have to implement most of the algorithms in zlib. To test for it in an image file, you'd have to implement a decoder for that image format that would at least extract the compressed streams to pass to zlib... as well as implementing zlib.
If the problem in the underlying component is a bug that involves the structure of a complexly encoded data stream, it can't really be described in the input or any internal interfaces. Which means that you're not going to catch it with input validation.
Which means that while resiliant interface design is important, it's not going to be enough to block deep attacks. The only way to do that is to make the components themselves secure and resilient. And depending on input validation can cause problems, just ask anyone with an unusual surname.
Zlib itself contains 8000 lines of code. Not very big, is it? It's been around for years and is widely used, so in theory a lot of people have been able to look at it. And yet, after all these years, they are still finding buffer overflows in these 8000 lines of code.
Zlib was not written by monkeys. It was written by very smart, experienced coders. And yet somehow they are not able to write 8000 lines of code without multiple serious buffer overflows.
As long as code like this is written in C we're going to have these problems.
Saying, "there's a critical buffer overflow in a library written in C" is as newsworthy as saying "when I bang my head against the wall I get a headache."
This is really an argument for versioning dynamic libraries very carefully. The Linux dynamic linker has perfectly good support for avoiding problems like this. Each shared library has a "SONAME" field. Programs linked against the library should be able to use any later version of the library with the same SONAME. If the library changes in some way that breaks desireable behavior, it is supposed to get a new SONAME. The system keeps two sets of symlinks, in addition to the object files: libfoo.so is the latest version and libfoo.so.{version} is the latest version of a compatible series. When you link a program, you use the libfoo.so to find which series is newest. When you run a program, you use libfoo.so.{version}, so you get the newest compatible version.
It sounds like the problem you had was that the common library version number wasn't changed when it should have been. If it had been changed, there would have been no effect on any of the existing programs, static or dynamic. Of course, for a two-line fix to a function which only changes the behavior of the library when dealing with corrupted files, and resulted in a buffer overflow instead of an error, the change won't break anything except attacks, so keeping the same SONAME is right.
Note that you can see this by doing "ldd {program}", which will report how it looks for each library and what it finds. And you can see that zlib claims to be backwards compatible all the way through 1.x, while openssl is only to 0.9.7.
Luckily there were some Gentooists recompiling their systems packages every so often, since the vulnerability was found by the Gentoo Linux Security Audit Team here. I've always thought the the more projects making use of the same library, as well as, the platforms a project is ported to eventually improves the quality and stability of the code. In this case the security was improved, but in general the abstracted parts of the code improve.
--Excyl
What are you talking about? All I had to do was to rebuild zlib and restart apps that used zlib. Oh, I did that while I ssh back home from work, all I had to do was to fire off a couple commands to do the same fix as apt-get.
Please, learn how a Linux/BSD system work, how linked/static binaries work before start critiquing other distributions with non-sense.
Please direct all bug reports to