Metasploit mailing list archives
linux 2.6 stack randomization
From: mmiller at hick.org (mmiller at hick.org)
Date: Sat, 17 Dec 2005 10:55:13 -0600
On Sat, Dec 17, 2005 at 01:55:46PM +0100, Sebastiaan Veenstra wrote:
Hi, I've read a bit about some patches today introducing stack randomization into the 2.6 kernel. With these patches, a stack overflowable buffer is located on a different memory address for each invocation of the vulnarable program. Thus, storing shellcode in a stack overflowable buffer and overwriting the return address with the address of the buffer is no longer possible since the buffer is stored on a completely different stack address among subsequent invocations of the program. Even by utilizing a nop sled it's not possible. How does the metasploit framework anticipate to this kind of behavior? Are there any facilities in the new framework to automate the exploitation process in such a situation?
Stack randomization does not matter unless the entire address space is randomized. If only partial randomization is implemented, the best you get is a reduction in return address surface for the exploit. You can still return into predictable regions of memory that happen to contain useful opcodes (text segments, memory mappings, heap, etc), although on Linux you tend to lose portability quickly for certain types of regions, like text segments. There have been papers outling how to take advantage of the new vsyscall mapping for exploitation, so that is another option as well. In general, this isn't really the job of the framework to solve at this point, although we're working on some generalizations that could be applied to make it useful to this kind of situation (such as the return address pooling stuff we will be introducing in a future version).
Current thread:
- linux 2.6 stack randomization Sebastiaan Veenstra (Dec 17)
- linux 2.6 stack randomization mmiller at hick.org (Dec 17)
- linux 2.6 stack randomization Tim (Dec 17)
- linux 2.6 stack randomization mmiller at hick.org (Dec 17)