RE: "Moving" Stack: my poor return address!

[<salexander () frontporch com>]

More advanced techniques such as return-into-libc are an option but
stack-based attacks can still work because stack randomization can be
defeated (eventually).  

Stack randomization changes the base of the stack.  It doesn't change
the relative location of a saved instruction pointer or function pointer
on the stack.  This means that you can can still overwrite a saved
instruction pointer, you just don't know what to change it to.

The first thing you need to do is find out how much randomization is
applied to the stack base.  Pretend for a moment that a random 16-bit
number is chosen, shifted left two bits (for word alignment) and added
to the stack base.  You now have only a 1 in 65,536 chance of
redirecting an instruction pointer so that it points to some shellcode
you've placed on the stack.  That would be a problem but you can place a
NOP or JMP sled at the front of your shellcode.  If you're not familiar,
a NOP sled is a buffer of No-Operation instruction prepended to your
shellcode.  If the saved instruction pointer points to any location in
the NOP sled, execution will proceed through the sled and into your
shellcode.  A JMP sled serves the same purpose but uses relative JMP
instructions instead; they are useful if there is a chance that the sled
will get corrupted before the saved instruction pointer is popped and
used.  Suppose you can prepend a 1k NOP sled to your shellcode.  With
16-bits of stack randomization, you now have a 1 in 256 chance of
executing your shellcode (you lose a factor of four to word alignment).
For a local SUID program or a remote service that is automatically
restarted, a 1 in 256 chance is easy to work with.  Your chances
increase if you can add a larger sled or insert your payload in multiple
locations.  

Memory randomization of any sort is an imperfect solution (not that I'm
claiming to have a perfect one).  In theory you can simply try an
exploit over and over until you manage to hit your payload; in practice
you may not have enough time to make a 16 million attempts.  Injecting
multiple payloads and using NOP sleds greatly improves your chances of
success.  Format string exploits that allow you to read stack values can
help you to defeat memory randomization entirely.

For more info:
https://engineering.purdue.edu/ResearchGroups/SmashGuard/BoF.html

-Steven





 

-----Original Message-----
From: list-recv () crepinc com [mailto:list-recv () crepinc com] 
Sent: Wednesday, August 02, 2006 6:41 AM
To: vuln-dev () securityfocus com
Subject: Re: "Moving" Stack: my poor return address!

Thanks all for letting me know about stack randomization.

So is it safe to say that "traditional" stack-based exploits such as in
my origianl post are a thing of the past, and current exploit developers
use methods like returning into libc to get a shell / etc?

Thanks again,

-Jack Carrozzo
jack   _{@}_   crepinc.com