Data Execution Prevention (DEP)/NX
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]
References
- http://phrack.org/issues/49/14.html
- https://en.wikipedia.org/wiki/Sasser_(computer_worm)
- https://en.wikipedia.org/wiki/Blaster_(computer_worm)
- https://en.wikipedia.org/wiki/W%5EX
- https://en.wikipedia.org/wiki/NX_bit
- https://pax.grsecurity.net/docs/segmexec.txt
- https://lwn.net/Articles/31032/
- https://docs.microsoft.com/en-us/windows/win32/memory/data-execution-prevention
- https://docs.microsoft.com/en-us/cpp/build/reference/safeseh-image-has-safe-exception-handlers?view=vs-2019
- https://seclists.org/bugtraq/1997/Aug/63
- http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Slides-v2.pdf