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

61–70 of 88 posts

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

#61

Post by kibwen »

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.

I see there are some downvotes here, which I don't think are deserved. It's true that at some level of your stack you're going to have some code that's just poking bytes into buffers, and that generally takes some manual effort to verify.

For what it's worth, I'd expect this sort of thing to be walled up behind an `unsafe` block in Rust, which if nothing else would lend increased scrutiny in an audit.

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

#62

Post by zanny »

tedunangst wrote: post #50
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.

Most libraries are not sane. API breaks are common, and often security updates are only available in new, incompatible releases.

Then don't use those libraries! How can you trust a third party library to provide functionality to your software if they cannot even release sanely with ABI stability? Its a disservice to you and your users to risk security vulnerabilities like this.

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

#63

Post by epoch1970 »

marssaxman wrote: post #57
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…

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

> The PNG decoder has no access to the file system, network interfaces, user interfaces, or really anything but stdin and stdout and some memory.

So you've rediscovered what UNIX has allowed us to do for decades now.

Things like process isolation, memory isolation, file isolation, and hardware isolation aren't new. UNIX systems offered mature implementations of them in the 1980s, if not before then.

Best of all, this functionality was offered without needing to resort to resource-intensive virtual machines or anything of that sort.

Those who want the level of isolation you propose have been able to get it for a long time now. They just tend not to, because it's inconvenient and impractical for real world systems.

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

#64

Post by rdtsc »

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…

Technology moves so fast that everyone has short memory, patience and attention span.

So stuff like this happens [this is a tongue in cheek scenario, treat it as joke, not criticism of particular people or framework]:

Developer1: "Argh, I can't figure out dependencies for this library",

Then someone comes along and "fixes" it:

Developer2: "Look, just static compile it / include all deps in a subdir some place. See, fixed! I even made a language / framework thingie to do this for you. Yeah, those stupid old packagers and OS people made such a mess...".

Developer1: "Oh wow so easy, I'll be using this and tell others to use it too." /goes to twitter...

A few years later, everyone uses the new shiny dependency-bundling library/framework thingie. Then a security vulnerabily hits and everyone realizes why those old boring packagers and OS people set things up the way they did. 6 days later everyone forgets and jump on the next new shiny framework. Cycle repeats...

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

#65

Post by snogglethorpe »

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.

libpng is actually very easy to use directly.

Some other image libraries are hard because they force you to write many code-paths to handle various different cases, but libpng provides many different helpers that make it pretty simple.

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

#66

Post by kalleboo »

mmaunder wrote: post #46

Curious if this affects PHP. AFAIKT GD is compiled with libpng for PHP (it's required) and is presumably used for functions like getimagesize() in PHP. That is used by WordPress core for uploads (although you need to be signed in). However I suspect many plugins use GD for unauthenticated image upload, so this could have a wide impact.

If I'm reading this comment https://news.ycombinator.com/item?id=10567353 and this code https://github.com/libgd/libgd/blob/4751b606fa38edc456d62714... correctly, then it looks like GD isn't vulnerable since it uses num_palette to size the palette rather than info_ptr->palette or bit_depth

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

#67

Post by marssaxman »

epoch1970 wrote: post #63
marssaxman wrote: post #57

Earlier quoted context omitted.

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

> The PNG decoder has no access to the file system, network interfaces, user interfaces, or really anything but stdin and stdout and some memory. So you've rediscovered what UNIX has allowed us to do for decades now. Things like process isolation, memory isolation, file isolation, and hardware isolation aren't new. UNIX systems offered mature implementations of them in the 1980s, if not before then. Best of all, this…

Oh, sure, but once you start playing "there's nothing new under the sun", the mainframe guys will eventually come along and explain how they were doing all that in some vastly more sophisticated way back in 1962 using systems none of us have ever heard of. So what? I don't care. I just think that the definition of "practical" is shifting, and I want to play with another way of doing things in case it turns out to suit my needs better.

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

#68

Post by wbl »

epoch1970 wrote: post #63
marssaxman wrote: post #57

Earlier quoted context omitted.

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

> The PNG decoder has no access to the file system, network interfaces, user interfaces, or really anything but stdin and stdout and some memory. So you've rediscovered what UNIX has allowed us to do for decades now. Things like process isolation, memory isolation, file isolation, and hardware isolation aren't new. UNIX systems offered mature implementations of them in the 1980s, if not before then. Best of all, this…

That's just not true. A program needs to be started root to execute setuid(2): there is no way for a program started by an unprivileged user to drop privileges. Nor can it drop network privileges. That's why tools like pledge(2) and seccomp had to be added, but they have their own problems. To get the level of isolation GP described, you need some fairly esoteric solutions.

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

#70

Post by AndyKelley »

snogglethorpe wrote: post #65
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.

libpng is actually very easy to use directly. Some other image libraries are hard because they force you to write many code-paths to handle various different cases, but libpng provides many different helpers that make it pretty simple.

Are you referring to setjmp? Because it's quite the opposite. This blog article does a good job explaining: http://latentcontent.net/2007/12/05/libpng-worst-api-ever/
Post reply on HN