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.
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.
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
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 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.
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.
Here is a sample of the Scan log.
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."