| |||||||||||||
vulnerability inflationvulnerability inflationPosted Nov 22, 2006 23:49 UTC (Wed) by roelofs (guest, #2599)Parent article: Virtual Machines and Memory Protections
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... Greg P.S. I'll see if I can't get 3334 updated...perhaps I'll get lucky this time.
(Log in to post comments)
vulnerability inflation Posted Nov 23, 2006 19:29 UTC (Thu) by bluefoxicy (guest, #25366) [Link] Score: 4 (Insightful)
Mod parent up, and other slashdotisms.
I wasn't aware of that issue; although the other listed CVEs are valid I believe. The point was that things like that are stopped cold by PaX/SELinux memory protection policy; and you can't use those with JIT.
vulnerability inflation Posted Nov 30, 2006 16:05 UTC (Thu) by PaXTeam (subscriber, #24616) [Link] sorry to burst your security bubble, but things don't quite work the way you imagine it. the 2 byte overflow can very well lead to arbitrary code execution. imagine that the buffer you overflow ends just below the saved frame pointer (whether that actually occurs in real life binaries or not is a question you should have answered before jupming to conclusions about the bug being not exploitable). overwriting the 2 LSBs of the frame pointer with a fixed value of "k\0" will most likely decrease its value (on little-endian CPUs like i386), that is, on function return the frame pointer will point into a memory (stack) region that is not actually part of any live stack frame. depending on the execution history of the whole app (not only lib!) this memory region may very well be valid (mapped) already, hence further code executes with a frame (and later, stack) pointer that isn't quite where it's expected. since past execution may very well have left user controlled data on the stack where the code expects trusted data only, you have a situation wide open for exploitation. this isn't even something new, http://phrack.org/archives/55/P55-08 had desribed this a long time ago.
|
|||||||||||||