Windows 7/8 ASLR - Not so Much

This commentary is based on the work published and performed by "Kingcope". The original text and PoCs are located here: http://kingcope.wordpress.com/2013/01/24/attacking-the-windows-78-address-space-randomization/

The inclusion of memory protections in Windows 7 (and now Windows 8) was touted as a means to defeat exploitation attempts by:

1) Preventing code execution on the stack [DEP]
2) Randomizing the memory offsets of Programs (and associated DLLs) [ASLR].

While bypassing DEP has been relatively well documented by multiple sources in numerous locations [see: ROP Chains], ASLR has proven a tougher nut to crack. Randomization of the memory space forces an exploit writer to try and predict where in memory to point an instruction pointer that he or she has gained control over. The goal being, of course, to point to an area of memory which contains the writer's arbitrary code.

Current methods for "beating" ASLR include: utilizing browser memory leak bugs or relying on older DLLs that do not have their image bases randomized. Unfortunately, knowledge of a particular memory leak or reliance on outdated third party software are niche* scenarios culminating in the creation of an idyllic attack surface.

That's where Kingcope's research comes in!

The theory presented is fairly simple: DLLs are loaded into memory space as long as there is space available. If no memory (or very little) is availble, the DLL will be put into the remaining memory. But how does an attacker create a situation in which there is no or minimal (and thus predictable!) memory available in which to load a DLL? By utilizing JavaScript in a target's browser to fill memory to the allocated boundary.** When the allocated boundary is hit, a JavaScript exception is raised which causes the exception handler to execute additional code that frees small chunks of memory. The goal is to slowly free small heap blocks and try to add the DLL(s) into memory; when the DLL is successfully loaded, the region (address space) is fixed and predictable, allowing an exploit writer to point an instruction pointer at a fixed location on the heap.

In his example, Kingcope utilizes the Windows Media Player control ActiveX object to illustrate how the previously described method of abusing JavaScript's exception handler can be used to load a DLL into predictable address space.

Now that the selected DLL (The Windows Media Player DLLs, to continue the example) are loaded into a predictable address, execution of shellcode is only an ROP chain away! I won't spoil the rest of the example Kingcope provided [Hint: LoadLibrary API], but suffice to say it is relatively simple to construct an ROP chain by which to execute arbitrary code following a heap spray.

Click the link to view a quick graphic summary.

*Perhaps not so much in the case of Java.
**One drawback to this proposed technique is that filling memory in this way will cause Windows to become unresponsive until the selected DLL is loaded and memory is freed by an attacker's JavaScript.