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.
CVE-2015-8126: Multiple buffer overflows in libpng
31–40 of 88 posts
Re: CVE-2015-8126: Multiple buffer overflows in libpng
#32Earlier 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…
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…
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.
Re: CVE-2015-8126: Multiple buffer overflows in libpng
#33Where does one get the patched libpng-1.6.19? The libpng site is broken for me right now.
http://libpng.sourceforge.net/index.html
Sourceforge also seems to be under heavy load. I found this mirror:
Re: CVE-2015-8126: Multiple buffer overflows in libpng
#34Some 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.
Re: CVE-2015-8126: Multiple buffer overflows in libpng
#35Unlike, for example, heartbleed, a vulnerability in libpng really requires some contemplation to come up with all the places and ways that a typical production application uses the vulnerable code.
I have web applications that probably use libpng five different ways, each from a different client application and libpng version.
Re: CVE-2015-8126: Multiple buffer overflows in libpng
#36Some 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.
Github search: png_get_PLTE
C 48892
C++ 2916
Obj-C 36
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 the bug and works around it. It's when developers hastily reinvent the wheel that sloppy validation bugs like this are problems. It's why the maxim "never write your own crypto" exists. Or as Mark Twain said[2], "put all your eggs in one basket and _watch_that_basket_."
But as I said, there's no actual buffer overflow in libpng. This is a validation bug. The headline and the NVD summary are misleading.
[1]https://android.googlesource.com/platform/external/skia/+/ma...
[2]maybe
Re: CVE-2015-8126: Multiple buffer overflows in libpng
#37Earlier 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…
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 about that?
[0] Or, -alternatively- "just" lets you keep your system working while you rebuild affected packages.
Re: CVE-2015-8126: Multiple buffer overflows in libpng
#38Earlier 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…
No that's exactly right. I'm specifically referring to your [0] comment. It allows me to spread the compilation over a longer time (days) while being able to use the old things without breakage. Before, I had to recompile everything and things would be unworkable until everything was recompiled. I now have a number of boxes with distcc so compilation times aren't that bad nowadays. But back in 2010 or so, when I just had a shitty gateway laptop, dealing with libpng version bumps was a weekend affair.
Re: CVE-2015-8126: Multiple buffer overflows in libpng
#39Earlier 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. 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…
No that's exactly right. I'm specifically referring to your [0] comment. It allows me to spread the compilation over a longer time (days) while being able to use the old things without breakage. Before, I had to recompile everything and things would be unworkable until everything was recompiled. I now have a number of boxes with distcc so compilation times aren't that bad nowadays. But back in 2010 or so, when I just…
> Before, I had to recompile everything and things would be unworkable until everything was recompiled.
Oh god, tell me about it. I was around for the first libpng upgrade catastrophe, way back when. Portage/emerge has gotten so much better since then. :D
Re: CVE-2015-8126: Multiple buffer overflows in libpng
#40Uh 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…
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 standard library, at least under unix systems.