BeyondTrust

Security In Context

Bringing you news and commentary on solutions and strategies for protecting your critical IT infrastructure.

DEP Down Part 2: Why is DEP failing?

Post by The eEye Research Team October 21, 2010

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

Vulnerability Expert Forum Highlights: April 2014

We had a great turnout for last week’s April 2014 Vulnerability Expert Forum (VEF) webcast. BeyondTrust Research experts, Carter and DJ, provided in-depth knowledge about the latest vulnerabilities and their potential impacts on network environments. Below are highlights from the Forum, plus an on-demand video of the presentation. Latest critical vulnerabilities, vendor patches, and zero-day…

Post by Chris Burd April 16, 2014
Tags:
, , , , ,
BI-5.1-user-asset-visibility-img

Understanding Who Has Access to What with BeyondInsight v5.1

Today, it’s my pleasure to introduce you to BeyondInsight version 5.1, the latest release of our IT Risk Management platform, which unifies several of our solutions for Privileged Account Management and Vulnerability Management. BeyondInsight v5.1 embodies BeyondTrust’s mission to give our customers the visibility they need to make smart decisions and reduce risk to their…

Post by Morey Haber April 15, 2014
Tags:
, , , , , , , , , , , ,

PowerBroker for Unix & Linux Now Available via Web Services

This week BeyondTrust released a fully functional Web Services interface (REST API) for its PowerBroker for Unix & Linux product.  With this new feature users of the solution will now be able to remotely and securely configure and retrieve data via the API.  The Web Services interface implemented by BeyondTrust is an industry standard that…

Post by Paul Harper April 10, 2014
Tags:
, , , , ,