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."

Comments

Modularised code will always have this problem.

[Ckwop]

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.

Re:Modularised code will always have this problem.

[mistersooreams]

There's a compile option in Visual C++ that allows automatic buffer overflow protection

Is there? I haven't seen it. Even if there is (and I'm inclined to trust you), the reason that no one uses it is because it slows programs down so much. The pointer semantics of languages like C and C++ are fundamentally dangerous and the only way you can make them safe (checking every dereference individually) is painfully slow. I think a factor of three or four was the general consensus on /. last time this debate came up.

I guess it's about time for the Slashdot trolls to start calling for the end of C and C++. Strangely, I think I'm starting to agree with them, at least above the kernel level. Is speed really so critical in zlib?

Re:Modularised code will always have this problem.

[Ckwop]

See here

On the broad issue on whether we should be using other languages, I think that saying "the programmer should carefully" is a bit misguided. Humans make mistakes and this is something that computers can do very well. Besides, if coding in such languages is slow, we can use a profiler to find the hot-spots and optimise the slow section using a lower level language.

For that reason, I don't really buy the "but it's too slow argument" - I think it's a good trade-off to use a language that doesn't allow buffer-overflows.

Simon.

Re:Modularised code will always have this problem.

[aws4y]

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.

The problem I have with this statement is that any checks that Visual C++ may have are at best a fig leaf. Buffer Overflow protection is something that has dogged not just programers but hardware manufactures for decades now. If security is of such great consern why not make the assembler do buffer checks?, why not the operating system? why not the processor?, why not create a ram infrasturcture called SDDR in which the RAM itself does not allow anything to be accessed without a secure hash? the answer to all of these questions is that for every solution, event the stupid one at the bottom, the buffer overflow might take on a new form or the security measures themselves may backfire.

Ultimatly the parent is IMHO over reacting, we are always going to have buffer overflows. This is not necissarily a problem so long as people are willing to disclose the vulnerability and work hard to get it patched before an exploit is out in the wild. This is the main argument as to why Microsoft software is insecure because often known vulnerabilites go months without being patched. They are getting better but they are nowhere near the transparancy displayed here. They made a mistake in coding, they are attempting to fix it but until all the vulnerable aplications are patched we need to be on guard for signs of malicious behavior from programs relying on zlib. In other words this is just a part of life in the world of computing.

Re:Modularised code will always have this problem.

[Tyler Durden]

Why have hardware support that simply helps prevent buffer overflows when we can use hardware features that solve it? I believe that can be done with the NX bit in many modern processors. For more information, look in the Wikipedia entry for "buffer overflow". Getting all new machines to run with chips with this feature and operating systems to take advantage of it is the key to stopping the overflows, not new languages to generate low-level code.

The problem I have with the argument, "Sure the software checks in higher-level languages will slow things down significiantly, but computers are so much faster now," is simple. Ever notice how even as memory/video card frame-rates/hard-drive space increases exponentially it seems that the newest applications tend to still max them out to compete? Well the same thing applies to speed. It's tough to explain to your manager that you are going to purposefully use a language that cripples the efficiency of your newest application to anticiplate your own carelessness. (I'm not saying I'm any better than anyone else on this point. I've had my share of careless programming moments myself).

Does anyone know of any disadvantages to the NX bit that I don't know about? (Like significant slow-down worse than software checks or possible overflows that it would miss).

very complex code

[ep385]

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.

Re:If you link with zlib the right way, easy to fi

[macemoneta]

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.