Below are listed ... some of those libraries that have had significant security holes allowing remote runtime code execution.
I have to call bullshit on that one. Like far too many of those publishing these advisories, MITRE and/or the "CVE Editorial Board" are far too eager to artificially inflate the severity levels for press purposes, to all appearances--and as far as I can determine, they never correct their mistakes or even properly qualify the threat-level with specific information provided by the original reporter. (I have personal experience with that--though not via libpng, for which I'm incorrectly credited as the "vendor.")
In this particular case, the buffer overflow is by two bytes, and those two bytes are 'k' and NULL, period. While one could certainly imagine a processor architecture in which ASCII (or EBCDIC) 'k' and NULL are valid jump/branch-related opcodes, I defy anyone to come up with even a proof-of-principle exploit for a processor of actual, pragmatic interest. Remote denial of service is the realistic worst case, and while that's certainly bad enough, it's not exactly doomsday. (Last week's issue is similar.)
As to the other two issues, the 2004 one was definitely at the high end of the nasty-o-meter (although I never did hear of any actual exploits--not that I necessarily would have, of course); I no longer recall the specifics of the 2002 one (other than that it had to do with 16-bit samples), but I'll assume remote execution was a possibility there, too. So yes, there have been real issues, and nothing I've said here contradicts any of the main conclusions of the article. I simply wish there could be a little more precision in security advisories, insofar as they're the raw fodder used in so many other analyses...
P.S. I'll see if I can't get 3334 updated...perhaps I'll get lucky this time.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds