6 ms·

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

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 everywhere. Patching this properly will require not just replacing a centralized copy of libpng, but scanning all binaries for statically-linked copies. There might be some tools left over from the last time libpng got into trouble; this would be a very good time to update and link to them. Some categories of software that are at particularly high risk right now: * Web browsers. Sandboxing likely helps, but there's a possibility that there are some usages (eg favicons) that decode outside the sandbox. * MMS on Android (possibly remote root on phones with no user interaction) * Any server that accepts PNG uploads and processes them (eg, user avatar thumbnail generation) * Anything which shows people user-provided avatar images (eg, IM clients) * Video games which download levels that can contain images * File browsers which show image previews * Music players which display album covers Expect malicious images to start appearing everywhere, and soon. If you're responsible for the computer security anywhere, this is a drop-everything priority.

heinrich5991 11y ago
Is this more than a denial of service due to crashes?
- cbhl 11y ago
  No. Buffer overflows can be used for privilege escalation. Crashes are better than privilege escalation, but they do not mean that privilege escalation is impossible.
- bennofs 11y ago
  I guess the problem is that you don't know: > allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact As far as I understand, trying to predict what is possible by exploiting a buffer overflow is hard because it depends on many specifics, such as compiler options used, OS protections, ...
  - deleted 11y ago
    [deleted]
- jimrandomh 11y ago
  No one's published an example which causes arbitrary code execution yet (that I'm aware of), but most bugs of this type end up there eventually.
  - airza 11y ago
    You'd need an infoleak but from somewhere, but I doubt anyone who has one will come forward.
swiley 11y ago
The best part about android is that all the important apps are tied together and have to be updated at once. It seems like it really wouldn't be hard to write an MMS worm that stuck around for a while.
throwaway2048 11y ago
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/unnoticed.
- noobermin 11y ago
  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 with distribution of software could weigh in on whether there is a way to mitigate this issue when it comes to people who choose to bundle software for ease for users' sake.
  - zanny 11y ago
    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.
    - rewqfdsa 11y ago
      PIMPL is an inefficient antipattern when the holder object is itself heap-allocated. You're better off coding against interfaces, COM-style.
      - zanny 11y ago
        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.

heinrich5991 11y ago

Is this more than a denial of service due to crashes?

cbhl 11y ago
No. Buffer overflows can be used for privilege escalation. Crashes are better than privilege escalation, but they do not mean that privilege escalation is impossible.
bennofs 11y ago
I guess the problem is that you don't know: > allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact As far as I understand, trying to predict what is possible by exploiting a buffer overflow is hard because it depends on many specifics, such as compiler options used, OS protections, ...
- deleted 11y ago
  [deleted]
jimrandomh 11y ago
No one's published an example which causes arbitrary code execution yet (that I'm aware of), but most bugs of this type end up there eventually.
- airza 11y ago
  You'd need an infoleak but from somewhere, but I doubt anyone who has one will come forward.

swiley 11y ago

The best part about android is that all the important apps are tied together and have to be updated at once. It seems like it really wouldn't be hard to write an MMS worm that stuck around for a while.

throwaway2048 11y ago

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

noobermin 11y ago
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 with distribution of software could weigh in on whether there is a way to mitigate this issue when it comes to people who choose to bundle software for ease for users' sake.
- zanny 11y ago
  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.
  - rewqfdsa 11y ago
    PIMPL is an inefficient antipattern when the holder object is itself heap-allocated. You're better off coding against interfaces, COM-style.
    - zanny 11y ago
      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.