'Bypassing ASLR and DEP on Adobe Reader X'

Discussion in 'other security issues & news' started by Baserk, Jun 25, 2012.

Thread Status:
Not open for further replies.
  1. Baserk

    Baserk Registered Member

    Joined:
    Apr 14, 2008
    Posts:
    1,321
    Location:
    AmstelodamUM
    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
     
  2. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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?
     
  3. xxJackxx

    xxJackxx Registered Member

    Joined:
    Oct 23, 2008
    Posts:
    8,623
    Location:
    USA
    I see that even with EMET applied the address for ntdll.dll never changes...
     
  4. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    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.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.