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

51–60 of 88 posts

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

#51

Post by nitrogen »

noobermin wrote: post #44
legulere wrote: post #40

Earlier quoted context omitted.

The problem is that it only works with system libraries and when you have a central software repository. You couldn't even do it with an appstore, as you can possibly break tons of software that you can't patch yourself. So what actually happens with dynamic linking there is that old .dll/.dylib files (with vulnerabilities) get copied around. With zlib I agree though. Static linking doesn't make sense with such a sta…

So do a mix? Make system libs shared and apps bundled when they are needed? Can't the app store work like your package manager anyway? Speaking from ignorance here, I want to know if it's possible.

The Click-n-Run app store from LindowsOS back in 2002 was based on apt and dpkg. So yes, it is possible, especially if there are automated tests that can tell when a dependency update breaks something.

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

#52

Post by Eridrus »

whoopdedo wrote: post #36
revelation wrote: post #34

Earlier quoted context omitted.

Does anyone actually interface libpng themselves? The library is pure insanity if all you care about is getting the image out in some format. I'd wager that there is one libpng and then only about 4 or 5 distinct pieces of code that use it that everyone else in turn is using. If that code is wrong, that would still make it widely vulnerable.

Github search: png_get_PLTE C 48892 C++ 2916 Obj-C 36 Apple programmers aren't using it directly at least. Nor Android, which is not exploitable[1]. Chromium also uses SKIA I believe. The C number is obviously inflated by the number of repositories that contain a copy of libpng. If everyone is using common glue code then I think it's more likely this won't be a problem since the middleware library probably noticed th…

Going through some random code on codesearch.com a lot of code seems to just pass in a png_colorp * as the pallete, which this doesn't break.

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

#53

Post by smtddr »

Rexxar wrote: post #30
throwaway2048 wrote: post #21

Earlier quoted context omitted.

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.

A system can be owned using various exploits combined together. So if someone finds a way to alter the installation images, suddenly a mild trick that would normally just result in funny icons is now an exploit.

Kinda good example right here: https://www.youtube.com/watch?v=CkPAgv1Gjz0

Maybe Nintendo never considered someone screwing around with their network to load an arbitrary image in a place that only Nintendo-Generated Mii png images should be but then I found a way... and if that libpng was vulnerable, suddenly we've gained usermode execution on a Wii U. Or worse yet, similar to the Sony PSP .tiff image exploit, maybe after gaining usermode we find a kernel-mode exploit and attack that. Now, we're near the realm of game piracy and private keys.

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

#54

Post by tedunangst »

kibwen wrote: post #49
mike_hearn wrote: post #26

Earlier quoted context omitted.

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.

What killercup might be implying is that Rust is both a "safe language" and that Rust code can expose a C-compatible ABI, which means that a library written in Rust could theoretically replace one written in C regardless of which other language is ultimately making use of it. For example, this is what Mozilla is working on doing in Firefox by replacing security-conscious components with Rust implementations ( https:/…

However, if the bug is that the library writes to a too small allocation by the application (based on a lie told it by the library) then it doesn't much matter what language the library is in.

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

#55

Post by contingencies »

This vulnerability is quite ... foretold. We have had issues with image libraries before. Instead of just running about patching again for this one bug, why not use the opportunity to discuss some architecture-level approaches that may have mitigated this attack?

Knowing that image libraries may contain vulnerabilities, how would you design a secure image ingestion process?

Some reasonable strategies...

(0) Attack surface minimization: Similarly to other types of input, input is segregated and treated as toxic and dangerous until proven otherwise. (Eg. Don't store random inbound files where you store those you will re-use; never allow batch processes to touch temporary files received from external systems; delete external input as soon as possible; store input only after normalization)

(1) Attack surface minimization: only accept one file format. This provides no guarantees but helps to limit exposure to unknown vulnerabilities, though may not always be feasible.

(2) Parallelization (opposite of the above): explicitly convert all formats of input to some common format (using throwaway containers/VMs), ideally using multiple versions of multiple libraries on multiple operating systems, and compare the results. If the results of every environment do not match, raise an alarm and do not continue processing.

(3) Reverse-conversion check. Convert the file to another (non-lossy conversion possible) format, then convert it back (also in a throwaway environment). If the result matches (or the portion of the result that is non-lossy matches) continue. This could be combined with #2 for additional strength.

(4) "Application-level firewall" approach: progressively determine the various format-specific and general properties of the image in question (eg. starting with libmagic; and preferably all in relatively secured throwaway environments, using the above strategies!) then apply a neural network or basic statistical analysis to generate alerts for anomiles. For instance, the reduced pallette featured in this attack would not be normal for many types of image input (scans or photographs come to mind). Other useful checks may include "are the image dimensions sane?", "is the aspect ratio sane?", "is the image predominantly black and white?", etc.

Strategies #0 (in particular cases), #1 (with some luck), #2, #3 and #4 (with some luck) could have mitigated this attack. Executed wrongly, any of those strategies could also have triggered the vulnerability. #4 is ripe for a web2.0 Silly-Valley outsource-the-problem startup (investors?).

PS. I enjoy these types of problems; anyone looking for ideas or development get in touch.

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

#56

Post by asveikau »

revelation wrote: post #34
whoopdedo wrote: post #31

Some applications might read the bit depth from the IHDR chunk and allocate memory for a 2^N entry palette, while libpng can return a palette with up to 256 entries even when the bit depth is less than 8. On initial review, this will require assumptions in the client application to be exploitable. I haven't found a place where libpng itself causes the overrun. It is just an enabler by returning a smaller value for bi…

Does anyone actually interface libpng themselves? The library is pure insanity if all you care about is getting the image out in some format. I'd wager that there is one libpng and then only about 4 or 5 distinct pieces of code that use it that everyone else in turn is using. If that code is wrong, that would still make it widely vulnerable.

The libpng simple decoder sample is pretty reasonable C, except for the fact that it uses setjmp to handle errors. (libpng's fault, not the sample.)

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

#57

Post by marssaxman »

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…

Containerization might well be the solution to this kind of problem: libpng's vulnerabilities no longer matter much if you've isolated it into its own VM with no access to resources beyond the ones it needs to decode a PNG into a pixel buffer. I've been working on a little OS project along these lines, where every process runs in its own VM, and every shared service is provided by a local server. There's no dynamic linking. Instead of dealing with the cost of constantly churning code, and all the instability and unreliability that comes along with it, the idea is to pay for security up front by isolating everything. If you want to decode a PNG you have to spin up a VM, stream the PNG data in, and stream the decoded pixels out. The PNG decoder has no access to the file system, network interfaces, user interfaces, or really anything but stdin and stdout and some memory. If it crashes, it crashes, and from the client's perspective the app just exited with a non-zero error code.

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

#58

Post by hyperion2010 »

simoncion wrote: post #37
noobermin wrote: post #24

Earlier quoted context omitted.

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 wi…

> I'm a gentoo user and before preserved libs came in, updates to libpng required recompilation of almost everything on a system. I'm also a Gentoo user. (Hi! :D ) ISTR that preserved-libs "just" lets you delay recompilation of affected packages [0] by keeping the old libs around until everything that needs rebuilding to link against the new version has been rebuilt. You still need to rebuild packages. Am I wrong abo…

Oh man, the number of times I have delayed updating a system because different programs required different versions of libpng. On the other hand, having used gentoo as my primary distro for nearly a decade I have found that there are some serious benefits to actually knowing what libs are actually involved in creating a functional linux environment.

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

#59

Post by zanny »

rewqfdsa wrote: post #41
zanny wrote: post #32

Earlier quoted context omitted.

Any sane library should be using a stable ABI. Qt does it with giant libraries but any software compiled against any 5.x release will work with any of them since they require ABI stability. You don't even need to ABI break on new features if you use PIMPL right. Its only when you change your API function signatures that already exist that you break the ABI. And thats the way every library should be.

PIMPL is an inefficient antipattern when the holder object is itself heap-allocated. You're better off coding against interfaces, COM-style.

It doesn't matter if your holder is heap or stack allocated, the d pointer is always heap allocated and the only reference to it is the private internal. With interfaces you either have an awful dummy static constructor for your private object somewhere or you have a non-virtual parent class with dummy implementations of all its functions and a mangled constructor that produces its private child.

For the developer, interfaces are cleaner, but for users, the interface style is leaky where PIMPL is not. That makes it superior. It also avoids overriding the intent of inheritance as a way of achieving ABI compatibility when it already has a significant and intentional function of runtime polymorphism, and can easily confuse users as to whether the implementation is to preserve the ABI or provide multiple implementations in the same release.

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

#60

Post by [deleted] »

tedunangst wrote: post #54
kibwen wrote: post #49

Earlier quoted context omitted.

What killercup might be implying is that Rust is both a "safe language" and that Rust code can expose a C-compatible ABI, which means that a library written in Rust could theoretically replace one written in C regardless of which other language is ultimately making use of it. For example, this is what Mozilla is working on doing in Firefox by replacing security-conscious components with Rust implementations ( https:/…

However, if the bug is that the library writes to a too small allocation by the application (based on a lie told it by the library) then it doesn't much matter what language the library is in.

[deleted]
Post reply on HN