Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Security Technology

CERT Warns Of Multiple Vulnerabilities In Libpng 259

Posted by simoniker 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."
This discussion has been archived. No new comments can be posted.

CERT Warns Of Multiple Vulnerabilities In Libpng More

CERT Warns Of Multiple Vulnerabilities In Libpng

Comments Filter:

  • Firefox (Score:2, Interesting)

    by dolmen.fr ( 583400 )
    Is Mozilla/Firefox/Thunderbird using this lib ?

  • Mozilla (Score:3, Interesting)

    by KidSock ( 150684 ) on Thursday August 05, 2004 @03:39AM (#9886910)
    So does mozilla statically or dynamically link with libpng?

    • Re:Mozilla (Score:4, Informative)

      by slashdevslashtty ( 712925 ) <slashdevslashtty@yahoo.com> on Thursday August 05, 2004 @03:50AM (#9886961)
      According to this [mozilla.org], libpng is part of the source tree. My guess is static.
      • Interesting. I wonder if this type of exploit could be prevented if the library was written in, say, java instead? Any experts that know for sure?

        • Re:Mozilla (Score:5, Funny)

          by Theril ( 606664 ) on Thursday August 05, 2004 @04:50AM (#9887130)
          Sure it could. Implement image loading and rendering in Java and nobody has patience to load images anymore.

        • Re:Mozilla (Score:2, Informative)

          by evil_one666 ( 664331 )
          I wrote a GIF library in JAVA to display animated gifs on java 1.0 and it was reeeeeeeaaaaaally sloooooooow. It would however not be possible to exploit a buffer overflow on such a decompressor...

        • Re:Mozilla (Score:5, Informative)

          by forgoil ( 104808 ) on Thursday August 05, 2004 @05:39AM (#9887236) Homepage
          Buffer owerflow attacks won't happen in languages which doesn't "support" that feature, such as perl, python, ruby, java, C# (any managed code), or managed C++ for that matter.

          Another way of killing the problem is using the NX (I hope I got that correct) instruction/bit in newer CPUs and simply separate code and data, and not allow execution in a data segment. Win SP2 does this, I am sure Linux does/will soon, one of the BSDs have done stuff like this for a while, etc.

          So yes, you would prevent it. But then again, calling a javalib from C... :)

          • Re:Mozilla (Score:3, Informative)

            by FireFury03 ( 653718 )
            Another way of killing the problem is using the NX (I hope I got that correct) instruction/bit in newer CPUs and simply separate code and data, and not allow execution in a data segment. Win SP2 does this, I am sure Linux does/will soon

            Yep, Fedora Core 2 has done this since one of the early kernel revisions (I think it was when they went from 2.6.5 to 2.6.6)

          • Re:Mozilla (Score:2, Informative)

            by Anonymous Coward
            " Buffer owerflow attacks won't happen ... using the NX"

            No, you can still overflow the buffer, thus being able to modify the return pointer, and some variables. What does this mean? If you were lucky/elite, you could get it to jump to a different function. Sure it's not executing your own instructions from the stack, but it's still control.

            thanks,
            jacob

            • Canary (Score:4, Informative)

              by bsd4me ( 759597 ) on Thursday August 05, 2004 @08:56AM (#9888291)

              You can protect against this to. The technique is put a ``canary'' on the stack frame and make sure it is still there before you return.

              There are at least two patches to gcc that do this. One is called ProPolice. The name of the second is escaping me right now. OpenBSD includes ProPolice by default.

              Google on stack-smashing protectors for more info.

              • Or just write good code that includes bounds checking .

                Jeepers.

                Never use strcpy, always use strncpy. Make sure the code can determine the size of the destination and never copy more than it can hold. Employ smart buffers that won't let you over run what they can hold. This type of exploit has been to widely known of to simply ignore it. besides it's good programming practice that should have been followed to begin with.
                • Or just write good code that includes bounds checking .

                  Or just never crash your car. That way, you don't need a seatbelt or airbags.

                  In fact, if these stupid humans would stop being making mistakes, all kinds of problems would just go away. The nerve of some people; making the world a more dangerous place, just because they happen to be fallible!
          • Buffer owerflow attacks won't happen in languages which doesn't "support" that feature,

            Pedantically, buffer overflows can still happen in any of those languages. But the easily-exploitable subset called stack overruns cannot. And without stack overruns, the difficulty of convincing a buffer overflow to actually do something harmful is great indeed- but it is a theoretical possibility.
        • What the hell are you talking about?

          >I wonder if this type of exploit could be prevented if the library was written in, say, java instead?

          Sure it could be prevented. It can also be prevented when written in C. See release 1.2.6rc1 [sourceforge.net].

          If you're starting the arguement that Java is inherently more secure, and therefore everything should be written in Java, it's not worth the flamewar.

        • Yes, it could of course be prevented, like most other security holes.
          Java has a bad reputation for being slow, but there are plenty of natively-compiled languages that are quite fast and would at worst result in a denial-of-service (exception) if they had this bug, never execution of arbitrary code.

          It is still a wonder to me that people who claim to be concerned about security choose C for their projects.

  • Diagram (Score:2, Funny)

    by skraps ( 650379 )
    Here [ancoraimparo.net] is a .PNG file with a diagram that explains the problem.

  • Old news (Score:2, Interesting)

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

  • Ah-ha! (Score:5, Funny)

    by iamdrscience ( 541136 ) on Thursday August 05, 2004 @03:40AM (#9886920) Homepage
    You all complained about Internet Explorer not being able to display PNGs correctly, but who's laughing now! Obviously they broke PNG support intentionally for security reasons. Once again, Microsoft comes through on the cutting edge.

  • well (Score:3, Funny)

    by Anonymous Coward on Thursday August 05, 2004 @03:42AM (#9886925)
    it's a good thing all of the porn sites i visit use jpegs

    • ...a few months ago, there was a /. article roasting someone at an antivirus software company for suggesting that "JPEGs may open holes to viruses" and "we may have to give up the JPEG format."

      Slashdot readers were waiting in line to flame the guy for suggesting that mere image files could have any possible security implications ("it's just a data file, it doesn't contain code, he's obviously clueless, unlike me and everyone who agrees with me"), and raising the spectre of having to abandon JPEGs because

  • Updates (Score:4, Informative)

    by Sunspire ( 784352 ) on Thursday August 05, 2004 @03:49AM (#9886950)
    Fedora Core 1 [fedoranews.org] and 2 [fedoranews.org] already have backported security updates for this as 1.2.5-7 and 1.2.5-8 respectively since yesterday. Much better than having to install a release candidate.

  • Bug? it's a feature! (Score:5, Funny)

    by barcodez ( 580516 ) on Thursday August 05, 2004 @03:50AM (#9886958)
    a buffer overflow which could potentially cause a PNG image file to execute arbitrary code

    This is not a bug it's a feature; the libpng team are obviously trying to get a piece of the ActiveX control market...
  • Comment removed based on user account deletion

  • Gentoo (Score:3, Interesting)

    by AliasTheRoot ( 171859 ) on Thursday August 05, 2004 @04:05AM (#9886998)
    I just emerge synced and the latest version available is still libpng-1.2.5-r7

    • Re:Gentoo (Score:5, Informative)

      by Sunspire ( 784352 ) on Thursday August 05, 2004 @04:12AM (#9887021)
      Yeah it's still not fixed, but when an updated package is available it will still most likely simply be versioned 1.2.5-r8. You can keep a watch on the package and see immediately when it's fixed here [gentoo.org].
    • Wait for the rsync mirrors to catch up with cvs. -r8 has been in CVS for a while...

      RCS file: /var/cvsroot/gentoo-x86/media-libs/libpng/libpng- 1 .2.5-r8.ebuild,v

      revision 1.3
      date: 2004/08/05 10:22:53; author: ciaranm; state: Exp; lines: +2 -2
      Stable on sparc, bug #59424

      revision 1.2
      date: 2004/08/05 10:20:27; author: lu_zero; state: Exp; lines: +2 -2
      marked ppc

      revision 1.1
      date: 2004/08/05 10:02:19; author: plasmaroo; state: Exp;
      Security bump for bug #59424.

  • Buffer overflow *again*? (Score:2, Interesting)

    by Anonymous Coward
    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 se
    • Technologies like execshield can help with this. I'd be interested to know if execshield prevented this problem being exploited.

      Yes you could reimplement libpng in a safe language that allowed for C export like D or maybe (with some hackery) Java. Nobody has though.

    • (This troll would be more effective if not posted anonymously.)

      Indeed this flamewar has been repeated many times. Safe languages do indeed provide protection from these kinds of attacks and typically at a fairly small speed penalty [debian.org] (depending on the language; the number-two language on that list is safe and places above C++!).

      See the earlier slashdot discussion [slashdot.org] for loads of argument. ( here [spacebar.org] for my perspective--note, I am a tower-in-the-sky PhD student in programming languages, but I do write lots of

      • I am still boggled that programmers who claim to be interested in security (and who moreover claim to be uninfluenced by marketing and "cool", but rather by technical concerns) still choose C or C++ for their projects.

        I agree that unsafe languages are on the way out for most applications in the long run. There's just no reason NOT to prevent these errors automatically. Code reviews and "being careful" are not solutions. There's no good reason for a language to be full of "undefined behavior" black hole

  • PNG security threat (Score:2, Funny)

    by Anonymous Coward
    Is there oil at Papua - New Guinea?
    • Is there oil at Papua - New Guinea?

      With the risk of being non-funny: yes.

      And the Australian government is making sure that they're getting their 'fair' share of it!

  • Combine this... (Score:5, Informative)

    by cperciva ( 102828 ) on Thursday August 05, 2004 @04:21AM (#9887046) Homepage
    ... with this [isec.pl], and Linux gets to join the "visit a malicious website and get rooted" crowd.
    • All I get is this:
      [+] mmaped uncached file at 0x40014000 - 0x40015000
      [+] mmaped kernel data file at 0x4014c000
      [-] Race lost 0, use another file!
      Terminated
      No matter which file I try.
      Running 2.6.7-gentoo-r10

    • Re:Combine this... (Score:3, Informative)

      by achurch ( 201270 )

      As far as I can tell, that only lets you read memory, which doesn't let you root anything. In fact, I tried the test and though it claimed to have worked, all I got was /proc/mtrr followed 64MB of zeros, which seems odd since my machine's been up long enough that all my physical memory should have been stomped on at some point.

      So yes, these are both serious problems, but they still don't boost Linux up into that vaunted "rootable group". (:

      • Well, it all depends on what the attacker gets from the kernel memory dump. Could be that they get sensitive information or it could be they get nothing that would help in privilege escalation. I'd rather close that door altogether, myself by using 2.6.8-rc or 2.4.27.

        But, please, unless GP has written a proof of concept that shows Linux is rootable via rendering a webpage, he should stop posting flamebait and go back to working on his 'depenguinator'.

  • Arbitrary Code...? (Score:2, Funny)

    by Anonymous Coward
    What is arbitrary code? How is it any different as compared to any other computer code, say a piece of software?

  • Debian (Score:4, Interesting)

    by Fuzzums ( 250400 ) on Thursday August 05, 2004 @06:05AM (#9887304) Homepage
    Within an hour (or so) after the CERT-mail I also got the Matt Zimmerman-mail.

    Fixed :)
    I love this!

    Thanks Guys!

  • SuSE patch also already available (Score:2, Informative)

    by Anonymous Coward
    I just patched my SuSE box. Man that was fast ... or perhaps .. it is because Germany is 6 hours ahead of me.

  • Attribution? (Score:3, Interesting)

    by Quixote ( 154172 ) on Thursday August 05, 2004 @06:33AM (#9887377) Homepage Journal
    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).

    • Re:Attribution? (Score:3, Insightful)

      by FireFury03 ( 653718 )
      If you do that (which is probably a good idea) you'll need to weight it based on the amount of code written by that author that _could_ contain a security hole. Otherwise the stats will just show that the authors who write 99% of the complex network-facing code are responsible for most security holes.

    • Re:Attribution? (Score:3, Insightful)

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

      Terrible idea. I can tell you right now, if I knew I'd be held personally responsible for bugs in open source software I contributed to, I would not contribute. If you want me to take responsibility for my bugs, give me money.

      If you don't like buggy free software, don't use it. What you're describing sounds almost like an inverse meritocracy, where people get branded if they don't write code that's

  • Another exploit in libpng (Score:5, Interesting)

    by ShadowRage ( 678728 ) on Thursday August 05, 2004 @08:25AM (#9887929) Homepage Journal
    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.

    • Re:Another exploit in libpng (Score:5, Interesting)

      by thogard ( 43403 ) on Thursday August 05, 2004 @09:38AM (#9888760) Homepage
      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.
    • BAM* it expands into 2gb of ram.

      *BAM* it reveals that the client-software shouldn't have been naively decompressing the whole file, but only the part it was going to display. (Loading more data from the file when the user begins scrolling)

      But seriously folks, this is an example of why DoS attacks can't really be automatically prevented. There's no strict boundary between a legitimate use of heavy resources and intentional squandering of resources.

      What if someone wants to store 190000 pixels of black?
  • The LibPNG library is merely a standardized library for reading and writing PNG files. It has been ported to many platforms and is even LGPL'd.

    This makes it a two-edged sword in some ways, because nothing is specifically keeping you from writing your own implementation of the PNG specification, but most people are generally lazy and grab whatever is at hand, particularly if it is well written.

    The trick is to keep the formal specification seperated from the implementation so the implementation doesn't bec
    • Are you off your rocker? "Dum de dum...I need to display some PNGs in my program. Rather than use the widely known and used libpng I think I'll write my own entire library". Umm ever here of not re-inventing the wheel? NIHS? Re-use?

      "but most people are generally lazy and grab whatever is at hand"

      It has nothing to do with laziness and if you can't see that then I never want you to write any software for me.

      "One way to prevent issues like this from really taking over is to provide alternative implemen

  • Mitigation... (Score:3)

    by Chief Typist ( 110285 ) on Thursday August 05, 2004 @09:22AM (#9888598) Homepage
    It appears to me that this problem exists at both the client and the server.

    Updating a server to use the patched version of libpng is an obvious first step. You don't want the buffer overflow compromising security as you deliver a .png file (which would only be an issue if you read the .png from the server before delivery.)

    The tricky part is what to do with the .png files that have been tampered with. You don't really want to serve those up to clients -- you'd be delivering a security risk. There will be a significant lag before client software is updated -- browsers and anything else that streams .png over a network connection will be at risk during this time.

    It seems to me that there's a need for some kind of scanning tool that checks for bogus .png files. At the server side, you could scan for compromised files and get rid of them.

    Does such a tool exist?

    -ch
  • Someone was asking on a mailing list why Mozilla fanboys think their browser is so much more secure than the Internet Explorer fanboys' browser. (My words, not his.) The same day, the PNG vulnerability came out. THE SAME DAY, the patched Mozilla, Firefox, etc. were released. I was using the new Mozilla an hour after I learned (via mail from US-CERT) about the vulnerability in a third-party library that Mozilla uses.

    I consider the question answered.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close