Data execution prevention (DEP)

In the previous section we briefly discussed the article, “Smashing the Stack for Fun and Profit”, where hacker, Aleph One, described how to exploit stack buffer overflow vulnerabilities, executing shellcode injected into a process’s stack segment. The viability of the techniques described in this article relied upon the fact that, at the time of its writing, there was no delineation between code and data for the memory segments of a process. [1] After a significant proliferation of computer worms [2][3] using these techniques occurred, operating system designers and engineers began to implement the W^X memory protection policy for process memory pages in an attempt to mitigate exploitation.

What is W^X?

W^X (write xor execute) is the idea that memory should be writeable or executable, but not both. Enforcement of this policy creates a delineation between code and data within process memory, code being r-x and data being rw-. Now when an attempt is made to execute machine code in a rw- segment, an exception is raised. [4]

What is NX?

The NX (No eXecute) bit is a hardware feature that, in conjuction with operating system software, can be used to segregate memory pages into code segments and data segments, enforcing the W^X memory protection policy. [5] While most modern processor architectures support the NX bit, earlier implementations did not support this feature - kernel patches like PaX [6] and Exec Shield [7] were designed to emulate NX bit functionality.

What is DEP?

DEP (Data Exeuction Prevention) is Microsoft’s implementation of the NX functionality on Windows operating systems. [8] Windows also implements a software DEP feature that avoids the use of the NX bit called SafeSEH (Safe Structured Exception Handling). [9] If a process raises an exception, SafeSEH enforces an integrity check of the stored exception handler, checking the exception handler against the one that was originally present when the application was compiled. This prevents an attacker from modifying the exception handler and intentionally raising an exeception to hijack control of the process.

Breaking W^X

As mentioned in the previous section, Solar Designer published the article, “Getting around the non-executable stack, (and fix)”, detailing how to conduct a ret2libc attack. The attack involves conducting a stack buffer overflow to hijack the control flow of the process, however, instead of jumping into the stack to execute shellcode, the attacker returns into libc’s system() symbol. This method defeats the W^X memory protection policy because control flow is redirected to a segment of memory that is r-x. An exception will not be rasied when the instructions of libc’s system() are executed. [10]

Return oriented programming takes this a step further. Utilizing the stack pointer as an artificial program counter, an attacker places words on the stack that point to valid instruction sequences within process memory (ROP gadgets). ROP gadgets reside within a section of memory that is labeled as code (r-x) - usually in libc. A sufficient number of ROP gadgets provides Turing complete functionality for an attacker, allowing them to compute anything necessary to exploit a vulnerable application.

Another surface presenting a method to bypass W^X is Just-In-Time (JIT) compilation. JIT compilation involves compiling code at runtime before executing it, usually supported by applications like browsers in order to implement things like JavaScript engines. Sometimes, the memory pages created by browsers to store and execute JIT compiled code don’t enforce the W^X memory protection policy. This has been used by attackers to execute a technique known as JIT spraying. JIT spraying involves the injection of malicious code into rwx pages of an application that supports JIT compilation. With a viable method to hijack the control flow of the application and a sensitive information leak, the attacker returns into the sprayed memory page to gain arbitrary code execution. [11]

Related pages

• ASLR

References

1. http://phrack.org/issues/49/14.html
2. https://en.wikipedia.org/wiki/Sasser_(computer_worm)
3. https://en.wikipedia.org/wiki/Blaster_(computer_worm)
4. https://en.wikipedia.org/wiki/W%5EX
5. https://en.wikipedia.org/wiki/NX_bit
6. https://pax.grsecurity.net/docs/segmexec.txt
7. https://lwn.net/Articles/31032/
8. https://docs.microsoft.com/en-us/windows/win32/memory/data-execution-prevention
9. https://docs.microsoft.com/en-us/cpp/build/reference/safeseh-image-has-safe-exception-handlers?view=vs-2019
10. https://seclists.org/bugtraq/1997/Aug/63
11. http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Slides-v2.pdf