Slashdot Mirror
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."
Yes. Most everything on Linux that reads or writes PNG's uses it.
'Standards' in computing only impress those who are impressed by things like 'standards'.
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
New builds of Mozilla / Firefox / Thunderbird have been released to patch four potential security vulnerabilities including the libpng issue
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...
----
According to this, libpng is part of the source tree. My guess is static.
M$ Lawyer: But `gcc
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
"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.
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.
Yeah it's still not fixed, but when an updated package is available it will still most likely simply be versioned 1.2.5-r8. You can keep a watch on the package and see immediately when it's fixed here.
It's like deja vu all over again.
... 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).
Sure it could. Implement image loading and rendering in Java and nobody has patience to load images anymore.
just ignore advocates, they'll go away eventually :)
gentoo is good for me, i don't think it's good for everyone - but i'm not everyone, i'm me.
my wife and my mother both use win2k and thats whats good for them, i help them out with patches and suchlike but neither of them really want to care about having gcc or whatever installed.
like i said, it's all about choice.
Buffer owerflow attacks won't happen in languages which doesn't "support" that feature, such as perl, python, ruby, java, C# (any managed code), or managed C++ for that matter.
:)
Another way of killing the problem is using the NX (I hope I got that correct) instruction/bit in newer CPUs and simply separate code and data, and not allow execution in a data segment. Win SP2 does this, I am sure Linux does/will soon, one of the BSDs have done stuff like this for a while, etc.
So yes, you would prevent it. But then again, calling a javalib from C...
"Submissions review procedure" ?
Taco: "Wooah! this Doom 3 is excellent!!!!"
Michael: "Anyone else gettin 503s?"
Simoniker: "Is anybody doing ANY work?"
Tim: "Simon - yer, just gettin submissions - omg, another 400"
Taco: "Die scum die!!"
Michael: "I give up, anyone wanna 7up?"
Taco [Looking up from game for a minute] "Yer go on then!"
Taco: "Tim, Throw another story onto the site, the natives are gettin restless."
Tim: "eeny, meeny miny mo...."
liqbase
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.
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.
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))