CERT Warns Of Multiple Vulnerabilities In Libpng
jefftp writes "CERT announced today that there are several vulnerabilities in libpng, one is a buffer overflow which could potentially cause a PNG image file to execute arbitrary code. Libpng release 1.2.6rc1 addresses the problems covered by this CERT announcement, and can be obtained from the libpng Sourceforge project. A fully tested version is to be released in the next few weeks."
Is Mozilla/Firefox/Thunderbird using this lib ?
So does mozilla statically or dynamically link with libpng?
Here is a .PNG file with a diagram that explains the problem.
Karma: -2147483648 (Mostly affected by integer overflow)
...thanks to the Debian Security mailing list, my systems were secured against this hours before it even made it to /.
You all complained about Internet Explorer not being able to display PNGs correctly, but who's laughing now! Obviously they broke PNG support intentionally for security reasons. Once again, Microsoft comes through on the cutting edge.
it's a good thing all of the porn sites i visit use jpegs
Fedora Core 1 and 2 already have backported security updates for this as 1.2.5-7 and 1.2.5-8 respectively since yesterday. Much better than having to install a release candidate.
It's like deja vu all over again.
a buffer overflow which could potentially cause a PNG image file to execute arbitrary code
This is not a bug it's a feature; the libpng team are obviously trying to get a piece of the ActiveX control market...
----
Well, _lib_png have many, many jmp like instructions, they're called
function calls, and if you manage to overwrite the return address on the stack, you can make it jump anywhere, like the code you injected.
Hopefully it's just the stack you can overflow, most of us should run with a no executable stack theses days, no harm done(well, it probably crashes.. )
Seriously, we need a "Dumbass" mod option
I just emerge synced and the latest version available is still libpng-1.2.5-r7
"And how many PHP sites/scripts dynamically generates .png files ? Quite a lot I'd think, so, webservers might be vunerable, but it seems
like a longshot to try to inject something to such scripts."
Did you read the article? You don't seem to understand the point here.
The bug affects only loading of PNG images. One can make a specially crafted PNG image which has some invalid fields causing problems in the decoder. The invalid handling of these special error cases may cause an application crash or potential execution of arbitary code in the application which uses libpng.
It is not possible to introduce malicious RAW image data to the encoder. And even if it was possible, you should be able to pump data directly in the encoder, which is not a usual case with dynamically generated images. So, your PHP site is safe.
However, libpng is the most commonly used PNG implementation due to it's free licence. These bugs affect to very many applications (graphics applications, Office applications, user interface managers, browsers, etc.) which happen to use PNG.
A similiar case like this was zlib bugs some time ago.
We've all heard about buffer overflow problems in countless programs and libraries again and again. I'm not a programmer, but as I under stand it, the problem is writing to unallocated memory areas. But this is not a new problem, it has happened for ages. Is it really that difficult to avoid? I understand that libpng as a "building block" library needs good performance, but is it really that much of a problem to write things in safer programming languages that don't allow these kind of problems? Can some seasoned programming gurus here enlighten me here?
The article is about PNG, not PHP.
Of course, but this means that free PHP hosting services are at risk, as some malicious users will try to exploit this flaw on the server side.
Is there oil at Papua - New Guinea?
... with this, and Linux gets to join the "visit a malicious website and get rooted" crowd.
Tarsnap: Online backups for the truly paranoid
Its reassuring that for once MS has already taken care of some security issue (for XP SP2 at least).
What is arbitrary code? How is it any different as compared to any other computer code, say a piece of software?
Sorry I am kinda new to png stuff... can anyone explain how this might effect my Windows XP box? Should I go get the patch for my system? btw I am running Windows XP professional with service pack 1. Thanks in advance.
! - in case this is for real.
PNG is an image format. It's very popular. There's a free (not copyleft free) library that anyone can put in their software to handle the PNG format.
There's a problem with this free library. If you're using software with a broken version of this library, you'll need to update the software.
The XPSP2RC has either fixed or sidestepped the issue. If you want that, you can get it from Windows Update (v5). But it's still a release candidate so you might prefer to wait.
Within an hour (or so) after the CERT-mail I also got the Matt Zimmerman-mail.
:)
Fixed
I love this!
Thanks Guys!
Privacy is terrorism.
I just patched my SuSE box. Man that was fast ... or perhaps .. it is because Germany is 6 hours ahead of me.
I think it is time we started attributing vulnerabilities to the authors (just as we do with companies).
most of us should run with a no executable stack theses days
Ah, you mean the vast majority of people are now running Athlon64's? (tip: Plain IA32 CPUs don't support the NX bit).
http://blog.nexusuk.org
This explains how it's done:/ ANNOUNC E-exec-shield
http://people.redhat.com/mingo/exec-shield
image bombs. basically, you create a 190000x190000 pixel monochrome image, save it, and it compresses to 43 kb
anyone opens it... *BAM* it expands into 2gb of ram.
Microsoft internet explorer has encountered a problem ands needs to close. we are sorry for the inconvience.
...
bla bba
[x] restart mirosoft internet explorer
[b]WOW[/b], it is a portable bug!
can anybody tell us if this is exploitable?
On the other hand, it's quite difficult for a bug to creep into a compiler's bounds checking code (which is typically very simple). I know of no such historic examples, though perhaps this is because relatively few apps actually use safe compiled languages. (It would presumably have to be matched by a bug in the application code...) Interpreters and JIT compilers are much more subject to this kind of problem, particularly if they are written in C themselves. ;) There have been a few JVM exploits historically, though it is still much easier to make a secure JVM than to make tens of thousands of secure applications.
Finally, remember that even C has the burden of bugs in its compiler, runtime, and libraries, so this argument is useless at differentiating between C and safe compiled languages (unless you can argue that the latter have more complicated support code).
Umm... the point-and-drool update utility in my SuSE box automatically installed the patch last night. No programming or advanced sysadmining was required on my part.
You can protect against this to. The technique is put a ``canary'' on the stack frame and make sure it is still there before you return.
There are at least two patches to gcc that do this. One is called ProPolice. The name of the second is escaping me right now. OpenBSD includes ProPolice by default.
Google on stack-smashing protectors for more info.
(S(SKK)(SKK))(S(SKK)(SKK))
(This troll would be more effective if not posted anonymously.)
Indeed this flamewar has been repeated many times. Safe languages do indeed provide protection from these kinds of attacks and typically at a fairly small speed penalty (depending on the language; the number-two language on that list is safe and places above C++!).
See the earlier slashdot discussion for loads of argument. ( here for my perspective--note, I am a tower-in-the-sky PhD student in programming languages, but I do write lots of code in many languages, including C and C++.) I am still boggled that programmers who claim to be interested in security (and who moreover claim to be uninfluenced by marketing and "cool", but rather by technical concerns) still choose C or C++ for their projects.
It appears to me that this problem exists at both the client and the server.
.png file (which would only be an issue if you read the .png from the server before delivery.)
.png files that have been tampered with. You don't really want to serve those up to clients -- you'd be delivering a security risk. There will be a significant lag before client software is updated -- browsers and anything else that streams .png over a network connection will be at risk during this time.
.png files. At the server side, you could scan for compromised files and get rid of them.
Updating a server to use the patched version of libpng is an obvious first step. You don't want the buffer overflow compromising security as you deliver a
The tricky part is what to do with the
It seems to me that there's a need for some kind of scanning tool that checks for bogus
Does such a tool exist?
-ch
If this was a Microsoft thing, Slashdot would be all over it. Arbitrary code execution from an IMAGE READING LIBRARY?!
:)
Just the obligatory "perspective" post.