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.
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?
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
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.
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.
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.
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.
I would like you to meet Mr. Sendmail. And while you're at it, say hello to bind for me.
/.'ers had ever heard of Unix.
Just be glad most serious *ix security flaws have been taken care of under less public circumstances before most
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.
Hey, I have a great idea!
Let's keep writing software in an unsafe, glorified assembly language (and glorified assembly languages with OBJECTS!). You know, because it's not like we care about safe applications or anything. We need our button widgets to complete their draw operations in under 5 microseconds.
Seriously, we don't need to check array dereferences. It takes up AN ENTIRE WHOLE INSTRUCTION for each dereference. That's insane, we might have to wait a whole millisecond for a button widget to redraw. And how can we deal with that? I mean, remote code getting executed on my local machine every once in a while, I can understand.. but I want my user interface to be SNAPPY.
And besides, only stupid programmers write programs that can't deal with unsafe memory access. I mean, how stupid do you have to be? It's very easy: only clobber memory that needs to be clobbered. It's not rocket science!
No, we don't need garbage collection, either. Real men keep track of all their pointers, all over their programs, and use ad-hoc reference counting schemes if necessary!
Yep, hooray for C and C++.
-Laxitive
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