Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Zlib Security Flaw Could Cause Widespread Trouble

timothy posted more than 9 years ago | from the all-over-the-place dept.

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

cancel ×

372 comments

Sorry! There are no comments related to the filter you selected.

Modularised code will always have this problem. (5, Interesting)

Ckwop (707653) | more than 9 years ago | (#13025933)

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. (4, Interesting)

mistersooreams (811324) | more than 9 years ago | (#13025947)

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. (4, Interesting)

Ckwop (707653) | more than 9 years ago | (#13025969)

See here [developer.com]

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. (2, Informative)

grahammm (9083) | more than 9 years ago | (#13026035)

Also hardware support would help. Even 25 years ago the ICL 2900 series systems had a native hardware 'pointer' type (they called it a descriptor). This included in it the size of the object pointed to, and the hardware would check that any dereferences were not out of bounds.

Re:Modularised code will always have this problem. (1)

menkhaura (103150) | more than 9 years ago | (#13026197)

That would be neat indeed; but how could such a hardware pointer be included in the modern, convoluted, ubiquous x86 instruction set? Yeah, not all the world is a x86, but most of it is.

Could some similar feature be supported by the operating system, or even the libc, by keeping track of every malloc, calloc, realloc, and whatever, reserving some memory space to store information about malloc'ed objects and their sizes?

Re:Modularised code will always have this problem. (1)

sqlrob (173498) | more than 9 years ago | (#13026214)

ummm, most C libraries do that (how do you expect it to deallocate if it doesn't know the size?)

The problem is the dereference beyond the range of the block. Either all dereferences have to go through the library (slow) or you need hardware support.

And even hardware support doesn't completely solve the problem. Nothing prevents you from hitting another block that was allocated, just not the one you're looking at.

Re:Modularised code will always have this problem. (4, Informative)

Anonymous Coward | more than 9 years ago | (#13026298)

Actually, x86 already does, but nobody uses these features. When they fixed segmentation with the 386, segments were now accessed through selectors and offsets. The selectors pointed to one of two tables (GDT - global descriptor table or LDT - local descriptor table). Whenever a memory access was made using a selector, the CPU would look up the descriptor corresponding to the selector. It would check whether the current program had necessary access rights and privilege. If not, then a GPF would be thrown. Segments can be marked as read-only, read-write, executable and maybe a few more combos. Although the GDT and LDT each have only room for 8192 entries, that's still probably more than most programs would need. Each segment could correspond to a single object or array of primitive objects. There would be no buffer overflows because the CPU catches attempts to go beyond the limit of a segment. Stack data couldn't be executed inadvertently because the stack segment would properly be marked as non-executable.

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.

Re:Modularised code will always have this problem. (4, Interesting)

Tyler Durden (136036) | more than 9 years ago | (#13026321)

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

Re:Modularised code will always have this problem. (3, Insightful)

ookaze (227977) | more than 9 years ago | (#13026185)

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.

Re:Modularised code will always have this problem. (2, Insightful)

Anonymous Coward | more than 9 years ago | (#13025989)

Speed is and will always be a feature. Let's say you have a program that takes 1 second to open a zip/gzip file and another program that takes 8 seconds to open a zip/gzip file.
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. (2, Insightful)

Detritus (11846) | more than 9 years ago | (#13026114)

I like programming in C, but I recognize that it is completely inappropriate for many of the applications that it is used for. When modern computers are thousands of times faster than those used for the development of C, we can afford to spend some CPU cycles on reliability and security.

Re:Modularised code will always have this problem. (1)

springbox (853816) | more than 9 years ago | (#13026222)

Is there? I haven't seen it.

The updated complier is included in the latest version of the Platform SDK or the free command line compiler that Microsoft is giving away. I haven't actually used it, but I would suspect that most people would only activate it while they were in the process of testing.

Re:Modularised code will always have this problem. (5, Insightful)

Da Fokka (94074) | more than 9 years ago | (#13025958)

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. (2, Funny)

Da Fokka (94074) | more than 9 years ago | (#13025965)

For some reason your comment is moderated 'troll', probably because you had the filthy guts of uttering the Forbidden Word 'Visual C++'.

Actually, 'forbidden term' would be more appropriate. My bad.

Re:Modularised code will always have this problem. (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13026020)

"probably because you had the filthy guts of uttering the Forbidden Word 'Visual C++'"

What the hell? The Visual C++ IDE (Visual Studio) is superior to any OSS I've seen so far, including Eclipse and KDevelop and every other IDE I've tried so far for Linux. I don't see why Linux users and OSS fans continually blam a product that is better than the OSS equivelant.

Try using my paradigm, "Use what's best". Here's what I use on my development machine:

Windows XP SP2 (Not Linux)
Visual Studio .NET 2003 Professional [Visual C++ .NET 2003] (Not Eclipse)
IE SP2 (I go without tabs)
WMP10 (Not WinAmp)

And before you bitch at me for using IE SP2 and being an M$ fanboy, on my web server I have:

Red Hat Enterprise Linux
Apache 1.3
mySQL 3.0
The GNU Toolkit for compiling my server side apps.

So get over it, "Da Fokka", and all you other insecure OSS fanboys, too.

-- Kawahee

Re:Modularised code will always have this problem. (2, Insightful)

Da Fokka (94074) | more than 9 years ago | (#13026083)

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.

Re:Modularised code will always have this problem. (0, Troll)

Grey Ninja (739021) | more than 9 years ago | (#13026088)

Okay, you are just stupid. Not a MS fanboy. I mean, seriously, you are using some of the shittiest desktop apps, and your server is running absolutely ANCIENT software.

Re:Modularised code will always have this problem. (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#13026196)

> attack troll with sword

Re:Modularised code will always have this problem. (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#13026090)

He didn't say he didn't like Visual C++ jackass... he was giving an explanation of why he though the parent was modded troll.

Re:Modularised code will always have this problem. (4, Informative)

Richard W.M. Jones (591125) | more than 9 years ago | (#13026212)

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:Modularised code will always have this problem. (4, Funny)

CaptainFork (865941) | more than 9 years ago | (#13026041)

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?

If so why not? - and if not, why so?

Why why not but not if not? Why not not?

Re:Modularised code will always have this problem. (2, Informative)

bersl2 (689221) | more than 9 years ago | (#13026081)

There also exist modifications to gcc that perform the same function. A little checking on your part was all that was necessary to not fall into the publicization trap.

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:Modularised code will always have this problem. (1)

mindstormpt (728974) | more than 9 years ago | (#13026188)

Or would you rather all the bugs be found by the bad guys (this one was found by the Gentoo security team)?

I wonder how long it took them to emerge their minds after finding the bug...

Re:Modularised code will always have this problem. (1)

CaymanIslandCarpedie (868408) | more than 9 years ago | (#13026227)

publicization trap

What does this mean? I tried to lookup "publicization" in a few dictionaries, but it doesn't seem to be a word. A little checking on your part was all that was necessary to not fall into the using nonsense words trap ;-) Are you a Bush speech writer? ;-)

Re:Modularised code will always have this problem. (0)

Anonymous Coward | more than 9 years ago | (#13026093)

In Delphi, you can switch on {$R+}range checking{$R-} around part of the code you want to protect. (While not slowing down the rest of it.) It's still possible to do Dangerous Pointer Tricks that won't be protected, but you really have to want to.

Re:Modularised code will always have this problem. (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13026154)

Wow a human generated crapflood gets a +5 Interesting on slashdot. That isn't a first.

Re:Modularised code will always have this problem. (0)

Anonymous Coward | more than 9 years ago | (#13026155)

Java is safe from such buffer overflows as well. And there are no optional switches to worry about!

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.

Re:Modularised code will always have this problem. (2, Insightful)

Stiletto (12066) | more than 9 years ago | (#13026174)


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. (2, Interesting)

doctormetal (62102) | more than 9 years ago | (#13026248)

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.

This is a problem of education. When I was at school you learned to program C and assembler. If you made a stupid programming error you would notice it real soon. Now they mostly teach languages like java which hides most of the defensive programming from the programmer. If you don't know about such things, you should not be programming in languages where you need to these things.

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.

Consider all compiler warnings as errors is what I always do. Every warning can be a potential runtime error.

Thinking before you code can also help a lot.

The answer is Defense in Depth (3, Interesting)

n0-0p (325773) | more than 9 years ago | (#13026204)

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.

Re:Modularised code will always have this problem. (1)

Bodysurf (645983) | more than 9 years ago | (#13026244)

You can't really do that without line by line analysis which is unrealistic

Why not?

OpenBSD does this for everything.

And why not for something as crucial as your example of a TCP/IP stack. It is NOT unreasonable for someone/a group of people to go through that line by line.

Re:Modularised code will always have this problem. (2, Insightful)

Anonymous Coward | more than 9 years ago | (#13026302)

OpenBSD does this for everything

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.

Re:Modularised code will always have this problem. (0)

Anonymous Coward | more than 9 years ago | (#13026245)

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.

So, you want to say that if you will not reuse somebody else's code that was written years ago and went through a lot of bug-squashing since then, but instead will write your own for example BSD TCP/IP stack - it will have fewer bugs and will be more secure? I bet you will have a lot of bug-squashing to go through just to get close to that reused and cleaned up (and as a result - more secure) code.

Re:Modularised code will always have this problem. (4, Interesting)

aws4y (648874) | more than 9 years ago | (#13026286)

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.

The patch, and the E-Week article and quote (4, Informative)

alanw (1822) | more than 9 years ago | (#13025936)

Here's the patch to inftrees.c (found on Debian.org):
$ diff -Naur inftrees.c ../zlib-1.2.2.orig/
--- inftrees.c 2005-07-10 13:38:37.000000000 +0100
+++ ../zlib-1.2.2.orig/inftrees.c 2004-09-15 15:30:06.000000000 +0100
@@ -134,7 +134,7 @@
left -= count[len];
if (left < 0) return -1; /* over-subscribed */
}
- if (left > 0 && (type == CODES || max != 1))
+ if (left > 0 && (type == CODES || (codes - count[0] != 1)))
return -1; /* incomplete set */

/* generate offsets into symbol table for each length for sorting */
And here's the E-Week article [eweek.com] with the quote
However, Ormandy said, "Zlib is very mature and stable, so development is sporadic, but it's certainly not dead. Mark Adler [a Zlib co-author] responded to my report with a patch and an in-depth investigation and explanation within 24 hours, and I believe he expects to release a new version of Zlib very soon."

Re:The patch, and the E-Week article and quote (2, Interesting)

inflex (123318) | more than 9 years ago | (#13026067)

I wonder if it'd be possible to create a binary patch for prebuilt binaries ?

Anyone got some suggestions?

Re:The patch, and the E-Week article and quote (3, Informative)

Haeleth (414428) | more than 9 years ago | (#13026136)

I wonder if it'd be possible to create a binary patch for prebuilt binaries ?

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.

Re:The patch, and the E-Week article and quote (1)

inflex (123318) | more than 9 years ago | (#13026168)

Absolutely agreed on your points - there is one situation where a small binary patch does become useful, where it's a legacy system which simply cannot be swapped out for the 'latest version', non of us like those situations but they do exist :-(

Thanks for the pointers - amazing, /. being useful after all :-)

Re:The patch, and the E-Week article and quote (0)

Anonymous Coward | more than 9 years ago | (#13026202)

Am I the only one that read that subject "Sex, Lies and Compressed tapes?"

fp (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13025938)

HH

Important: Use a safe browser (4, Funny)

aussie_a (778472) | more than 9 years ago | (#13025943)

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.

For those with IE on XP,2003 (1, Redundant)

A beautiful mind (821714) | more than 9 years ago | (#13025960)

please visit this link:
http://www.hunger.hu/win.html [hunger.hu]

Warning: the link causes BSOD because of a flaw in the image rendering algorithm of some windows component when it tries to render a huge image, the waiting times out and the kernel decides its better just to panic.

The link causes no problems on linux, as it's implementation is not faulty.

I think there is a patch for this fault on windowsupdate, but i can't be certain as i'm not using windows.

So long with the zealotry of IE's safeness.

Re:For those with IE on XP,2003 (0)

Anonymous Coward | more than 9 years ago | (#13025994)

It crashed in Mozilla Firefox 1.0.4 as well (blue screen of death). The device driver that failed was that of my graphics card.

Re:For those with IE on XP,2003 (1)

A beautiful mind (821714) | more than 9 years ago | (#13026047)

Yes! Exactly.

That was mainly the point of my GP (sorry if my sarcasm wasn't apparent enough).

It is fairly plausible to assume that there are some platform specific bugs or design flaws, where a specific browser is not at fault, like in the case of this zlib bug or the case of the demonstrated windows image bug, therefor we cannot say that firefox sucks or ie sucks, just that "hey look, there is a bug in zlib which is used by this and that" or "hey look, there is a bug in this windows component/design which causes the whole system to halt when it encounters a bug in a device driver!".

Btw, Opera 8.x is said to be immune from this windows crashing design flaw because it uses it's own image rendering library (afaik).

Re:For those with IE on XP,2003 (0)

Anonymous Coward | more than 9 years ago | (#13026179)

Sorry man, I just thought perhaps you had just said Internet Explorer because it's so tied in to the operating system.

Not just IE (2, Informative)

mikael_j (106439) | more than 9 years ago | (#13026030)

Not just IE on WinXP, Firefox works equally well with this website if you are looking for a BSOD. (I just had to try it).

/Mikael

Re:Not just IE (2, Funny)

TekBoy (142140) | more than 9 years ago | (#13026105)

It is sites like that this that make Firefox's Session Saver extension a bad idea. I just had to click it. :-) Then firefox just had to restore it the next time loaded. :-0

My stupidity squared.

Re:For those with IE on XP,2003 (2, Funny)

smallstepforman (121366) | more than 9 years ago | (#13026049)

Opera 8.01 works fine. But what else would you expect from Scandinavians.

Re:For those with IE on XP,2003 (1)

Soul-Burn666 (574119) | more than 9 years ago | (#13026150)

Indeed. This crashes using Firefox aswell ^_^

Re:Important: Use a safe browser (0)

Anonymous Coward | more than 9 years ago | (#13025961)

excellent. so you seal one hole by using a browser with a large number of other holes.

smart. S.M.R.T.!

Re:Important: Use a safe browser (1)

grahammm (9083) | more than 9 years ago | (#13025988)

I doubt that Firefox will need a patch. The only patch which should be needed is to libz, then all applications which use is will benefit from the fix.

Re:Important: Use a safe browser (0)

Anonymous Coward | more than 9 years ago | (#13026019)

Fedora Core was patched yesterday... before I even know about this issue.

Re:Important: Use a safe browser (1)

dancallaghan (890674) | more than 9 years ago | (#13026060)

Except the Windows version (surely only an insignificant number of users though :-P), which would be statically linked against libz.

Re:Important: Use a safe browser (1)

jonwil (467024) | more than 9 years ago | (#13026224)

The question is, why didnt microsoft (who have used zlib in a few places in windows like IE PNG handling and shell zip support) add zlib or the compression algorithim it implements as a dynamic library and make it a core part of the OS (i.e. with a zlib.h in the platform SDK)

Re:Important: Use a safe browser (0, Redundant)

yeremein (678037) | more than 9 years ago | (#13026021)

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.

Wow, that's some attempt at spin. Too bad it's completely wrong.

The fact that Microsoft doesn't support the PNG alpha channel, antialiasing, shadow masking, etc. is completely immaterial--IE still has to decompress the PNG, which means it is vulnerable to any zlib bugs.

By the way, the "new technology" known as PNG was approved by the W3C on October 1, 1996 [libpng.org] . The fact that Microsoft still doesn't properly support it does not mean it's some bleeding edge thing. Microsoft is just stuck in the stone age.

Re:Important: Use a safe browser (1)

aussie_a (778472) | more than 9 years ago | (#13026056)

It was a parody! I went so overboard so that it would be obvious at a glance that I couldn't be serious. I typed it up in Firefox! I even added a disclaimer at the end of the post. I know PNG isn't new, I slipped it in to hopefully make it obvious I was joking.

Re:Important: Use a safe browser (2, Funny)

ratnerstar (609443) | more than 9 years ago | (#13026069)

Were you born without a sense of humor, or did you have it surgically removed?

Re:Important: Use a safe browser (1)

antic (29198) | more than 9 years ago | (#13026079)


"Wow, that's some attempt at spin. Too bad it's completely wrong."

-1, Completely missed the joke. And also completely missed the disclaimer on the joke noting it as such. Wow.

Re:Mods on crack!? (3, Funny)

atrocious cowpat (850512) | more than 9 years ago | (#13026157)

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.

Slander! I only mod people down when I'm off crack!

Re:Important: Use a safe browser (0, Redundant)

noda132 (531521) | more than 9 years ago | (#13026314)

By using IE, you ensure that you will be safe from any bugs that arise from new technologies, such as PNG.

That's wrong, IE is just as vulnerable with regard to PNGs.

Also, zlib compression isn't only used in PNGs. It is used to transfer a good proportion of web pages, transparently. In fact, this very web page was transmitted to you using zlib, if you're using IE or Firefox or Opera or Safari or Lynx or....

Check out Microsoft's misdeeds (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#13025944)

Re:Check out Microsoft's misdeeds (0)

Anonymous Coward | more than 9 years ago | (#13026007)

Parent is an attempted zlib buffer overflow hack. (The irony!) Don't click it.

Contact us for support (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#13025950)

For those of you with any questions about this or any other breaking security issues, please feel free to contact us at the National Security Research Center at 908.542.3588. We provide up-to-the minute support to individuals and businesses. There is no charge, and no strings attached, as we are government funded.

Will posting dupes cause widespread trouble? (0)

Anonymous Coward | more than 9 years ago | (#13025976)

I just wanted to ask Timothy is posting dupes would cause widespread trouble for the interenet. Seems like a flaw that not even open source can fix.

LP (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13025986)

* last post *

Already patched (4, Informative)

Anonymous Coward | more than 9 years ago | (#13025996)

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.

Re:Already patched (1)

jnelson4765 (845296) | more than 9 years ago | (#13026161)

Fedora Core 4 has an update to zlib - ran yum as soon as I saw this article :)

Re:Already patched (2, Informative)

i_like_spam (874080) | more than 9 years ago | (#13026192)

What took 'em so long?

Gentoo announced the bug July 5th [gentoo.org] and had the patch a day later.

Re:Already patched (0)

Anonymous Coward | more than 9 years ago | (#13026205)

Downside with gentoo is you have to wait three days before the emerge --sync finishes ;-P

Re:Already patched (0)

Anonymous Coward | more than 9 years ago | (#13026270)

Thu Jul 7 13:47:41 2005 >>> sys-libs/zlib-1.2.2-r1
merge time: 40 seconds.

Re:Already patched (1)

stutterbug (715367) | more than 9 years ago | (#13026233)

But what about the dozens of binaries you run on Debian, Ubuntu, Fedora and all the other OSs recently shown as patched on Secunia. If you're reading this in anything other than a text-only browser and you haven't recompiled from source, you are vulnerable, regardless of the application sitting in /bin/. That's precisely the point of the article.

Re:Already patched (2, Informative)

udippel (562132) | more than 9 years ago | (#13026295)

004: SECURITY FIX: July 6, 2005

On OpenBSD

even on Microsoft Windows (2, Funny)

Turn-X Alphonse (789240) | more than 9 years ago | (#13026031)

even on Microsoft Windows

NOT WINDOWS! I was just about to move to it from this Linux thing!

welcome to four days ago: [ GLSA 200507-05 ] (2, Informative)

Anonymous Coward | more than 9 years ago | (#13026038)

Glad I'm running Linux. (3, Informative)

yog (19073) | more than 9 years ago | (#13026044)

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 [mitre.org] , 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!

Re:Glad I'm running Linux. (1)

A beautiful mind (821714) | more than 9 years ago | (#13026118)

Sorry to take a stab at this, but using linux in itself is NOT a guarantee to get rid of luser stupidity and ignorance. The biggest weakness, around 40-50% of all insecurities in a given system is the user, statistically. We can mitigate the other risks, but the user factor is the worst problem.

I am writing this from my debian desktop.

Re:Glad I'm running Linux. (3, Insightful)

moonbender (547943) | more than 9 years ago | (#13026153)

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

Re:Glad I'm running Linux. (0)

Anonymous Coward | more than 9 years ago | (#13026255)

I applied the update RPM over 48 hours ago before seeing this story here. I love Slashdot, but:

Corollary: Don't depend on /. for security announcements.

Golly Gee! (-1, Troll)

tripslash (683760) | more than 9 years ago | (#13026076)

Even software running on Windows? OMG, I thought Windows was Teh Sh1t!

Anyway, I don't see how this is such a big deal. Just apply the patch.

Oh, that's right, it's Windows ... I guess it is a big deal (applying a patch, that is).

Re:Golly Gee! (1)

tripslash (683760) | more than 9 years ago | (#13026176)

Troll? Come on, I know it's early, but lighten up!

How 'bout -1 Lame Attempt at Humor using awkward attempt to make fun of the phrase "even on Microsoft Windows."

Note to self: Don't go for the obvious M$ joke early on Sunday morning. (Damn, did it again.)

Note to self/others: Lighten up!

Ah ... that's better.

despite being OSS... (1, Insightful)

forgoil (104808) | more than 9 years ago | (#13026089)

...there has been no security audit that found this flaw. ...everybody's computers won't be automatically updated just because there is a patch that all total geeks love. ...the source haven't been read by all who uses it, and the flaw wasn't found.

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:despite being OSS... (1, Informative)

Anonymous Coward | more than 9 years ago | (#13026121)

..there has been no security audit that found this flaw.

Been at the crack pipe again? "Provided and/or discovered by: Tavis Ormandy, Gentoo Linux Security Audit Team" here [secunia.com] .

A case for packaging systems (4, Insightful)

eldacan (726222) | more than 9 years ago | (#13026115)

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

If you link with zlib the right way, easy to fix (4, Insightful)

Ed Avis (5917) | more than 9 years ago | (#13026133)

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.

Open Source zlib (1)

canuck57 (662392) | more than 9 years ago | (#13026134)

It affects countless software applications, even on Microsoft Windows.

I thought Microsoft was proprietary and didn't use open source like zlib? Snicker. I guess Microsoft is being assimilated.

Perspective of non-C Programmers (4, Informative)

putko (753330) | more than 9 years ago | (#13026138)

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 [paulgraham.com] .

It's the runtime... (1)

argent (18001) | more than 9 years ago | (#13026228)

The problem with writing code in a typesafe language is, as you have noted, integration with libraries. The main reason that so much code is writen in C is that C needs pretty close to zero runtime support.

Not only do languages like Lisp need a fairly extensive runtime, they need dynamic memory allocation and garbage collection, and when you share garbage-collected objects between languages (potentially between multiple languages each with their own allocation models) you're asking for a whole new kind of hurt.

Find a type-safe language where the generated code is standalone and has an easy mechanism for importing and exporting data, and you'll get some traction. And much as I like lisp-family languages myself, that's not the way to go... nor is anything like Java. Perhaps there's something in the Modula family that will work, though my own experience with Modula 2 has not been encouraging.

Re:Perspective of non-C Programmers (4, Informative)

Florian Weimer (88405) | more than 9 years ago | (#13026230)

Common Lisp (the language) is not completely safe, it permits unsafe constructs which can even lead to classic buffer overflows. Most implementations omit bounds checks which are not mandated by the standard when optimizing, so these problems can occur in practice.

Re:Perspective of non-C Programmers (4, Informative)

Anonymous Coward | more than 9 years ago | (#13026251)

the problem is that C is not a type-safe language

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.

A skilled worker chooses his tools carefully (2, Insightful)

Goosefood (884250) | more than 9 years ago | (#13026148)

Ok guys, its about time we start looking at the tooling used in the field of programming. The widespread use of software is constantly bringing to light the same types of software faults. Hardly a day goes by without someone being negatively affected by a buffer overflow/pointer type of bug in software. Would we accepts this from the engineers who build our bridges and buildings?

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.

fuck zlib (0, Flamebait)

sl4shd0rk (755837) | more than 9 years ago | (#13026165)

We don' neet no steenking zeeleeb. -LZO lib

Smile :) (0)

Anonymous Coward | more than 9 years ago | (#13026223)

MSN Messenger uses PNG for some smilies, I guess it's time to disable them ;) 8-) :)

Only a CVE candidate? (1)

i_like_spam (874080) | more than 9 years ago | (#13026241)

Can someone explain why this zlib buffer overflow is only considered as a candidate for inclusion in the CVE list [mitre.org] ?

Has it not been completely verified, or is there just a lot of red-tape involved in being accepted by the CVE board?

Of course, that'd be... (0)

Anonymous Coward | more than 9 years ago | (#13026259)

as in Oscar.

Wow. (0)

Anonymous Coward | more than 9 years ago | (#13026263)

It's a good thing we have modern features like shared libraries to make fixing this easier. Right? RIGHT?

I'll just sit down now.

very complex code (5, Interesting)

ep385 (119521) | more than 9 years ago | (#13026283)

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 [franz.com] 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.

Is i my imagination... (3, Funny)

MSDos-486 (779223) | more than 9 years ago | (#13026316)

or does it seem the end of the world will be caused by a buffer overflow?

BSD Status (5, Informative)

emidln (806452) | more than 9 years ago | (#13026329)

For the undead crowd out there:

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
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>