71–80 of 88 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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/
The PNG format has lots of variations and optional bits that would be quite annoying if you needed to handle them all yourself. I'm referring to the many various flags, options, and little helper functions in libpng that make handling all these format variations quite painless for the user of libpng.
[Some libraries, e.g. libtiff, provide mechanisms to abstract out the low-level details, but still expect the application to explicitly handle many format variations, and this is quite annoying.]
libpng is hardly perfect; it's old, and that certainly shows in various ways (e.g. the use of setjmp). But to call it the "worst API ever" is just wrong.
Earlier quoted context omitted.
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/
Huh? I'm not referring to setjmp at all... (why would you think I'm referring to setjmp?) The PNG format has lots of variations and optional bits that would be quite annoying if you needed to handle them all yourself. I'm referring to the many various flags, options, and little helper functions in libpng that make handling all these format variations quite painless for the user of libpng. [Some libraries, e.g. libtif…
> 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.
It seemed that you were thinking of error code handling as a "code-path" and setjmp/longjmp being a mechanism to reduce code paths.
Anyway, it sounds like we're in agreement. It's not that big of a deal to use libpng directly, and "worst API ever" is too strong. The author has probably not done enough Windows API programming to find the worst API ever :-).
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!
Everyone has known what a massive security risk unsafe languages are for a long time. Nearly every vulnerability is a buffer overflow. What's the value in persisting in writing such dangerous code? Just because it's 10% faster than a safer language? Hopefully the likes of Rust bring and end to this.
Perhaps there's a culture of C++ being the only proper language for libraries?
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…
If a PNG app trusts the spec, and the library doesn't comply, and that causes the app to crash. That's a good thing overall. It would lead to somebody discovering the problem and hopefully fixing it. It's only a bad thing for the specific app that crashes. Or in this case, risks getting exploited. Maybe for security, the principle doesn't apply the same way.
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…
Just look at any forum about some open source software. There'll usually be endless posts from people complaining that they can't compile it because of some weird dependency errors. These are really widespread and time-wasting problems.
Earlier quoted context omitted.
> 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.
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 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.)
Earlier quoted context omitted.
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.
size_t sz = lib_get_buffer_size();
char *buf = malloc(sz);
lib_fill_buffer(buf);
It's a deficiency in the API, which should require the buffer size to be passed to lib_fill_buffer so lib_fill_buffer doesn't have to make any assumptions about the size. But if you're trying to preserve compatibility with existing C APIs, you might be stuck with APIs like this.
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…