linux 2.6 stack randomization

[mmiller at hick.org (mmiller at hick.org)]

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).