Timeline for ASLR does not seem to randomize text section
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 30, 2017 at 13:06 | comment | added | Polynomial | I'm not sure this answer is strictly correct, at least not any more. By default a Linux kernel with ASLR support will not relocate .text, but it will do if the executable is compiled as position independent with -fPIE. | |
| Oct 14, 2014 at 7:33 | comment | added | Chocosup | And regarding dynamic libraries ? Are their virtual loading addresses randomized ? Because while you would have to look "manually" into assembler dump to find ROP gadgets in the dev's code, if you can access the glibc functions then you may already know where to look for each gadget, right ? Also, I tested this on windows with visual c++, and it seems to randomize all segments. It is hard to believe for me that windows may be ahead of linux in terms of security, but maybe it's just prejudice... | |
| Oct 14, 2014 at 7:25 | vote | accept | Chocosup | ||
| Oct 13, 2014 at 16:32 | comment | added | rook | @Chocosup In most cases you have to overcome both ASLR and NX zones in a ROP chain, which can be done. A reasonably complex application will have small ROP gadgets that can do nasty things when put together, but I can see how this wasn't obvious before attackers develops ROP chains. Chicken or the egg I suppose, maybe in the future the Text segment will be ASLRed. | |
| Oct 13, 2014 at 15:01 | comment | added | Chocosup | Thank you. I actually knew about ROP, but what I thought was that code injection was prevented by DEP, which was bypassed by ROP, which was countered by ASLR. Actually I don't really see how the assumption that the code is safe could be well founded, as if there is no flaw in the code you don't need protections anyway. Or am I wrong ? | |
| Oct 13, 2014 at 14:40 | history | answered | rook | CC BY-SA 3.0 |