Slashdot Mirror

← Back to Stories (view on slashdot.org)

CERT Warns Of Multiple Vulnerabilities In Libpng

Posted by simoniker on from the puh-nug-guh dept.

jefftp writes "CERT announced today that there are several vulnerabilities in libpng, one is a buffer overflow which could potentially cause a PNG image file to execute arbitrary code. Libpng release 1.2.6rc1 addresses the problems covered by this CERT announcement, and can be obtained from the libpng Sourceforge project. A fully tested version is to be released in the next few weeks."

12 of 259 comments (clear)

  1. Firefox by dolmen.fr · · Score: 2, Interesting

    Is Mozilla/Firefox/Thunderbird using this lib ?

  2. Mozilla by KidSock · · Score: 2, Interesting

    So does mozilla statically or dynamically link with libpng?

  3. Old news by Anonymous Coward · · Score: 2, Interesting

    ...thanks to the Debian Security mailing list, my systems were secured against this hours before it even made it to /.

  4. Gentoo by AliasTheRoot · · Score: 2, Interesting

    I just emerge synced and the latest version available is still libpng-1.2.5-r7

  5. Buffer overflow *again*? by Anonymous Coward · · Score: 2, Interesting

    We've all heard about buffer overflow problems in countless programs and libraries again and again. I'm not a programmer, but as I under stand it, the problem is writing to unallocated memory areas. But this is not a new problem, it has happened for ages. Is it really that difficult to avoid? I understand that libpng as a "building block" library needs good performance, but is it really that much of a problem to write things in safer programming languages that don't allow these kind of problems? Can some seasoned programming gurus here enlighten me here?

  6. Debian by Fuzzums · · Score: 3, Interesting

    Within an hour (or so) after the CERT-mail I also got the Matt Zimmerman-mail.

    Fixed :)
    I love this!

    Thanks Guys!

    --
    Privacy is terrorism.
  7. Attribution? by Quixote · · Score: 2, Interesting
    Would it be too much to ask whose code was it that had the vulnerability?

    I think it is time we started attributing vulnerabilities to the authors (just as we do with companies).

  8. Re:Didn't this happen with BMP? by FireFury03 · · Score: 2, Interesting

    most of us should run with a no executable stack theses days

    Ah, you mean the vast majority of people are now running Athlon64's? (tip: Plain IA32 CPUs don't support the NX bit).

    --
    http://blog.nexusuk.org
  9. Re:Ah-ha! by billatq · · Score: 2, Interesting

    Someone who saw the leaked source code a while back happened to mention to me that Internet Explorer uses libpng for rendering PNG files--it's just broken because it uses such a friggin' old version of it. So there's a good chance that IE is affected too.

  10. Another exploit in libpng by ShadowRage · · Score: 4, Interesting

    image bombs. basically, you create a 190000x190000 pixel monochrome image, save it, and it compresses to 43 kb

    anyone opens it... *BAM* it expands into 2gb of ram.

    1. Re:Another exploit in libpng by thogard · · Score: 4, Interesting

      This is a problem? I've got about 300 people try to anon-proxy through one my servers every day. When they ask for a gif (or png or whatever) would be a nice to give them something to make them go away.

  11. Bugs in Compilers... by Tom7 · · Score: 2, Interesting

    On the other hand, it's quite difficult for a bug to creep into a compiler's bounds checking code (which is typically very simple). I know of no such historic examples, though perhaps this is because relatively few apps actually use safe compiled languages. (It would presumably have to be matched by a bug in the application code...) Interpreters and JIT compilers are much more subject to this kind of problem, particularly if they are written in C themselves. ;) There have been a few JVM exploits historically, though it is still much easier to make a secure JVM than to make tens of thousands of secure applications.

    Finally, remember that even C has the burden of bugs in its compiler, runtime, and libraries, so this argument is useless at differentiating between C and safe compiled languages (unless you can argue that the latter have more complicated support code).