Zlib Security Flaw Could Cause Widespread Trouble 372
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."
Re:Modularised code will always have this problem. (Score:5, Insightful)
For some reason your comment is moderated 'troll', probably because you had the filthy guts of uttering the Forbidden Word 'Visual C++'.
However, your question is prefectly valid. Automatic buffer overflow protection only covers the straightforward buffer overflow problems, i.e. array index overflows. In the case of more complex pointer arithmetic, where most of these problems occur, automatic protection is not possible (at least not without losing the option of pointer arithmetic).
Re:Modularised code will always have this problem. (Score:2, Insightful)
In the first case most users will just open the file to check the contents, which is a feature, fast access means you'll use the files in another way. An 8 second access time slows you down, so you'll be less inclined to check the contents.
This goes for everything in computing. Previewing a filter change in your image program before applying it? If it takes 10 secs, why bother..., if it takes 2 secs, sure.
Re:Modularised code will always have this problem. (Score:3, Insightful)
So get over it, "Da Fokka", and all you other insecure OSS fanboys, too.
Actually, I agree with the first part of your post, I use VS.NET 2005 and I love it.
Here is a pointer [wikipedia.org] that will help you understand the first part of my post.
despite being OSS... (Score:1, Insightful)
Let's face it, going through code isn't that much fun, and only big projects find stuff because many people are activly changing the code (and thus forced to read parts of it since the documentation isn't there(proper documentation, not a shabby man page and some out of date howto)). Which is probably why we've got new programming languages which do their best to avoid "security flaw by programming language"
Re:Modularised code will always have this problem. (Score:3, Insightful)
A case for packaging systems (Score:5, Insightful)
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...
If you link with zlib the right way, easy to fix (Score:5, Insightful)
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.
A skilled worker chooses his tools carefully (Score:1, Insightful)
The direct cause of this of course is programmer error. But lets be honest, we cannot realisticly expect a programmer to check every single pointer related statement in systems running into the thousands of KLOCs. You can certainly invest a lot of effort and reduce the number of potential bugs, but even then you cannot be sure that you've found them all. We really need to start using tooling (languages, compilers, APIs etc etc) that removes this task from the progammer. I'm not saying that every software project out there is suitable for this, but most userspace programs should be.
I'd far rather have an application that today is a little slower, but secure instead of fast but unsecure. Think about it, today it'll be slow and secure, in a year time it'll be fast and secure once the hardware cycle has caught up with the extra overhead introduced.
Re:Glad I'm running Linux. (Score:4, Insightful)
Re:Modularised code will always have this problem. (Score:3, Insightful)
Your argument assumes that buffer overflows are a natural and unavoidable aspect of C programming. I can show you plenty of examples of C modules without buffer overflows. Writing a complex system without buffer overflows is only a matter of using these modules together with a carefully constructed interface.
I also doubt your argument that achieving security in software is impossible. People have been doing it for years and years. Unfortuately we are seeing more and more security breaks because the percentage of careless programmers out there has been steadily rising.
You can write 100% bug-free code if you take your time, are careful and methodical, and do thorough unit and system tests. Those with the "Hey, all warnings but no errors--Ship It!" mentality give the software writing skill a bad name.
Re:Modularised code will always have this problem. (Score:4, Insightful)
We are talking about a low level LIBRARY here. Which means reentrant, placement independant code, efficiency, API accessible easily to any language and compiler.
I think all of this is still very difficult to do right in other languages than C. It is already very difficult to do in C++.
Anyway, your language without buffer overflows would not use pointer arithmetic, so would create a zlib a lot slower than the one we now, even if you optimise your high level language to the max.
When you see that what takes time are basic lines of your language, you are toast.
Re:Modularised code will always have this problem. (Score:2, Insightful)
I can't resist:
Apperently they *don't* do this for everything, or you've just shown that code inspection won't trigger everything at all. And so does Visual C++'s rumoured "magical buffer overflow detection". Quite frankly, it's crap. It'll only trigger on *big* hefty overruns, and almost never on an off-by-one. And even when it triggers, all it does it put up the mightily annoying and terribly useless "DAMAGE detected after NORMAL block. Press Cancel to continue, Retry to abort, and abort to debug". And no, it won't even tell you exactly what variables were stored around the so-called "NORMAL" block. Bah.
Correct input validation is the key (Score:4, Insightful)
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.
So, what's wrong with modularization? (Score:3, Insightful)
Re:So, what's wrong with modularization? (Score:2, Insightful)
Yes.
Simply updating one shared library (libz.so or zlib.dll) will fix the problem for all of your installed applications. No?
No. Some applications ship their own zlib and/or statically link to it, circumventing the benefits of modularity.
Re:Der.. (Score:3, Insightful)
I see. That must be why they not only use zlib, but also remove the copyright strings.
(Search for "microsoft") [zlib.net]
Re:If you link with zlib the right way, easy to fi (Score:2, Insightful)
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!
Correct interface design. (Score:3, Insightful)
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.
Yawn (Score:4, Insightful)
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."
Re:Modularised code will always have this problem. (Score:5, Insightful)
> in C.
Yeah. Right. It pisses me off that whenever security gets spoken of here, someone comes up with this pathetic magic fix.
Look, for commonly used libraries like zlib, you can't code it in anything but C. That is because only a C library can be called from every other language out there. Code it in, say, Python, and suddenly you lost all but Python programmers. Same goes for almost everything else. Yay for reuse of code!
Point in case - you write "for example OCaml which I prefer nowadays". Keyword 'nowadays'. What happens when you move on to the next big thing that comes along? Can you call libraries written in OCaml from that language? Extremely unlikely. But I bet it supports calling C libraries, because no serious language can avoid that.
Lots can be done to make C code safer. For example using safe versions of all non-safe functions, and integrating with a proper security model in the OS to drop non-needed permissions. But dropping the only language that can share code with everything else out there is just silly.
Re:Not complex (Score:1, Insightful)
In short, the shootout data is crap. Basing your conclusions on it is about as intelligent as getting your news from Fox.
Re:Modularised code will always have this problem. (Score:4, Insightful)
This is wrong. What you meant to say is that only a library using the C calling convention can be called from every other language out there. Heck, I can write libraries in Visual Basic of all possible languages, and still have them compile against a C program (on Windows, and I'm sure it'll work on other platforms if someone ports vbc). If a language can call C functions, then it is likely (with a little effort) to have functions called by C - or any language that can call "C".
I haven't used Python or OCaml, but if either of those languages can produce C-style
What's more, you say that C can work with (at least as a library) every other language out there. So what's the problem with a small C-language interface that just calls the Python function and returns the result?
Re:Modularised code will always have this problem. (Score:1, Insightful)
In fact, contrary to the popular urban myth that "C is fast", C's essentially unconstrained pointers (which show up as "programmer-accessible pointer arithmetic") inhibit a great many compiler optimizations. This has been a known situation in the compiler-optimization community for over twenty years.