ROP to the Rescue
In the last section we discovered that SMEP prevented us from calling user mode code from the kernel. To defeat this we need to disable it using ROP.
Last updated
In the last section we discovered that SMEP prevented us from calling user mode code from the kernel. To defeat this we need to disable it using ROP.
Last updated
Data Execution Prevention (DEP) was introduced in the Windows operating system starting from Windows XP Service Pack 2 (SP2). DEP is a security feature that helps protect against certain types of malicious code execution by marking memory regions as non-executable unless explicitly allowed. This is enabled in kernel space, so in order to defeat SMEP we first need to defeat DEP, and we will soon find out kASLR too!
Supervisor Mode Execution Protection (SMEP) is a security feature that leverages the 20th bit of the Control Register 4 (CR4) in x86 processors. When the SMEP bit is enabled by setting it in cr4, it prevents the processor from executing user mode code in kernel mode.
At any point during kernel debugging we can view the cr4 register:
From the output we can see that 20th bit (using a zero index) from the right is set to 1. If we take the rightmost (least-significant) three bytes we can do some very simple binary maths:
Removing the 20th bit (the SMEP flag) can also be easily calculated:
Effectively, we need to set the cr4 register value to 0x506f8 to disable SMEP.
We have manually carried out the following calculation; this calculates a new cr4 register value with the 20th bit set to 0:
We can carry out this calculation in Windbg Preview:
This can be useful if the value in cr4 is different to what we have here.
In order to disable SMEP we need to find ROP gadgets that carry out the following, or similar:
This doesn't seem too much of a daunting task.
Note: The following assembly would be more portable, but unfortunately the gadgets do not exist:
ntoskrnl.exe is a core system file in the Windows operating system that contains the kernel code, providing essential services and functionality for the operating system.
The ntoskrnl.exe file is responsible for managing memory, processes, drivers, and various system components. It acts as the interface between the hardware and software layers, handling system calls, managing resources, and maintaining overall system stability and security.
We will use rp-win by 0vercl0k to find ROP gadgets in ntoskrnl.exe to help us defeat DEP in the kernel.
Locate C:\Windows\System32\ntoskrnl.exe and copy it to convenient location.
Use the following command in a new command prompt to search for gadgets in the kernel code:
When the command is completed we can open the ntoskrnl.txt file to look for appropriate ROP gadgets:
You may notice that the addresses are prefixed with 0x140, this is not a true address, but an offset of 0x140000000. We can use the debugger to test this theory.
If we take a random gadget (make it an easy one to compare) we can check this against the nt module in the debugger:
If we remove the prefix from the gadget address, and check the loaded module in the debugger we find that the gadget address is an offset of the loaded module base address (without the prefix):
Searching through the gadget file we can locate gadgets to disable SMEP, run our shellcode then restore SMEP; the following ROP chain is constructed:
We can use the connected debugger to check that our gadgets point to the correct assembly, the first gadget is shown below:
The second gadget is also checked:
Now we have the gadget offsets we can start thinking about putting this in to our exploit. However, we need to defeat kASLR. That is discussed next.
Work in progress
See if you can find other ROP gadgets to meet the objective.
