Slashdot Mirror
GdkPixbuf Suffers Image Decoding Vulnerabilities
DNAspark99 writes "It seems Multiple vulnerabilities have been reported in GdkPixbuf, which can be exploited by malicious people to DoS (Denial of Service), and potentially compromise a vulnerable system. Personally, I wasn't concerned about this until I ran 'ldd firefox-bin | grep libgdk_pixbuf'" There's no official patch yet, but the article notes several Linux vendors have issued updates. Worth keeping an eye for those who use libgdk_pixbuf under other Unix-style operating systems as well.
More bugs. More fixes. More patches. This is the software cycle...
If you're not aware, gnome2 uses this library, so any gtk2/gnome2 applications you use are probably linked against libgdk_pixbuf.
update your systems...
sigh Time to tell the idealist in me to STFU.
-paul
Pistol caliber is like religion: everyone has their favourite, and theirs is the only right choice.
Well, they tend to be writing in C, and concerned about "performance". They thus leave out vital buffer checks. Given that computers are now 3000 times faster than when I was a lad, there's no excuse, any inefficiency is easily compensated for by the "ridiculous speed" of modern computers.
Either learn to write safe C or switch to a safer language.
There will always be vulnerabilities. Since people can't produce perfect code there will always be a way for someone to make a flaw into a vulnerability. Therefore there will always be patches and updates(relating to security measures). The only way to stop these flaws from becoming an issue, like this one, is to stop crackers. And good luck with that.
Free Ipods it's for real check out Wired then go to: http://www.freeiPods.com/default.aspx?referer=8533
Time to switch. Take back the Web.
Vote against shoddy software with your clicks.
It strikes me that it would be a good use of any spare capacity some search engines might have to search for image headers on web sites, that are attempting to exploit these types of problems.
Uhhh, no. It is simply "in vogue" to look for vulnerabilities in image format parsers at the moment. Is the trend not obvious?
Soon all the major image libraries will have been examined, all the bugs fixed, and the security gurus will move on to other things. And we'll all benefit from that, because the code will be fixed.
Bitching is counterproductive, don't you think?
The only places using gdk-pixbuf in Firefox for loading images are all for loading images from your local machine. No from-the-network code paths use gdk-pixbuf.
Last time I ran "ldd firefox-bin | grep libgdk_pixbuf". I was pretty worried that I had no frigging idea what the hell I was typing.
I find that alot of people I've worked with in software development have a "get it working, clean it up later" attitude. Usually basic error checking gets thrown in, but "hardcore" security often gets put aside in favour of other projects that need to be done. Thus, I think we end up with a fair amount of possibly shoddy code.
I've never done an audit, because I'm trying to write good code, and it's all I can do to be as "productive" as the others.
I don't think anybody seriously thinks "man, that could be a huge problem! well, nobody will notice".
-- Seq
Now your GNU/Hippie software is vulnverable what are you going to do about it?!
...patch it before the vulnerability is even announced... not six months later.
I was just using the Icesoft Java web browser and the Fluendo media player. These are both big applications written in 100% pure Java. They both don't have buffer overflows because Java doesn't have buffers (in the C sense). How many security holes do we need to see every week?
This is why I really hate when people start wars about one platform over another over security. No one is perfect, and errors like this will happen. The only real way to attempt to prevent flaws like this is more strict code reviews and more testing and debugging. Even those actions won't always find a problem like this because sometimes the problem is outside the bounds of the program's normal operation (ie invalid data in an image that wouldn't be found by testing with real images). All we can do is hope that there are more of us wearing white hats then there are those of us wearing black hats.
There's a particular comment which we'll see about a thousand times on this thread alone, the gist of which will be, "See? Even open source has bugs/security holes! It's no better than Microsoft!"
The reason we bash Microsoft for its bugs and security holes is not because they have bugs and holes; the reason is that Microsoft paints itself as the savior of computing, as software that will make your life infallibly better and easier, and along the way has made quite a lot of unethical business decisions. They basically brag about how uber they are, and then they release crappy software and frequently take forever to fix certain bugs (or simply never fix them -- e.g. PNG transparency in IE. What's it at, 3 years and counting? 4?).
The guys who write open source stuff like GdkPixBuf, on the other hand, have not (to my knowledge) done these things. They are thus not deserving of scorn; they write software, release it, and say, "I wrote this because I needed it. If you want to try it out, here you go. Have fun; I don't promise anything."
That's why we mock Microsoft for its bugs and not the GDK team.
(To be fair, I'm certain that there are some OS projects whose developers are as arrogant as Microsoft, but they at least do not have the unethical business history Microsoft does, nor do they (still!) have a monopoly on desktop OSes that they continue to abuse to the detriment of everyone except themselves. It's one thing to be an asshole when you're nobody important; it's quite another when you have a great deal of power.)
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
--
A neighborhood's tale
Firefox doesn't use gdk-pixbuf for drawing it's images. The only places using gdk-pixbuf in Firefox are loading a couple of images from your hard drive into the browser UI -- like the little Windows desktop icon that shows up in the download manager UI. This isn't remotely exploitable in Firefox.
--Asa
Fix it.
Actually, we can, that's one of the main reasons for the existance of open source.
well eventhough the computers are zillion times faster, the datastructures they have to deal with have gotten zillion times bigger and/or more complex.
Solving algorithm-deficiencies by throwing more iron at it is a short-term solution that is bound to come back and bite you in the tail sooner or later.
Learn to write safe C and make sure your algorithms are sound and healthy.
There are a number of very easy things you can do while coding to make it more secure. For example, avoid any non- "n" string function. Just get used to typing and using strncat and snprintf and the like instead of the unchecked ones. Little things like that can actually go a pretty long way.
How hard would it be to write a program that could be used to test apps against buffer overflow errors. This should be given the source of the app, where one could exclude various procedures (i.e. when the calling procecedure already tests for overflow).
Difficult, impossible. Helpful or useless?
I'd imagine that with such tools hackers could also test your code for overflows, but if it became mainstream to hardcore test for such things then perhaps they wouldn't have the opportunity.
Personally I think C is much too slow.
Relying on high level languages like C seems like a good idea because of development time and security but eventually program complexity will outpace hardware speed increases and you will be screwed!
A real programmer doesn't need to waste resources on bloated handholding crap like "C". A real programmer uses assembly to avoid writing bloated code!
Graphic proccessing is one of the places where the speed is needed. Yes computers have gotten 1000 times faster but modern GUIs do 1000 times more graphics computations than they use to. Concider the fact that every single gtk/gnome widget drawn on your screen uses this library (yay themes) and it becomes apparrent that it has to be written for speed, so going to a high level language is not an option. There are many other reasons that GTK uses C, the main one being that while everyone is moving to high level languages, they are all moving to different ones. Therefore, GTK has to be written in C since that is what all the other languages can link against.
Second, it likely wasn't that they intentionally left out checks on purpose for speed, but just missed one - probably weren't think about someone attempting to DOS thier graphics library. It happens when you write code. I am a decent programmer and have never found an integer overflow or memory access error in any C code I wrote (after shipping it), but I am not arrogant enough to think that there are not any in there waiting to be discovered. It isn't insightfull to say that if everyone programmmed perfectly then we wouldn't have any bugs - it is unrealistic.
Lastly, even if you did use a high level language, the programmer that overlooked thisp problem in C would still overlook it in the higher level lanugage as well. It would likely result in an uncaught exception, and the program would likely terminate. So this would still be a bug - just not a security hole, since it couldn't result in executing arbitrary code.
Higher level lanugagues can help make a program more secure, and are a good idea for that reason. But as long as human beings are the ones writting code, mistakes and oversights will happen, and patches are something you will have to learn to live with.
Hmm, guess I'll stick with MS since they've already gone through the monkey-pounding.
Or more likely is they all have a similar structure inside and so after finding one vulnerability it wasn't hard to morph it to the other jpeg libs that are out there.
"You can now flame me, I am full of love,"
You seem to be missing the point. ALL software has bugs and those bugs need to be found the removed. That is the software cycle.
I can't wait for the proverbial monkeys to start pounding away on all the upcoming Linux boxes and the inevitable number of bugs to be discovered.
You know, I can't wait either because then these bugs will be fixed :)
Hmm, guess I'll stick with MS since they've already gone through the monkey-pounding.
Go for it.
ldd searches for dynamic dependancies, hence no need for a new packages. Mozilla's gdk_pixbuf will be updated by the updated gdk_pixbuf containg package.
Thanks YaST!
In a language without pointers, array-bounds checks impose a 1-3% performance hit. This is because advanced optimizers can usually remove most of the array-bounds checks. In practice, safe natively compiled languages (Ocaml, Lisp) can get within 10% - 20% the performance of C. 10% - 20% for the sake of security is a trade-off I'm willing to make. Obviously, the current C recommendation of "learn to write secure code in a language that encourages you not to" isn't working, because buffer-overflow vulnerabilities are rampant. It's time to throw that idea out the window.
A deep unwavering belief is a sure sign you're missing something...
if you didn't realize by reading the news in the last week, it doesn't matter how long your software is attacked, new bugs are found. Yes, guess what, even microsoft has vulnerabilities announced every month. Millions of eyes on the code can help and obviously it did. We didn't hear about the new virus out there in order to find out about this exploit, we just found out about this exploit. Millions of eyes don't prevent mistakes, they do help find them faster and patch them quicker. And of course, even this story is exactly what that is, they already have vendors with patches out for this problem.
hm..... seems Micrsoft, even with all its monkey-pounding, still doesn't have a shot in hell with fixing problems as fast as the open source community does. I'll stick with the box that doesn't stay vulnerable for as long.
And they're not trying very hard. A new patentable algorithm is worth money. A performance improvement is also worth money and makes your software better. Most security measures, such as checking return values and carefully allocating memory or evaluating possible sizes of inputs, cost CPU time, slow your systems, and cost time to do. And they're often best understood by the most expensive programmers on a team, not the new guys and interns handed these new development problems, so they get tacked on only as an afterthought.
As long as it's not a RAW screendump or uncompressed TIFF file or something, there's going to be some interpretation of the file's content to produce the human-consumable output. And it'll be based on a parameterized command stream. And if the interpretation of those parameters is not handled rigourously, or if the system does not account for every possible combination of commands, well then you're ripe for an exploit.
That's basically EVERY file format.
Even text can be dangerous. Ever heard of a terminal or ANSI bomb? (scroll down in link).
The only "safe" viewer is a hex editor. Or less (maybe, you get the idea).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
A more general prevention method is to use an environment that doesn't allow buffer overflows; as Java proponents never tire of pointing out, Java guards against this type of attack. There are C libraries which do similar things, IIRC; StackGuard was one such method, though it seems to haved faded into obscurity.
As to your suggestion of a static source code check for unsafe programming practices, there are programs that do that too. GCC itself includes a number of warnings that pop up if you use inherently unsafe C library functions, like gets() (which is buffer overflow in a can...).
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Isn't it a bit odd that these libraries are failing on both Windows and Linux?
I wonder of someone has been stealing source code?
If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy. - James Madison
Most of the exploits (ie actual "exploits") depend on the EIP or some other register being clobbered or the stack being smashed to execute a data block. Metasploit has a nice database of such clobberable locations for Windows
So if you compile your own stuff with your own "-O3 -fomit-frame-pointer -fstack-protector", you may be breaking the binary compatibility of exploit :).
Most ordinary exploits will fail for such custom compiled stuff , unless the guy at the other end takes a memory dump (hard to do undetected over the network) and reads the .stab entries first to figure out your box's weak spot (to use "-g" or not ... hmm..). If you're dealing with guys like that , then you'd better invest a bit better in security than I do . I call it "Security through Diversity" .
Too bad windows users don't have that option.
Quidquid latine dictum sit, altum videtur
Isn't it a bit odd that these libraries are failing on both Windows and Linux?
I wonder of someone has been stealing source code?
While it is possible Microsoft may have violated the licenses of open source and free software projects, it is doubtful. It is virtually certain that the opposite is not the case, unless Microsoft lackeys are deliberately trying to poison the well, in which case a court would find the Microsoft willfully released the code into the wild, effectively licensing it. That isn't very likely either.
What we do know is that C and C++ have vulnerabilities in how the language is used with respect to buffers, that can get even experienced programmers into trouble. We also know that algorithms for reading and drawing images are widely known, widely published, and quite standard, so any two (or more implimentations) are likely to run afoul of similiar mistakes in programming and weaknesses in the language (C/C++) used.
Why moderators find it "insightful" or "interesting" to make the extremely unlikely insinuation that someone is probably be violating copyright in order for similar issues to arise out of code doing similar tasks using similar programming languages and similar libraries, accessing similar open standard graphical formats, bespeaks an agenda and ax to grind (either against Microsoft or Free Software), not an understanding of the underlying coding issues.
I loathe and despise Microsoft as much as anyone, and for good reason, but lets try to limit our lambasting of that destructive and dangerous entity to issues which have a grounding in fact, and not unlikely scenerios like this. There are a plethora of real, documented activities by that company that can provide more than enough fodder for criticism, without insinuating the very unlikely in defiance of occams razer and all real sense.
And if the jab was meant for Free Software, then replace the word "unlikely" above with "absurd beyond any rational measure."
The Future of Human Evolution: Autonomy