Difference between revisions of "DEP"
GertieUbpgdd (Talk | contribs) |
GertieUbpgdd (Talk | contribs) |
||
| Line 26: | Line 26: | ||
[[Category:Buffer Overflows]] | [[Category:Buffer Overflows]] | ||
| + | |||
| + | {{countermeasures}} | ||
Revision as of 01:00, 16 May 2012
Data Execution Prevention.
Microsoft's Windows XP SP2 Operating System was Microsoft's first real attempt at data execution prevention. While the attempt was in fact a feeble one, it laid the ground work for later innovations, for example ASLR, or Address Space Layout Randomization employed by Microsoft's Windows Vista Operating System.
Windows XP Service Pack 2 will not allow a ret instruction to return to a location inside of a data or bss segment. Needless to say, this is an improvement however is not a sure-fire fix. For example, say we have found a stack overflow that allows us not only to overwrite the return address for the function, but also allows us to overwrite the value of the eax register. While the return pointer cannot be set to a location within the buffer, the return pointer CAN be set to the location of a jmp eax instruction. So if we put the location of our code in the overwritten eax register and then the location of jmp eax into the return pointer, we have successfully bypassed Windows XP Service Pack 2's data execution prevention system. Some good memory addresses from research can be found as follows :
Windows XP Service Pack 2 Professional English Edition
ntdll.dll: Mem Address Instruction 0x7c9556d8 jmp eax 0x7c901231 ret 0x7c90eac5 call eax 0x7c93ee57 call ebx 0x7c9037bd call ecx 0x7c961819 call edi
kernel32.dll: Mem Address Instruction 0x7c8106f8 jmp ecx
Magic Numbers and ASLR
I'm sure that this list will be constantly updated and/or rewritten as versions and the years go by. This is the simple DEP bypass for Windows XP SP2. As mentioned before, Windows Vista employs something called Address Space Layout Randomization. To bypass this runtime data execution prevention, one must overwrite what is called the SEH frame, or the Structured Exception Handler frame. This frame is located near the bottom of the stack and is used to define whether the application uses windows' exception handler or if the application has its own exception handler. Generally speaking, exploitation is much more successful when the attacker writes his or her own exception handler for the vulnerable application. An overwritten exception handler allows for what is called a "magic number attack", or an attack where the attacker no longer needs to know the location of his shellcode, in stead the attacker uses the exception handler to find out the location and jump to it during the exception handling execution cycle, not only bypassing data execution prevention but also making his or her exploitation cross-version compatible as no absolute pointers are needed for this type of exploitation.
