The size of the shellcode is 242 bytes (add 5 for stack alignment and 39 for EAT bypass). It has all the usual bells and whistles: OS/SP independent, null-free, optional stack alignment and EAT bypass and no register requires a specific value for it to run correctly.

Get the code here.

In early September this year Microsoft released their Enhanced Mitigation Experience Toolkit v2.0 (EMET), which includes a new “pseudo”-mitigation called Export address table Address Filter (EAF). I decided to have a look at how this mitigation attempts to prevent exploits from succeeding and how an attacker might bypass it. For people that suffer from tl;dr syndrome, I’ve put my conclusion up front:

It is my conclusion that EAF should be effective at preventing most current shellcode from executing and therefore a useful mitigation. However, it is relatively simple to bypass. Proof of concept code to do this can be found here. I expect that if EAF becomes a common mitigation, attackers will update their shellcodes to bypass it. I cannot think of any effective way in which EAF can be updated that would not be relatively simple to bypass as well.

EAF works by setting a hardware breakpoint on the export address tables of the ntdll.dll and kernel32.dll modules in a process. When the breakpoint is triggered, EAF determines if the code that is trying to access the export address table is valid code for that process or malicious code injected into the process through an exploit. Most exploits will at some point inject and run shellcode into the target process. One of the first thing most shellcodes do is determine where certain functions are loaded in memory. This is commonly and easiest done by going through the list of loaded modules and reading their export address tables. When shellcode reads the export address tables of ntdll.dll and/or kernel32.dll, EAF detects the shellcode and terminates the process, preventing the exploit from running successfully.

I tested EAF withone of my shellcodes that shows a message in a popup window when it runs successfully. All my shellcodes scan the export address tables of loaded modules to find certain functions. This is a common technique used by almost all shellcodes that EAF is designed to detect. So, enabling EAF should prevent my shellcode, and most others, from working.

I use testival to test my shellcode because it makes things easy to automate and I can copy+paste the output into this blog to show you what is going on. When my shellcode is run, it shows a popup dialog box and then triggers an int3 debugger breakpoint. Here’s the output of w32-testival.exe for a successful run of my shellcode:

C:\Dev\Shellcode\w32-msgbox-shellcode>w32-testival [$]=ascii:w32-msgbox-shellcode.bin eip=$ --verbose --eh --eh
Allocating 0x1000 bytes of memory... ok. (address: 0x00030000)
Setting data and registers:
[0x00030000] = 8C bytes of data.
eax = 0xDEADBEEF (default)
ecx = 0xDEADBEEF (default)
edx = 0xDEADBEEF (default)
ebx = 0xDEADBEEF (default)
esp = ??? (unmodified)
ebp = 0xDEADBEEF (default)
esi = 0xDEADBEEF (default)
edi = 0xDEADBEEF (default)
eip = 0x00030000 ($)
Registering Structured Exception Handler (SEH)...ok.
Registering Vectored Exception Handler (VEH)...ok.
Executing shellcode by jumping to 0x00030000...First chance debugger breakpoint exception at 0x0003008B.
Second chance debugger breakpoint exception at 0x0003008B.
 
C:\Dev\Shellcode\w32-msgbox-shellcode>
 

Of course, you cannot see the popup dialog box in this output, but you can see that the int3 debugger breakpoint at the end of the shellcode was executed. This means that it ran successfully.

After enabling EAF I tried executing the shellcode again and found that it still worked. So either EAF was not working or I was doing something wrong. I contacted my friends at MS who developed the tool and asked them to help me find out what was going on. They explained that in order to install the EAF mitigation, EMET needs to create a new thread in the process first, which means the mitigation is not enabled immediately on startup. To make sure that the mitigation is installed, you need to wait a bit before running your shellcode. So, I added a new switch to testival that allows it to wait a given number of milliseconds before executing the shellcode. Using this new feature, I tried again and this time EAF successfully blocked my shellcode, as you can see here:


C:\Dev\Shellcode\w32-msgbox-shellcode>w32-testival [$]=ascii:w32-msgbox-shellcode.bin eip=$ --verbose --eh --eh --delay=1000
Allocating 0x1000 bytes of memory... ok. (address: 0x00030000)
Setting data and registers:
[0x00030000] = 8C bytes of data.
eax = 0xDEADBEEF (default)
ecx = 0xDEADBEEF (default)
edx = 0xDEADBEEF (default)
ebx = 0xDEADBEEF (default)
esp = ??? (unmodified)
ebp = 0xDEADBEEF (default)
esi = 0xDEADBEEF (default)
edi = 0xDEADBEEF (default)
eip = 0x00030000 ($)
Registering Structured Exception Handler (SEH)...ok.
Registering Vectored Exception Handler (VEH)...ok.
Waiting for 1000 milliseconds...ok.
Executing shellcode by jumping to 0x00030000...First chance single step exception at 0x00030054: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
Second chance exception 0xC0000409 at 0x00030054.
 
C:\Dev\Shellcode\w32-msgbox-shellcode>
 

This time the process is terminated early by a single step exception. This is because the EAF mitigation has detect that the shellcode accessed the export address table and decided to terminate the application rather than allow the shellcode to continue executing. This shows that EAF should be able to detect and protect against exploits that use most common shellcode.

I decided not to reverse EAF in order to find out how it works, but rather try to guess how it works and guess how it might by bypassed and try if it works. I assumed that EAF works by checking the location of the instruction that is accessing the export address table: if it is located inside the code segment of a loaded module, EAF assumes it is valid code and allowed it to continue. Otherwise, EAF assumes it is malicious code and terminates the process. If my hypothesis is correct, it might be possible to have the shellcode use a sequence of instructions inside the code segment of a loaded module that can be used to read memory. Because in this case, EAF will assumes that valid code is attempting to read the export address table rather than my shellcode and allow the code to continue.

To test this, I created a modified version of my shellcode that works like this:

• First, the shellcode finds out where ntdll.dll is loaded in memory as usual.
• Second, it finds out where the code segment for ntdll.dll is located.
• Third, it scans the code segment for a specific instruction sequence that can be used to read arbitrary memory.
• Finally, it calls this instruction sequence to read the export address table, rather than read it directly.

This is effectively the same as doing a ret-into-libc attack, something which EAF is not designed to block and this should therefore be able to bypass it. It turns out that the RtlGetCurrentPeb function has a useful instruction sequence. This sequence is static across Windows versions and SPs and exactly 4 bytes long, which means it is easy to write code to find it:

ntdll32!RtlGetCurrentPeb:
64a118000000 mov eax,dword ptr fs:[00000018h]
8b4030 mov eax,dword ptr [eax+30h]
c3 ret
 

By setting EAX to the memory address you want to read (minus 0×30) and calling the second instruction, you can read arbitrary memory into EAX.

The first time I tested my code, it was blocked by EAF while scanning for the instruction sequence in the code segment. It turns out that the export address table is located at the start of the code segment of ntdll.dll, so my scan for the instruction sequence was accessing it and triggering EAF. Luckily, the RtlGetCurrentPeb function is not located anywhere near the start of the code segment in any version of ntdll.dll, so it was relatively easy to avoid this by skipping over the first 0×1000 bytes of the code segment.

Here is the result for my modified shellcode, which is only 30 bytes larger than the original:

C:\Dev\Shellcode\w32-msgbox-shellcode>w32-testival [$]=ascii:w32-msgbox-shellcode-eaf.bin eip=$ --verbose --eh --eh --delay=1000
Allocating 0x1000 bytes of memory... ok. (address: 0x00030000)
Setting data and registers:
[0x00030000] = AB bytes of data.
eax = 0xDEADBEEF (default)
ecx = 0xDEADBEEF (default)
edx = 0xDEADBEEF (default)
ebx = 0xDEADBEEF (default)
esp = ??? (unmodified)
ebp = 0xDEADBEEF (default)
esi = 0xDEADBEEF (default)
edi = 0xDEADBEEF (default)
eip = 0x00030000 ($)
Registering Structured Exception Handler (SEH)...ok.
Registering Vectored Exception Handler (VEH)...ok.
Waiting for 1000 milliseconds...ok.
Executing shellcode by jumping to 0x00030000...First chance single step exception at 0x76FBA045: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
First chance single step exception at 0x76FAFFCE: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
First chance single step exception at 0x76FAFFCE: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
First chance single step exception at 0x76FAFFCE: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
<snip>(Many more single step exceptions)<snip>
First chance single step exception at 0x76FAFFCE: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
First chance debugger breakpoint exception at 0x000300AA.
Second chance debugger breakpoint exception at 0x000300AA.
 
C:\Dev\Shellcode\w32-msgbox-shellcode>
 

Every time the export address table is accessed, the hardware breakpoint is triggered and EAF checks to see if shellcode is attempting to access it. This is why you are seeing so may first change single step exceptions. However, because I am using the instruction sequence in ntdll.dll to access the address table, EAF allows the code to continue. The shellcode runs successfully and the process terminates when the shellcode executes the int3 debugger breakpoint as before.

Have a look at the changes I made to my shellcode to make this work. They are relatively minor and it should be possible to apply this technique to any shellcode, which reduces the usefulness of EAF in the long run.

I thought about possibilities to prevent or detect this bypass. Unfortunately, I could not think of anything that would be effective. Here are some of my ideas and why I think they won’t work:
- EAF could check for this specific instruction sequence. However, shellcode could scan for other sequences in ntdll.dll (or even in other modules) that can be used to achieve the same.
- EAF could “walk the stack” and check that all return addresses are valid. However, the shellcode could construct a ret-into-libc stack with only valid return addresses, where the first call reads the export address table and the next call modifies the return address for the third return address to point to the shellcode again.
- EAF could set additional hardware breakpoints on structures that can be used to find the locations of modules, in an attempt to prevent the shellcode from finding an instruction sequence that it can use to read memory. However, there are a large number of ways in which the location of modules can be found and there are a limited number of hardware breakpoints. There are not enough breakpoints available to protect all of locations that contain sensitive data.

I welcome your thoughts and ideas on this subject.

Oracle have released a fix for this issue, which can be found here.

Details can be found here.

Oracle have released a patch for this issue which can be found here.

More details can be found here.

The buffer overflow allows easy control over EIP and creating a working exploit for targets without DEP is as easy as copy+pasting a heap spray into the repro file.

I reported the issue to Oracle, who were already aware of the issue because it had also been reported to them by Stephen Fewer of Harmony Security through ZDI. Oracle has release a patch for this issue, which is available here.

More details can be found here.

Microsoft has release a fix for this issue here.

More details can be found here.

I hacked the code together in 30 minutes based on my calc.exe shellcode, so it can probably be optimized a bit more. I haven’t tested it thoroughly, but it works on Windows 7 for me.

I haven’t got as much time as I used to to write exploits for bugs I find, but when I write exploits, I usually do so in incremental steps: I first create a simple version that ignores ASLR/DEP and I make sure that works with ASLR/DEP disabled. I then add the code that uses ret-into-libc to bypass DEP, and provide it with the exact location of VirtualProtect to make sure that works as well before I add the code that automatically determines the location of VirtualProtect to bypass ASLR. Because I have ASLR enabled on most of my systems, I created a simple tool to extract its current location:


C:\Sample>type vp.c
#define WINVER 0x0500
#define _WIN32_WINNT 0x0500
#include <windows.h>
int main(int argc, char** argv) {
HMODULE hModule = 0;
FARPROC pFunction = 0;
if (argc < 2 || argc > 3) {
printf("Usage:\r\n %s module_name [function_name]\r\n", argv[0]);
} else {
hModule = LoadLibraryEx(argv[1], NULL, DONT_RESOLVE_DLL_REFERENCES);
if (!hModule) {
printf("Module not found!\r\n");
} else {
printf("Module base : %08X\r\n", (UINT)hModule);
if (argc == 3) {
pFunction = GetProcAddress(hModule, argv[2]);
if (!pFunction) {
printf("Function not found!\r\n");
} else {
printf("Function offset : %+8X\r\n", (UINT)pFunction - (UINT)hModule);
}
}
}
}
}
 
C:\Sample>build
== Sample ==
@ Generating build configuration.
@ Version 0.1 alpha, build 1, started at Fri, 03 Sep 2010 07:55:45 (UTC)
[Sample]
+ Build: vp.obj
+ Build: vp.exe
- Cleanup: vp.ilk
- Cleanup: vp.obj
@ Project built successfully.
@ Build successful.
 
C:\Sample>vp %SystemRoot%\system32\kernel32.dll
Module base : 77000000
 
C:\Sample>vp %SystemRoot%\system32\kernel32.dll VirtualProtect
Module base : 77000000
Function offset : 134EC
 
C:\Sample>
 

As you can see, both times I ran the tool, the base address of kernel32.dll was the same. This is because ASLR is only re-randomized at boot time, so until you reboot your machine, you can hard-code the value obtained this way into your exploit.

So, how random is the base address of kernel32.dll in real life? One way to find out is to set up a Windows machine to automatically run a script at startup that extracts the base address of kernel32.dll using the code above and then reboots. If you let this run for a while, you get a number of different values. Here’s a script I created to do just that:


@ECHO OFF
vp.exe "%SystemRoot%\system32\kernel32.dll" >> %COMPUTERNAME%.txt
IF EXIST continue.txt (
shutdown.exe -r -t 0
)
 

In addition to logging the base address of kernel32.dll in a file named after the machine it is running on, and rebooting the machine, it also checks for the existence of a file called “continue.txt”. That way, I can stop the machine from continuously rebooting by deleting that file (the script is loaded of a network share, so I can access the file from another machine). I used the “CONTROL USERPASSWORDS2″ configuration panel to tell Windows to automatically log in as a local user account at startup, and put the script in the “startup” folder of that local user.

After running for a while on a 32-bit Vista sp2 en-us virtual machine, I used the following Python script to extract some useful data from the information I gathered:


if __name__ == "__main__":
import sys;
file = open(sys.argv[1], 'rb');
try:
data = file.read();
finally:
file.close();
base_addresses_counts = {};
results_count = 0;
for line in data.split('\r\n'):
if not line:
continue;
results_count += 1;
base_address = int(line[18:], 16);
if base_address not in base_addresses_counts:
base_addresses_counts[base_address] = 1;
else:
base_addresses_counts[base_address] += 1;
base_addresses = base_addresses_counts.keys();
base_addresses.sort();
lowest_base_address = base_addresses[0];
highest_base_address = base_addresses[-1];
smallest_delta = highest_base_address - lowest_base_address;
previous_base_address = None;
print ' Base | Offset | Delta | Count ';
print '-------------|-------------|-------------|--------------';
for base_address in base_addresses:
offset = base_address - lowest_base_address;
if previous_base_address is not None:
delta = base_address - previous_base_address;
if delta < smallest_delta:
smallest_delta = delta;
else:
delta = 0;
print ' %11s | %11s | %11s | %d' % ( \
'0x%08X' % base_address, '+0x%X' % offset, '+0x%X' % delta, \
base_addresses_counts[base_address]);
previous_base_address = base_address;
print '-------------\'-------------\'-------------\'--------------';
print ' Total runs: %d' % results_count;
print ' Total different values: %d' % len(base_addresses);
print ' Smallest delta: 0x%X' % smallest_delta;
print ' Total possible values: >= %(v)d (%(v)X)' % {'v': offset / smallest_delta};
 


Here’s part of the output of this script:

C:\Sample>analyze.py VM3-V32SP2-N.txt
Base | Offset | Delta | Count
-------------|-------------|-------------|--------------
0x75490000 | +0x0 | +0x0 | 1
0x75550000 | +0xC0000 | +0xC0000 | 1
0x75580000 | +0xF0000 | +0x30000 | 1
0x755A0000 | +0x110000 | +0x20000 | 2
<snip>
0x77E40000 | +0x29B0000 | +0x40000 | 1
0x77E80000 | +0x29F0000 | +0x40000 | 1
0x77EB0000 | +0x2A20000 | +0x30000 | 1
0x77ED0000 | +0x2A40000 | +0x20000 | 2
-------------'-------------'-------------'--------------
Total runs: 807
Total different values: 460
Smallest delta: 0x10000
Total possible values: >= 676 (2A4)
 
C:\Sample>


To clarify: the machine was rebooted to collect another base address 806 times, yielding 807 base addresses. The base addresses were distributed among 460 different values, some values occurring more than once. Because of the number of the tests I performed and the randomness at which the addresses get chosen, it is to be expected that some values occur more often than others and that some values do not occur at all. Based on the lowest and highest value (07549000 and 077ED0000) and the smallest difference between two addresses (10000), I calculate that there are at least 676 different possible values for the base address.

I was a bit surprised by the results. I haven’t kept up-to-date with ASLR randomness, but IIRC it was 8-bits (256 possible values) last time I checked. Microsoft appears to have increased the randomness of their ASLR implementation in Vista. This makes a brute force attack against ASLR, in which you try all possible values until you find the right one, take longer. This also decreases the chances of success for an attacker that only has one try at guessing the address: a 1/256 chance is bad, a 1/676 chance is worse.

Should you decide to run a similar test, let me know what OS you tested and what values you found!

Case details can be found here.

http://code.google.com/p/jssfx/