Recent Features
| |||||||||||||
Prelink and address space randomizationPrelink and address space randomizationPosted Jul 7, 2006 18:58 UTC (Fri) by bluefoxicy (guest, #25366)In reply to: Prelink and address space randomization by jakub@redhat.com Parent article: Prelink and address space randomization
Unfortunately some of the most security sensitive binaries aren't typically PIE'd, even on RedHat systems (at least not last I looked; I was told explicitly "network-facing daemons"). These can inclcude:
- Konqueror plug-ins (they run as separate executable)
If you want to nit pick, you could even say something about less obvious binaries:
- Office suites (malicious Word documents that overflow the decoder)
And if you really want to go all out:
- Shells (for those days when they just don't want to deal with certain escape sequences or invalid UTF8)
I can't think of anything more ridiculous to exploit than a shell, sorry. 'ls' and 'cat' would be cute but I can't think of any technically feasible screw-up that would leave those exploitable. Note most of these are theoretical; I don't have real shell/script interpreter exploits in mind.
Back to the original topic, let's not forget that prelink is also available on Debian/Ubuntu and Gentoo. On Debian/Ubuntu we don't yet have pie; on Gentoo we have pie everywhere*** or nowhere. Building such binaries as PIE is a good idea and fairly non-invasive (the overhead is about 1%* in about 5-8%** of the code ever executed, so 0.05%-0.08%), but it's not wide-spread and it defeats the purpose of prelink in those cases.
* There is a 5% performance increase gained by -fomit-frame-pointer on x86, but NOT in PIC. I didn't say 6% because Ubuntu doesn't seem to use -fomit-frame-pointer anyway. On x86-64 the overhead is like 0.02% max.
** About 4-7% of the code executed on the system is in Xorg's main executable; every other program seems to execute under 1% in the main executable, most under 0.2%. This information courteous of me mass-profiling my whole damn system with oprofile because Theo de Raadt insists that PIE is "very expensive."
*** Everywhere except where it breaks things, which is a lot of places. Turn off hand-optimized assembly in everything (during ./configure or with USE flags) if you want to attempt this. It AND ProPolice used to break Xorg; I don't know if Xorg can handle it yet, I haven't used Hardened Gentoo since Ubuntu hit the map.
(Log in to post comments)
Prelink and address space randomization Posted Jul 13, 2006 21:03 UTC (Thu) by roelofs (guest, #2599) [Link] - 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
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.
|
|||||||||||||