Prelink and address space randomization

Prelink and address space randomization

Three then. I think one is enough to say "we should not load random images in file browsers and expect them to never try to hax0rz us with their l33t skr1ptz1ez!!!1113"

Oh, absolutely--I'm not defending the existence of the security problems, just questioning the sensationalism and risk-inflation that seems to be inherent in security companies' announcements these days.

Consider the most recent issue (listed under "png" rather than "libpng" in this week's Security page). Yes, it's a buffer overflow, but does that automatically mean remote code execution? It's an overflow by two bytes, and those two bytes are "n" and "k" no matter how mangled you make the image. Now what? Is there any realistic way to exploit that for anything beyond denial of service? Every RCE I've ever seen is highly dependent on the attacker's ability to write dozens of bytes to the stack, bytes that contain the code to be executed. That's not the case here.

And while it's still conceivable that random chance could cause these two bytes to combine with two others to overwrite a return address and send the code off to somewhere in the compressed or uncompressed image buffer for execution of badness, I suspect that possibility is so remote as to be nonexistent in any practical sense. (Also, further analysis might well be able to demonstrate that it's physically impossible--e.g., because the other two bytes are constrained by upstream libpng stack usage or because the "nk" become the high bytes and refer to an impossible address in either 32-bit or 64-bit Linux systems or whatever. But now I'm speculating...)

Anyway, it's definitely bad that libpng and other image-processing libraries continue to have these bugs. Not terribly surprising, mind you, given their complexity, but bad nonetheless. I keep hoping we're simply plugging longstanding holes and thus making the net result safer at every step, but I don't know if that's true, either.

Greg