Didier Stevens

I’ve written about Shell Extension without ASLR support before.

Not only do they open up explorer.exe to ROP attacks, but other applications too, like Adobe Reader and Microsoft Office.

You could use EMET to force ASLR on these DLLs, assuming you know which applications load shell extensions. Because shell extensions are not only loaded into explorer.exe, but other programs too, I wrote a tool to force Shell Extension DLLs to load at another address than their base address, effectively simulating ASLR.

When my tool, SE_ASLR.dll, is loaded into a process, it will check for the presence of comdlg32.dll inside the list of loaded modules. When comdlg32.dll is used by an application, the likelihood of shell extensions being loaded into the process by user interaction with the file dialogs is significant.

Hence SE_ASLR will patch the IAT to intercept calls to LdrLoadDll. Each time the application loads a DLL (all DLLs, not only shell extension), SE_ASLR will check if the DLL supports ASLR. If it doesn’t, SE_ASLR will pre-allocate a memory page at the base address of the DLL, thereby forcing the loader to load the DLL at another address.

Although SE_ASLR’s primary goal is to relocate shell extensions, it will effectively relocate all DLLs without ASLR support once SE_ASLR is loaded into the process.

You need to load my tool into all applications that could use shell extension, for example via the AppInit_DLLs registry key. But before you do, be sure to test this out on a test machine. Not all shell extensions support relocation.

SE_ASLR_V0_0_0_1.zip (https)
MD5: 9D6AE1A96D554AEE527EB802FE59FB20
SHA256: 8A6C1406A757CD9788A2630D76A497E2C058333EE4D44CA0B85B2A05A39F257E

Just like EMET, HeapLocker can allocate a page at address 0 (null or 0x00000000) to mitigate null pointer dereferencing.

I actually implemented this code in HeapLocker because I wanted to find out how one can allocate a page at address 0. You see, when you call VirtualAlloc with address 0, VirtualAlloc will allocate a page at an address chosen by VirtualAlloc, and not at address 0. So I would think that the trick is to call VirtualAlloc with address 1, and that VirtualAlloc will allocate a page that contains address 1, and that this page must start at boundary 0.

But the problem is that you get an error when you try to allocate a page at address 1 with VirtualAlloc. Ivanlef0u explains this in his blogpost (French). VirtualAlloc rejects addresses inferior to 0x1000, one must use NtAllocateVirtualMemory to successfully allocate address 1.

A third protection technique I implemented in HeapLocker is string detection.

When you enable string monitoring, HeapLocker will create a new thread to periodically check (every second) newly committed virtual pages that are readable and writable. When a specific string (configured in the registry) is detected inside these pages, HeapLocker will suspend all threads (except this monitoring thread used by HeapLocker) and warn the user that the string was detected.

I’ve had very good result with this technique searching for string “unescape” in Adobe Reader (the string “unescape” must be preceded by an equal sign or followed by a left parentheses). Almost all malicious PDF documents in my collection were detected by this. But like NOP-sled detection, it’s not 100% reliable. Sometimes HeapLocker will scan a page before the string “unescape” has been written to that page.