| |||||||||||||
Prelink and address space randomizationPrelink and address space randomizationPosted Jul 14, 2006 2:13 UTC (Fri) by bluefoxicy (guest, #25366)In reply to: Prelink and address space randomization by roelofs Parent article: 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"
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.
(Log in to post comments)
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.
|
|||||||||||||