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.

7 of 291 comments (clear)

  1. Re:Somebody is busy ... by Anonymous Coward · · Score: 5, Informative

    The one who found this vuln is Chris Evans, as known
    as the vsftpd author (http://vsftpd.beasts.org/), and
    here (http://scary.beasts.org/security/) are other bugs he found.

  2. Not exploitable in Firefox by sppavlov · · Score: 5, Informative

    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.

    1. Re:Not exploitable in Firefox by sppavlov · · Score: 5, Informative

      Mozilla does not use gdk-pixbuf for drawing images -- stuart "pavlov" parmenter (mozilla image library owner)

    2. Re:Not exploitable in Firefox by sppavlov · · Score: 5, Informative

      We only use a single code path for rendering images. We only use gdk-pixbuf to decode GNOME images to find icons for mimetypes.

  3. To head it off at the pass... by Dirtside · · Score: 5, Informative

    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
  4. Not Remotely Exploitable in Firefox by asa · · Score: 5, Informative

    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

  5. Re:Overflow testing by jhoger · · Score: 5, Informative

    There is no algorithm to do what you are describing (google for "halting problem")

    You could run something like lint to catch common C errors.

    Better than that though is to profile your code actually running, to see buffer overflows and leaks that actually occur (google for valgrind).

    But most of these exploits are specially crafted input that produce buffer overflows. Typical input won't. So it is very hard to test for buffer overflows.

    The only 100% way to work these kinds of problems out is to write code in higher level languages, so at least you'll get an exception and fail closed in the case of a buffer overflow.

    But in C, the only way to resolve these problems is

    1) Don't write code with buffer overflows (hard)
    2) Find and fix buffer overflows in code review (harder)
    3) Write good enough negative test cases that you find the buffer overflows (really hard for even a good tester).