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."
The patch, and the E-Week article and quote (Score:5, Informative)
Already patched (Score:4, Informative)
Not just IE (Score:3, Informative)
/Mikael
Re:Modularised code will always have this problem. (Score:3, Informative)
welcome to four days ago: [ GLSA 200507-05 ] (Score:2, Informative)
Glad I'm running Linux. (Score:4, Informative)
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!
Re:Modularised code will always have this problem. (Score:3, Informative)
However, all such methods introduce a very noticable performance penalty.
Furthermore, there are documented ways of bypassing all such stack protection mechanisms.
Stop bitching. Audit your goddamn code already. Or would you rather all the bugs be found by the bad guys (this one was found by the Gentoo security team)?
Re:despite being OSS... (Score:1, Informative)
Been at the crack pipe again? "Provided and/or discovered by: Tavis Ormandy, Gentoo Linux Security Audit Team" here [secunia.com].
Re:The patch, and the E-Week article and quote (Score:4, Informative)
For specific builds of individual programs, trivial. There are dozens of good, fast, and robust binary patching systems available - xdelta, bsdiff, and jojodiff are three F/OSS options. Of course, bandwidth is cheap enough these days that most people who use binaries can just download the new version in its entirety.
A general-purpose fix that could be applied to any application using a statically-linked zlib would be much harder, possibly even impossible. This is one of the major advantages of dynamic linking - that a security update to the library in question can automatically benefit any application that uses the library.
Perspective of non-C Programmers (Score:4, Informative)
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 [paulgraham.com].
Re:Already patched (Score:2, Informative)
Gentoo announced the bug July 5th [gentoo.org] and had the patch a day later.
Re:Modularised code will always have this problem. (Score:5, Informative)
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).
Actually, automatic checking is very much possible, and has been for years. For example, Bounds checking gcc [ic.ac.uk] (that website is down right now, so try my page on the subject [annexia.org]). That was written in 1994, and there are newer systems available now which don't have such a serious performance penalty.
The real solution is to stop writing critical code in C. Other languages provide bounds checking, and are faster and safer than C: for example OCaml [cocan.org] which I prefer nowadays.
Rich.
Re:Perspective of non-C Programmers (Score:5, Informative)
Re:Perspective of non-C Programmers (Score:4, Informative)
Please. This is a very boring misconception about types. It's not a type error. It's a pointer arithmetic error. Nothing a type system à la ML, Java, CL, whatever would have corrected.
However, mandatory bound checking on arrays, at runtime, in those languages would have caught the problem.
There exist type systems that can catch these kind of errors, but they are very cumbersome, and not very practical.
Re:Already patched (Score:2, Informative)
On OpenBSD
Re:Modularised code will always have this problem. (Score:4, Informative)
There are a few reasons, though, why we don't use this system. One is that loading descriptors is slow because it was never optimized in the CPU with the equivalent of a TLB as for paging. The other is that using segmentation requires 48-bit pointers rather than 32-bit pointers, or it requires loading segmentation registers and doing a dance with those. I suppose using longer pointers was a problem back in the days when memory was scarce, but it's hardly a problem now (check out 64-bit). Intel *could have* made segment descriptor access checks and loading fast, but I guess there wasn't a demand for it once paging was available.
BSD Status (Score:5, Informative)
OpenBSD is affected, and was patched [openbsd.org] on the 6th of June
FreeBSD is affected, and was patched [freebsd.org] on the 6th of June
NetBSD base system is not affected, but a zlib from pkgsrc is, and was patched [netbsd.org] on the 8th of June
Better yet... (Score:3, Informative)
Re:BSD Status (Score:2, Informative)
Re:despite being OSS... (Score:4, Informative)
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.
Re:Perspective of non-C Programmers (Score:5, Informative)
Why does this topic bring the, uh, technically challenged out of the woodwork?
I'm a Ph.D. computer science professor with 20 years of experience in design and implementation of programming languages, and the co-author of a C-like programming language [nickle.org] featuring static and dynamic typing and runtime operand checking. The parent poster is confused.
Static type checking involves automatically recognizing type-unsafe operations at compile time. In many programming languages, including C, if you write"s" - 1 the + operation is ill-defined, because the left-hand operand is of the wrong type: i.e., there is no string that is a legal operation to the - operator. The compiler can detect this at compile time and refuse to compile the program.
Dynamic type checking involves automatically recognizing type-unsafe operations at run time. In many programming languages, such as Python, if you write"s" - 1 inside a function definition, the compiler will not detect the problem, because the general problem of detecting this kind of error is unsolvable unless one restricts what programmers can write. Instead, the execution engine can detect the problem at runtime when the - is evaluated and refuse to continue executing the program.
Runtime operand checking involves automatically recognizing at runtime that an operation has an operand that, while of a type that might be legal for the operation being performed, is nonetheless illegal for that operation. In many languages, including Python, if you write 1 / 0 no error will be reported at compile time, because detecting such errors is in general impossible. Instead, the execution engine can detect the problem at runtime, and prevent execution from continuing.
(Of course, there also is such a thing as static operand checking, which bears the same relation to runtime operand checking that static type checking does to runtime type checking. This is a hot research topic right now.)
C's problem is that it (a) does not have a "safe" static type system, (b) does not have any dynamic type checking, and (c) has no operand checking. This combination of misfeatures is incredibly and obviously error-prone; offhand, I can think of no other popular language (not derived from C) that is broken in this fashion. Fixing (a) and/or (b) is not sufficient---(c) also needs to be fixed. Java, for example, has shown that this can be done in a C-like compiled language without noticeable loss of efficiency. (This was shown for PL/I more than 30 years ago, so it's no surprise.)
The parent post gives an example in which the index argument to an array dereference is of the correct type and has correct operands. If x[2] was evaluated, this would be an operand error, since the combination of arguments x and 2 is not a legal operand combination for the array dereference operator. With the statement as given in the parent post, I'm not sure what principle it was trying to illustrate. I think, though, that it doesn't much matter.
Re:If you link with zlib the right way, easy to fi (Score:3, Informative)
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.
Re:I love when this happens (Score:2, Informative)
What!!! The gentoo/bsd crowd wouldn't staticly link zlib. They would only need to rebuild one package. You sir, are full of crap.
Re:Modularised code will always have this problem. (Score:5, Informative)
Oh please. When are we going to get past, "I know! Let's just write perfect software all the time!"
There will always be some subset of people who refuse to accept the impossibility of absolute perfection. I believe their thinking goes like this:
(I never had to work for anyone who said the above, but my brother in law, a coder for a large trucking company, had to put up with a "quality consultant" whose entire theory was essentially the above, punctuated with shouts of "attention to detail, people!" in between such lectures. A similar consultant is documented in an email in "The Dilbert Principle". Sadly, it's probably not the same guy.)
Gentoo has it's place, too (Score:2, Informative)
Re:I love when this happens (Score:3, Informative)
Please, learn how a Linux/BSD system work, how linked/static binaries work before start critiquing other distributions with non-sense.
Re:Glad I'm running Linux. (Score:2, Informative)
Not entirely true. See this list [google.com] from the debian-security mailing list for a few which are statically linked.
Re:Modularised code will always have this problem. (Score:3, Informative)
Python can't, at least without embedding the python interpreter in the dll.
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?
Any language supports calling C libraries from that language. You have to, because for many things the only library available is in C, and there are millions of C libraries. Not so many support calling that language libraries from C - why would they? A big part of their attractiveness is their extensive standard library.
Re:Modularised code will always have this problem. (Score:3, Informative)
Personally, I work down a suite of tools to help ensure reliability:
1. Use a language and run-time that enforces bounds checking and managed memory. This is not always practial because of performance issues.
2. If I can't do that, use libraries that hide the complexity of managing memory (smart pointers, smart arrays, and the like). This is not entirely reliable because it depends on the discipline of the programmer.
3. If I can't do that, I use tools like valgrind in conjunctgion with unit testing, so that l can find memory errors after the fact. This can't be completely trusted because it depends on the completeness of the test suite.
4. Code carefully and cross my fingers.