Recent Features
| |||||||||||||
Prelink and address space randomizationPrelink and address space randomizationPosted Jul 13, 2006 21:03 UTC (Thu) by roelofs (guest, #2599)In reply to: Prelink and address space randomization by bluefoxicy Parent article: Prelink and address space randomization - File browsers (rabidly displaying thumbnails of images-- remember one day when SIX PNG EXPLOITS showed up at the same time and what FOUR of them were RCE?) Was there ever a proof of concept for any of those (or even for the zlib double-free)? I don't recall one, and I have a certain personal interest in such things. But I could have missed it easily... And FWIW, it was six by CERT's count (of which three were considered potentially remotely exploitable and the others were "impact unknown"), but MITRE (or whoever) considered them as three cases (CVE candidates 2004-0597 through 0599). All are linked from the bottom of the libpng page. Greg
(Log in to post comments)
Prelink and address space randomization Posted Jul 14, 2006 2:13 UTC (Fri) by bluefoxicy (guest, #25366) [Link] 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"
Search milw0rm and security focus if you're looking for exploit code. There might be some there. Also I hear packetstorm keeps loads of example code around but I never personally looked; I may be a security nut but I am more into understanding why these things work than memorizing every exploit in every program ever written.
Prelink and address space randomization Posted Jul 21, 2006 15:47 UTC (Fri) by roelofs (guest, #2599) [Link] 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
Prelink and address space randomization Posted Jul 22, 2006 15:35 UTC (Sat) by roelofs (guest, #2599) [Link] I hate replying to myself, but:It's an overflow by two bytes, and those two bytes are "n" and "k" no matter how mangled you make the image. Doh, it's a string: the two bytes are always "k" and a NULL, not "n" and "k". But the same line of argument holds. Greg
Prelink and address space randomization Posted Aug 20, 2006 7:58 UTC (Sun) by bluefoxicy (guest, #25366) [Link] Apache did this recently, didn't it? "We have an overflow, but you always overflow by like 3 bytes and they're always these bytes, and so it's not exploitable" then like 4 days later "OK somebody owned one of the devs' personal boxes we were wrong there was a really cool trick we missed."
Point is, we shouldn't say "We found an RCE here" if we don't see a way; but we should still say "there may be implications we have not discovered with this." It may be overflow by "k\0" today but tomorrow someone might make it overflow something else in there. We should neither assert that we know this will happen, nor that we know this will not happen.
|
|||||||||||||