GdkPixbuf Suffers Image Decoding Vulnerabilities 291
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.
Nothing to see here... (Score:3, Insightful)
gnome uses this (Score:5, Insightful)
update your systems...
Somebody is busy ... (Score:5, Insightful)
sigh Time to tell the idealist in me to STFU.
-paul
Re:What the hell (Score:4, Insightful)
Either learn to write safe C or switch to a safer language.
Re:Somebody is busy ... (Score:5, Insightful)
What we really need is a web page summarizing all the recent bugs in media decoding (mpg123 I think just had one) as a "how not to program" guide and then make it mandatory reading to get a sourceforge account. I think it's great folks are out looking for these bugs, but it's an embarrasement that there are this many being found so quickly. To me that indicates that there are a crapload of them out there.
It makes me want to go on vacation for six months and do one upgrade when I get back. Instead of doing one a day for the next six months.
Re:What the hell (Score:5, Insightful)
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?
Re:Somebody is busy ... (Score:4, Insightful)
Re:Somebody is busy ... (Score:4, Insightful)
Why should they?!? If I ask a question, why should I also have to provide an answer? That is a stupid attitude to have. If everyone who asked questions had the answers, there'd be no questions to ask.
Likewise, why look a gift horse in the mouth when he points out a vulnerability like that? Exploiting is a different art from coding to many people. Maybe it just so happens that some people are better at seeing things that others don't catch?
And don't blame the tools, either. I hear too often people saying things like "if only it were in Java instead of C++, this would not be a problem." A poor workman always blames his tools. A poor musician can ALWAYS say "if only I had a better instrument, I could be a better musician." One simple word for that: Balderdash.
Re:What the hell (Score:5, Insightful)
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".
Yawn (Score:3, Insightful)
I was just using the Icesoft Java web browser [icesoft.com] and the Fluendo media player [fluendo.com]. 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?
Security is always a problem.. (Score:2, Insightful)
Re:Nothing to see here... (Score:3, Insightful)
Re:What the hell (Score:5, Insightful)
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.
Re:What the hell (Score:3, Insightful)
Overflow testing (Score:3, Insightful)
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.
Re:What the hell (Score:3, Insightful)
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.
Re:I thought Linux was immune to this... (Score:2, Insightful)
Hmm, guess I'll stick with MS since they've already gone through the monkey-pounding.
Re:I thought Linux was immune to this... (Score:2, Insightful)
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.
Re:Somebody is busy ... (Score:3, Insightful)
I wouldn't be surprised if people are just testing the proof-of-concept demonstration files intended to break other image decoding code and finding that it breaks their code too, maybe in a slightly different way. It's not uncommon for separate programmers to make the same thinkos even if they've never seen each other's code (and especially if the original data spec is unclear, undefined or ambiguous on a given point).
The scary thing is that the sorts of problem we're seeing here apply to any "active" data format - i.e. one where the file isn't simply read and taken as-is (e.g. a plain text file), but is actually made up of "commands" which are interpreted as the file is used. We've seen similar problems with PostScript, PDF, MP3, wmv and probably more besides. The thing about this one is that short of HTML, JPEGs are probably the single most-commonly accessed type of active file - and from sources which may not be trustworthy too!
--
Re:Yawn (Score:3, Insightful)
There are safe languages with a lot less startup overhead than Java. Even quite slow languages like
Re:Tit for tat (Score:1, Insightful)
Just be glad most serious *ix security flaws have been taken care of under less public circumstances before most
Re:Yawn (Score:1, Insightful)
Java's security record isn't that bright. Yes, in the hands of a poor or overworked programmer, it will produce less buffer overflows... but the VMs themselves have been vulnerable from time to time, etc.
However, the -most serious- security issues are arguably the higher level ones, ie, with insecure protocols; they can be impossible to fix while retaining backwards compatibility.
While Java fans like to hype the language as "the solution to everything", it's not. It's not 100% secure; merely 'better by default' than C and its ilk.
Other alternatives such as ocaml or lisp or python have similar benefits; the former two can have speed pretty much on par with C, while the latter, interpreted at -run time-, has historically been similar to Java speedwise [according to Sun's own memos.]
"Use Java!" is an easy mantra to repeat. In terms of pure security, it would be a benefit -over C-. However, multiple other languages exist that allow for both buffer overflow protection and speed; what Java has going for it is marketing, name recognition, more programmers who already "know" it to various degrees, and not much else.
Yes, 'well-written' Java code can be fast. Well-written C can be secure. Problem is, there is a lot of code in both categories that just isn't either...
Re:What the hell (Score:3, Insightful)
Hooray for C and C++ (Score:1, Insightful)
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
Security through diversity ... (Score:3, Insightful)
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 [metasploit.com] 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.
Re:Hooray for C and C++ (Score:1, Insightful)
Not at all similar (Score:3, Insightful)
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."