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."
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).
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
Are all the apps on your system that have zlib compiled into them statically patched, too? (Although I'm not sure if that's even an issue.)
Switch back to Slashdot's D1 system.
You don't buy the "but it's too slow argument", OK, that's your right, and it is not surprising when your vision of programming is so narrow.
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.
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
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."
> The real solution is to stop writing critical code
> 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.
That is because only a C library can be called from every other language out there.
.lib's, .dll's, .so's, .obj's, whatever, then they'll work as well from C. I've seen libraries fully usable in C coded in Delphi, because Delphi designed its object file format to interface with C.
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?