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.

12 of 291 comments (clear)

  1. Nothing to see here... by gnuman99 · · Score: 3, Insightful

    More bugs. More fixes. More patches. This is the software cycle...

  2. gnome uses this by kinko · · Score: 4, Insightful

    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...

  3. Somebody is busy ... by crimethinker · · Score: 5, Insightful
    I think this is the fourth vulnerability related to image decoding I've seen in the past month or so. Methinks somebody is doing a thorough code review of open source image libraries, the stolen NT code (remember the Windows BMP vuln?), and, where source can't be obtained, thinking about where it might be vulnerable. I just wish people with that much determination would concentrate on fixing the bugs, instead of exploiting them ... so much wasted talent.

    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.
    1. Re:Somebody is busy ... by BeBoxer · · Score: 4, Insightful

      I just wish people with that much determination would concentrate on fixing the bugs, instead of exploiting them ... so much wasted talent.

      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.

    2. Re:Somebody is busy ... by PitaBred · · Score: 3, Insightful

      The thing is, you now know about the vulnerability. I'd rather know about it and fix it than not know about it and let someone exploit it. It's a GOOD thing that people are finding these and reporting them. They'll found either way...

    3. Re:Somebody is busy ... by ZuperDee · · Score: 3, Insightful

      I just wish people with that much determination would concentrate on fixing the bugs, instead of exploiting them ... so much wasted talent.

      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.

  4. Re:What the hell by Anonymous Coward · · Score: 4, Insightful

    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.

  5. Re:What the hell by pclminion · · Score: 4, Insightful
    Are the people who write graphics libraries just not trying very hard or something?

    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?

  6. Re:What the hell by Seq · · 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".

    --
    -- Seq
  7. Yawn by ChiralSoftware · · Score: 3, Insightful
    Maybe Slashdot should have a separate section for this? As I've said again and again, we will keep having these types of vulnerabilities until we start using languages with safe pointers and safe memory operations. NX bits, library loading location randomization help too.

    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?

  8. Re:What the hell by cyb97 · · Score: 4, Insightful

    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.

  9. Re:What the hell by fitten · · Score: 3, Insightful

    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.