Vulnerability Development mailing list archives
RE: "Moving" Stack: my poor return address!
From: <salexander () frontporch com>
Date: Wed, 2 Aug 2006 15:10:52 -0700
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
Current thread:
- "Moving" Stack: my poor return address! Jack C (Aug 01)
- Re: "Moving" Stack: my poor return address! Andrea Purificato - bunker (Aug 02)
- Re: "Moving" Stack: my poor return address! Alexander Klimov (Aug 02)
- Re: "Moving" Stack: my poor return address! Steve Bonds (Aug 02)
- Re: "Moving" Stack: my poor return address! Jon Erickson (Aug 02)
- <Possible follow-ups>
- Re: "Moving" Stack: my poor return address! list-recv (Aug 02)
- RE: "Moving" Stack: my poor return address! salexander (Aug 02)
- Re: "Moving" Stack: my poor return address! Javor Ninov (Aug 29)