'Bypassing ASLR and DEP on Adobe Reader X'

From Heise Online, posting on "Bypassing ASLR and DEP on Adobe Reader X, blog post by Guillaume Delugré from Sogeti ESEC Lab."

'Adobe Reader X runs in a sandbox at a very restricted privilege level. Important system calls are supposed to be handled by a special broker process that will subject them to extensive testing. However, a small design flaw allows attackers to user system calls, circumvent ASLR (Address Space Layout Randomisation) and DEP (Data Execution Prevention) and execute arbitrary code.
As described by Guillaume Delugré, the broker process is at the heart of the exploit as it uses a memory page allocated via VirtualAllocEx to store the overwritten code of system calls which have been redirected to the broker. Despite having ASLR, however, the memory address returned by VirtualAllocEx is not randomised. This means that the Windows system function call will end up in a predictable, "nearly constant" location which the exploit can then access directly.' link

From the blogpost;

'Adobe Reader X currently makes use of three different techniques to back off attackers on Windows:
DEP (permanently enabled)
ASLR
Application sandboxing, with a derivative of the Chrome's sandbox implementation
We will see here how a bug in the Chrome sandbox can lead to the full bypass of ASLR and DEP in the renderer process with a good reliability (although not breaking the sandbox protection itself). The target will be an up-to-date Adobe Reader 10.1.3 on Windows 7 x64.
...
It is interesting to see how a mistake in the implementation of a security measure can impact the efficiency of another. ASLR particularly is a very fragile feature. It is only working under the assumption that every executable page in the process address space is randomized. How many products, supposedly protected by ASLR, have we seen still exploitable because one DLL wasn't compiled to be ASLR-compatible (oops...) ? This fragility speaks for itself here, where a single static page with a few instructions is enough to nullify the protection.
It also shows how a security measure can be dependent on the OS. When I first observed the non-randomized page, I browsed the code and couldn't find anything wrong with it. Until I did some tests on VirtualAllocEx by myself and realized the result was never randomized. Dear Windows, that is not the expected behavior.' link

 

I found it this afternoon. Did you test it? I downloaded the PoC, and from what I could see, it required JavaScript to be enabled in Adobe Reader, and didn't see anything happening, because JS is disabled. Can anyone confirm it?

 

I see that even with EMET applied the address for ntdll.dll never changes...

 

Yep. There are a number of universal ASLR bypasses due to addresses that can not change. But with EMET you'll gain EAF so any automated exploit requiring ROP should fail anyways unless it takes it into account.