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.
And here I was all like "my God, that's pathetic, Microsoft can't even make a JPEG parser without buffer overflows that compromise the user".
Now it seems this is universal, or at the very least universal outside the macintosh world. Are the people who write graphics libraries just not trying very hard or something?
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.
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.
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
We're not going to see the open source to a universal buffer object, with complete bounds checking, that every single buffer-requiring codepath calls, any time soon. So how about a "security watch" object that checks a specifiable URL for security announcements, which sends a message to a DB that notifies the sysadmin of security announcements, from warnings to patches? The DB could be set with alternate URLs, the watch object could require corroboration from multiple sources, the site policy could default to autoinstaling patches with certain signatures. Everyone talking about "white worms" that spread patches would want this infrastructure, which could be remotely administered under support contracts. Like a 21st Century fire alarm, calling a robot fire department.
--
make install -not war
--
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.
Sounds like time to strace Firefox and search for calls to gdk-pixbuf functions. I am on a shitty winders machine right now or I would do it myself.
I personally would rather have something a hair slower but a lot more secure. Also, if more desktop apps got ported to Java and Java got more real-world desktop use, the JVM would get tuned and adapted. There's no reason why it should be slow.
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.
On the desktop I don't want to put up with the load times of a VM and the fact that many applications are written to a particular VM, whether that be a particular point rev of Sun's JVM or Microsoft's. So much for write once, run anywhere. So how many JVMs do I have to put up with on my machine to realize this nirvana of no buffer overflows, exactly?
In regards to being an amateur, I was in this business when you were in diapers, if your email address is any indication. Put simply, if I know the end user application is in Java and requires a VM I avoid it like the plague.
I will well and truly laugh when an enterprising individual manages to successfully run arbitrary code inside a JVM again. Yes, it's happened before, and will happen again. Maybe it'll shut some of you amateurs who think that "because it's Java, it's secure" up.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
Hmm, guess I'll stick with MS since they've already gone through the monkey-pounding.
I've never seen so much jibba-jabba in my life! What the hell is this story about? What's a bifpukfix and where can I get it? What needs updating? Jesus H. Christ in a handbasket! Can you say obfuscation?
There's no official patch yet, but the article notes several Linux vendors have issued updates.
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.
I think you must be right. The windows vulnerability has been bricked up.
Thanks YaST!
I did a yum update the other day for my Fedora Core 1 laptop - and it downloaded a new gdk_pixbuf package that broke VMWare so that I couldn't get it to run.
I'd guess this pixbuf is used to draw the widgets in XWindows. Here's a thread on this.
I had to go through some contortions to get yum to retrograde my FC laptop and get VMWare (a show-stopper if not working) going.
Since now there's a *new* vulnerability, I'm waiting until the dust settles and this is reasonably resolved before I try this again.
First time I ever broke something with yum...
I have no problem with your religion until you decide it's reason to deprive others of the truth.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
I had no way of knowing Asa is a Mozilla developer, secondly there are a lot of developers working on Mozilla and he wouldn't necessarily know if someone else put in a call to a verboten function. I am a developer and I can tell you on big projects often people use functions they shouldn't simply because it's impossible to keep everyone informed of everything they should or shouldn't do. Finally, it's really really easy to grep an strace for any of the functions declared in a library, so there's no reason not to do the test.
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
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.
Unless someone installs a VM that monkeys with their browser configs, et cetera, to sit alongside the at least one other VM that is installed on any given machine. Great option.
I'll buy that software!
If your people are writing a lot of code with buffer overflows they are going to write crappy code in any language. End of story. If you and your coworkers can't be bothered to write solid code THAT IS NOT MY PROBLEM. I am NOT going back to the functional equivalent of a BASIC runtime module to coddle you. I wouldn't buy Visual Basic programs either, for that matter.
Somehow I managed to write code that didn't have such vulnerabilities back in CP/M days and I still manage it.
If you insist on using Java then compile it so I don't have to deal with crappy VMs. Then you might sell stuff.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
Wouldn't favicon.ico be displayed as a gui elment? I know that icons rendered in geko are run through some sanity checks that made them safe from the recent jpeg/bmp vulnerability. It seems possable that something could get through since mozilla would use gdkpixbuf when rendering them.
Yes. Software has bugs and it gets fixed.
However, in the last week there have been three separate vulnerabilities related to parsing of images (IE, Moz, and now this).
Not to be the one who looks for spooky coincidences, but might this belie a class of bugs in graphics software? Or is this kind of attack just becoming inevitable as (cr|h)ackers get more sophisticated?
To me it just seems odd that this cluster of bugs in a particular niche of computing is showing as so vulnerable -- after all, every web browser is expected to trust graphics and just process them.
Lost at C:>. Found at C.
This is the cool thing about Linux. I just ran an update and installed a fix for this problem and now I'm reading about it on /. When has that ever happened for Windows?
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
The real issue is these library programmers are serving two masters:
:-)
1) Desktop use
2) Embedded use.
Generally they code for the latter, even if they know that the majority of use is going to be for the former.
I've seen claims in libraries like libpng and zlib about how little memory required for decoding and such and such.
Well guess what? It's all that grasping for allocating the smallest buffers possible that gets you into trouble. Because it's really easy to fuck up there. If you just play it safe and allocate as big a buffer as some atom of your file format is theoretically going to need to do what it does, then you wouldn't have to worry about stuff like that.
And, it's like, so what! EVERY desktop operating system out there has a paged virtual memory system, and I guarantee if you don't use that extra unallocated memory in most cases, it won't "actually" get allocated. So the operating system (and thus the user) could care less, since it's demand-based anyway. But in the odd case that someone tries to fuck with you and actually use that memory, well you'll notice when your hard drive starts paging that somethings' up.
And not to disparage embedded developers: it could be as simple as adding a conditional compiler flag that uses the "safe" mode or the memory/pointer/fiddling version.
libpng was already doing that with respect to feature support. Why not play fast and loose with memory in the full profile version?
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
(Of course, so does every other program that uses GTK for the interface/widgets...)
:-)
So unless someone has convinced you to download and use a GTK theme that has PNG files in it that exploit the vulnerability, you're okay.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
methinks someone has a new toy that lets them try out image based attacks. I expect this new toy will get a lot of excersize for a few months... no?
[signature]
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?)
I just woke up, red this, and checked the SuSe update.
And guess what, the patch was allready there.
Gotta love the OSS usually-same-day-patch-cycle.
Thumbs up, SuSe!
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
Thanks for the update. Now on my Fedora setup, all the image thumbnails in Nautilus look like they were side-swiped by a bulldozer.
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
Java is a bad example of a safe language, because, while it is safe, it also has a lot of other baggage that you really don't need, and because Java keeps you from doing unsafe things even when you ask nicely.
A safe systems programming language does not need to be noticeably different from C in terms of performance or programming style. Furthermore, a safe systems programming language shouldn't prevent you from doing unsafe things, it should just force you to make it explicit when you are doing unsafe things.
There are currently no safe systems programming languages that would appeal to a hardcore C user (D, Cyclone, and similar efforts are trying to do too much). But in the past, there have been some pretty straightforward Pascal and Modula dialects that combined being fairly simple with being efficient and suitable for systems programming. So, it is possible, someone just needs to do it in the C family of languages.
It is possible using certain languages to formally verify and basically prove that for a certain program a particular set of properties does or does not hold true. I am fairly certain it is not possible to do this with a non trivial program in C (unless you try and annotate it and/or restrict which operations you are allowed to do) though, so this point is a bit moot.
There is a big difference between a DoS (which programs in "safe" languages may be open to) and an actual exploit -- which is basically a privilege escalation from "I can ping you" (or even less, actually, with these "passive" exploits that are becoming more and more popular) to "I can install a keylogger". Big. Difference.
HAND.
...the truth is that secure coding is a lot more complex than that.
There are common functions which can be insecure if used in particular ways. There are different kinds of buffer overflow attack - e.g stack and heap attacks. Sometimes the API you are correctly using is itself the problem in that context. Sometimes the particular kind of data you're dealing with requires different forms of validation.
So in the real world it's very useful to be able to examine insecure code and the resolution to the problem.
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
Actually there have been 3 in the last week or so, which is pretty unusual for Apple. Of the many fixes included, however, I only see two that are remotely exploitable on a default install. One is a theoretical, this might be exploitable and the other is the new and very serious, links in ichat may remotely start programs, if the user clicks on them and the exploiter knows the path. I could see this used very maliciously with rm.
Even so, I think practical security on OSX, while it could be better, is still on par with, or superior to most linux distros.
Don't use C, C++, or other languages that permit buffer overflows, because chances are if you do, your code actually will have buffer overflows. Even if you audit it.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
The issue is that C is very difficult to properly code, because it does not give compile errors for buffer overflows. Indeed, it is almost never coded without buffer overruns, even in security-critical software (like OpenSSH).
I really have no idea why people wouldn't use Ocaml, or Ada, or Haskell, or Java, or whatever the hell they want that isn't C. Parent poster is right: this isn't 1978 anymore.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Historical bootstrapping may vary, but most high-level languages these days are written in themselves, and compiled using a previous iteration of the compiler. Lisp compilers written in Lisp; ML compilers written in ML; etc.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
It's more like "don't code in C, because every time you bastards do, it ends up with a buffer overflow." OpenSSH, libpng, gdkpixbuf, the list goes on for quite some time.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Agreed.
These guys are just performing a vital Quality Assurance function that any normal company has. When is the last time you received an email from your local QA Dept that also included a fix? Only messages I have ever seen are like... "This part fails every test we throw at it. It is crap." Then marketing reduces the specs and sells it anyway. Thank heavens that in Open Source there is no marketing (yet). Sales and Marketing are just spammers with real jobs.
Whew! That makes me feel a lot better.