CVE-2015-8126: Multiple buffer overflows in libpng

Re:CVE-2015-8126: Multiple buffer overflows in libpng by marssaxman on Saturday November 14, 2015 @06:09PM (#10567696)

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.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by epoch1970 on Saturday November 14, 2015 @07:00PM (#10567846)

> 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.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by wbl on Saturday November 14, 2015 @08:50PM (#10568175)

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.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by ploxiln on Saturday November 14, 2015 @10:59PM (#10568424)

Well seccomp() strict mode (only allows read, write, exit) has been available since linux-2.6.12 (2005). So no need to invent something new, or set up a bunch of cgroups and namespaces, to get processes that can only read stdin and write stdout and use some of their own memory.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by marssaxman on Saturday November 14, 2015 @08:01PM (#10568035)

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.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by ploxiln on Saturday November 14, 2015 @11:06PM (#10568439)

For something like libpng, there isn't any "instability and unreliability" and the code is hardly churning. Just `apt-get update` or `pacman -Syu` and you've got the patched version, compatible with all binaries on your system.

The only exception would be something like Chrome/Chromium that bundles a bunch of its own tweaked copies of common libraries. Or various closed-source software not controlled by your package manager, like some commercial games which have a linux build available. But many systems, like my home router/fileserver, and my workstation, don't have any of these exceptions, and they were updated in about 2 minutes. (I have no long running network daemons using libpng, but if I did they would be easy to restart.)

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by PinkysBrain on Monday November 23, 2015 @01:12PM (#10616104)

We have no processors which can efficiently isolate memory spaces with that fine granularity.

Which is why we should have stopped using C long ago and used languages which could guarantee that kind of isolation with less overhead.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by fanf2 on Monday November 16, 2015 @04:28PM (#10577322)

Sounds like Qubes

[ Parent | on HN ]