BeyondTrust

Security in Context: The BeyondTrust Blog

Welcome to Security in Context

Bringing you news and commentary on solutions and strategies for protecting critical IT infrastructure in the context of your business.

DEP Down Part 2: Why is DEP failing?

Posted October 21, 2010    The eEye Research Team

In the first part of the series “DEP Down”, we discussed how DEP (Data Execution Prevention) is not always enabled on the application targeted by attackers. When it is enabled, it can be defeated in a number of ways:

  1. Return-to-libc attacks
    These attacks, while normally limited to simple system commands, will always evade DEP as code will never execute from non-executable memory.
  2. Resetting the NX bit on the protected page to allow execution
    Exploit code can accomplish this by calling the VirtualProtect API passing in the address of malicious code and specifying PAGE_READ_WRITE_EXECUTE.
  3. Disabling DEP for current process
    An attacker could call SetProcessDEPPolicy (supported on Windows XP SP3, Vista SP1 and Windows 2008) to disable DEP for the current process with the caveat that it can be accomplished only if the process has not called this function itself.
    Another way to accomplish this is by calling the NtSetInformationProcess API to disable DEP on the current process. A good article explaining this bypass can be found here.
  4. Allocating new writable and executable memory then copying the shellcode payload to it and jumping to it
  5. Copying the shellcode to an already existing writable memory area and jumping to it

But how would an attacker be able to do any of the above if DEP will not let it execute in the first place? The answer lies in using a technique known as ROP (Return Oriented Programming). In a nutshell, ROP is a very clever way of using pieces of already existing code (called snippets or gadgets) from the current process and chaining them together in order to disable DEP (or perform other nefarious actions).

Without going into the details of ROP (although we do recommend reading the document linked above as well as Dino Dai Zovi’s excellent presentation), we should point out that there is one additional requirement for ROP to succeed: module(s) from which code will be “borrowed” must be loaded at predictable and consistent locations. And that is exactly what used to happen until ASLR (Address Space Layout Randomization) came around.

ASLR will throw a wrench in the wheel by randomizing the location where modules load and by doing so, it makes it impossible to reliably find where to jump in a ROP chain. The problem with ASLR is that it is an opt-in feature by default (it can be forced set to always on via registry) and all it takes is one module to be compiled by the vendor without the /DYNAMICBASE linker flag to provide enough ROPe to hang yourself (pun intended).

A classic example of such an exploit, and maybe the first, was the LibTiff Adobe Reader exploit. The exploit makes use of one Adobe DLL which did not use ASLR (BIB.dll) from which it managed to “borrow” enough code to allocate executable memory, copy the payload to it, and then jump to it. Pretty impressive, right?

The weak point in this case was the memory where the code was copied was left as PAGE_READ_WRITE_EXECUTE (it needed the WRITE access to be able to copy to it in the first place). That is enough information for a security product capable of tracking where code is being executed from to detect foul play. Knowing that Adobe Reader is not supposed to execute from writable memory (even if marked as executable) is a dead giveaway.

To recap, DEP is a great security measure offered by Windows to defend against attacks exploiting buffer overflow vulnerabilities – especially when used with ASLR – however it is not invulnerable and additional security is still needed.

Blog by:
Laurentiu Nicula
Founding Software Engineer
LNicula@eeye.com

Tags:
,

Leave a Reply

Additional articles

PBPS-screenshot-blog aug2014

Failing the Security Basics: Backoff Point-of-Sale Malware

Posted August 22, 2014    Marc Maiffret

At the beginning of this month, US-CERT issued a security alert relating to a string of breaches that had been targeting Point of Sale (POS) systems. The alert details that attackers were leveraging brute forcing tools to target common remote desktop applications such as Microsoft’s Remote Desktop, Apple Remote Desktop, Splashtop and LogMeIn among others….

Tags:
, , , , , ,

Troubleshooting Windows Privilege Management Rules with Policy Monitor

Posted August 21, 2014    Jason Silva

When defining and testing PowerBroker for Windows rules for production or pilots, customers sometimes tell us, “I don’t think this policy / program is working.” This is usually a case of the policy not properly triggering because of the way the rule was created. A unique feature of PowerBroker for Windows compared to other solutions is a client-side…

Tags:
, , ,
darren-mar-elia

BeyondTrust Webcast: Darren Mar-Elia’s 4 Active Directory Change Scenarios to Track

Posted August 20, 2014    Chris Burd

In our latest webcast, we joined Darren Mar-Elia, CTO at SDM Software, to discuss best practices for Active Directory (AD) change management. Here are some key takeaways from the presentation, followed by a link to a full-length video of the presentation. Mar-Elia kicks things off with a critical insight: that the best AD change management…

Tags:
, , , , , , ,