Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2015-8126: Multiple buffer overflows in libpng

web.nvd.nist.gov

Post reply on HN
Print view View original

21–30 of 88 posts

Re: CVE-2015-8126: Multiple buffer overflows in libpng

#21

Post by throwaway2048 »

jimrandomh wrote: post #3

Uh oh. It's time for the monthly global computer security meltdown. Again, but worse this time. Security vulnerabilities in libpng are a huge deal; they affect lots and lots of different programs, including things people don't usually think of, and many them embed their own copies of libpng which makes them hard to update. The last time there was a security vulnerability in libpng, it took years before it was fixed e…

This is exactly why static linking/bundled libs/containerization is such a piss poor idea. We are going to be dealing with this vuln for years and years, if not decades to come. The exact same insanity has has happened with embedded copies of zlib in the past.

The solution to dependency management in way too many cases becomes "never update". And those mechanisms allow negligence like that to fester for years ignored/unnoticed.

Re: CVE-2015-8126: Multiple buffer overflows in libpng

#22

Post by 0xcde4c3db »

packetized wrote: post #6
deanclatworthy wrote: post #4

What are the practical implications of this?

No input validation in the IHDR as to the number of bits in the palette of the image. As I understand it, you just create an arbitrary image with the palette in the IHDR tweaked to a large number of bits, and watch as the process dies while trying to malloc() enough space to handle a palette that large. http://seclists.org/oss-sec/2015/q4/264

I think it's the other way around: the malicious image specifies a small bits-per-pixel value in IHDR (thus in some sense advertising that the palette will have 2^bpp entries) but then contains a palette with more than 2^bpp entries, which libpng will copy in its entirety when asked to read the palette, overflowing the destination buffer if the application only allocated enough memory for the expected number of entries.

Re: CVE-2015-8126: Multiple buffer overflows in libpng

#24

Post by noobermin »

throwaway2048 wrote: post #21
jimrandomh wrote: post #3

Uh oh. It's time for the monthly global computer security meltdown. Again, but worse this time. Security vulnerabilities in libpng are a huge deal; they affect lots and lots of different programs, including things people don't usually think of, and many them embed their own copies of libpng which makes them hard to update. The last time there was a security vulnerability in libpng, it took years before it was fixed e…

This is exactly why static linking/bundled libs/containerization is such a piss poor idea. We are going to be dealing with this vuln for years and years, if not decades to come. The exact same insanity has has happened with embedded copies of zlib in the past. The solution to dependency management in way too many cases becomes "never update". And those mechanisms allow negligence like that to fester for years ignored…

I'm a gentoo user and before preserved libs came in, updates to libpng required recompilation of almost everything on a system. So while libpng is unknown to most linux users, gentoo peeps are well aware of it.

Anyway, this is exactly the question I wanted to ask, whether stuff like this counts against bundling. I am, however, not very experienced in these things, I'm curious if anyone else who has more experience with distribution of software could weigh in on whether there is a way to mitigate this issue when it comes to people who choose to bundle software for ease for users' sake.

Re: CVE-2015-8126: Multiple buffer overflows in libpng

#25

Post by 0xcde4c3db »

Do I understand correctly that for this to be potentially exploitable, the application must allocate too little memory for the palette? In other words, could this be mitigated on the application side by always allocating at least enough memory for a 256-entry palette?

I don't mean to suggest that this is "really" an application bug or that people shouldn't upgrade libpng ASAP; I'm just wondering whether there are other options for installations/applications where that would be painful for some reason.

Re: CVE-2015-8126: Multiple buffer overflows in libpng

#26

Post by mike_hearn »

killercup wrote: post #11

A good opportunity to check how https://github.com/PistonDevelopers/image-png is doing (a PNG decoder written in Rust). Looks like it includes bindings to use miniz.c for DEFLATE decoding as well as "inflate" (which seems to be DEFLATE in Rust). Also, it seems to have a fuzzing driver (png-afl). Good times!

There are PNG decoders written in a bunch of safe languages.

For instance the JVM uses a Java PNG decoder. So it isn't vulnerable.

Re: CVE-2015-8126: Multiple buffer overflows in libpng

#27

Post by packetized »

0xcde4c3db wrote: post #22
packetized wrote: post #6

Earlier quoted context omitted.

No input validation in the IHDR as to the number of bits in the palette of the image. As I understand it, you just create an arbitrary image with the palette in the IHDR tweaked to a large number of bits, and watch as the process dies while trying to malloc() enough space to handle a palette that large. http://seclists.org/oss-sec/2015/q4/264

I think it's the other way around: the malicious image specifies a small bits-per-pixel value in IHDR (thus in some sense advertising that the palette will have 2^bpp entries) but then contains a palette with more than 2^bpp entries, which libpng will copy in its entirety when asked to read the palette, overflowing the destination buffer if the application only allocated enough memory for the expected number of entri…

You're precisely right.

Re: CVE-2015-8126: Multiple buffer overflows in libpng

#29

Post by cesarb »

0xcde4c3db wrote: post #22
packetized wrote: post #6

Earlier quoted context omitted.

No input validation in the IHDR as to the number of bits in the palette of the image. As I understand it, you just create an arbitrary image with the palette in the IHDR tweaked to a large number of bits, and watch as the process dies while trying to malloc() enough space to handle a palette that large. http://seclists.org/oss-sec/2015/q4/264

I think it's the other way around: the malicious image specifies a small bits-per-pixel value in IHDR (thus in some sense advertising that the palette will have 2^bpp entries) but then contains a palette with more than 2^bpp entries, which libpng will copy in its entirety when asked to read the palette, overflowing the destination buffer if the application only allocated enough memory for the expected number of entri…

If that's the case, and bpp is always 8 or less, then software where the programmers were "lazy" and always allocated 256 entries for the palette might not be vulnerable.

From a quick search in MXR (https://mxr.mozilla.org/mozilla-central/) for the identifiers "png_set_PLTE" and "png_set_PLTE", it seems that at least Mozilla (Firefox) did the lazy thing and always allocated 256 entries.

Edit: I was right, from https://bugzilla.mozilla.org/show_bug.cgi?id=1224244 "Mozilla is not vulnerable to the security issues that it fixes, when using either the in-tree libpng or the system libpng."

Re: CVE-2015-8126: Multiple buffer overflows in libpng

#30

Post by Rexxar »

throwaway2048 wrote: post #21
jimrandomh wrote: post #3

Uh oh. It's time for the monthly global computer security meltdown. Again, but worse this time. Security vulnerabilities in libpng are a huge deal; they affect lots and lots of different programs, including things people don't usually think of, and many them embed their own copies of libpng which makes them hard to update. The last time there was a security vulnerability in libpng, it took years before it was fixed e…

This is exactly why static linking/bundled libs/containerization is such a piss poor idea. We are going to be dealing with this vuln for years and years, if not decades to come. The exact same insanity has has happened with embedded copies of zlib in the past. The solution to dependency management in way too many cases becomes "never update". And those mechanisms allow negligence like that to fester for years ignored…

If a software use libpng to read images that only come from installation directory, I don't think it's really a problem to link statically libpng.

For example a GUI that loads icons, background images, button images etc.

Post reply on HN