NEW: Microsoft Vulnerabilities Report 2022 - Read the Findings of Our Annual Report Read Now

  • Partners
  • Support
  • Careers
  • English
    • Deutsch
    • français
    • español
    • 한국어
    • português
BeyondTrust
  • Products

    Privileged Password Management

    Discover, manage, audit, and monitor privileged accounts and credentials.

    • Password Safe
    • DevOps Secrets Safe
    • Privileged Access Discovery Application

    Endpoint Privilege Management

    Enforce least privilege across Windows, Mac, Linux, and Unix endpoints.

    • Windows and Mac
    • Unix and Linux
    • Active Directory Bridge

    Secure Remote Access

    Centrally manage remote access for service desks, vendors, and operators.

    • Remote Support
    • Privileged Remote Access
    • Privileged Access Discovery Application

    Cloud Security Management

    Automate the management of identities and assets across your multicloud footprint.

    • Cloud Privilege Broker

    BeyondInsight

    Experience the industry’s most innovative, comprehensive platform for privileged access management.

  • Solutions

    Use Cases

    • Cloud Security
    • Compliance
    • Cyber Insurance
    • Digital Transformation
    • Endpoint Security
    • Operational Technology
    • Ransomware
    • Service Desk Efficiency
    • Zero Trust

    Industry Applications

    • Financial Services
    • Government Agencies
    • Healthcare
    • Law Enforcement
    • Manufacturing
    • Schools & Universities

    Solutions

    The BeyondTrust Privileged Access Management portfolio is an integrated solution that provides visibility and control over all privileged accounts and users.

  • Resources

    Learn

    • Blog
    • Customer Stories
    • Competitor Comparisons
    • Datasheets
    • Videos
    • Glossary
    • Infographics
    • Podcast
    • Whitepapers

    Attend

    • Events
    • Go Beyond
    • Training
    • Webinars

    Support

    • Changelog
    • Professional Services
    • Technical Documentation

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

  • Company
    • About
    • Leadership
    • Core Values
    • Partners
    • Careers
  • Watch Demo
  • Contact Sales

DEP Down Part 2: Why is DEP failing?

October 21, 2010

  • Blog
  • Archive
  1. Home
  2. Blog
  3. DEP Down Part 2: Why is DEP failing?

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

Photograph of Scott Lang

Scott Lang, Sr. Director, Product Marketing at BeyondTrust

Scott Lang has nearly 20 years of experience in technology product marketing, currently guiding the product marketing strategy for BeyondTrust’s privileged account management solutions and vulnerability management solutions. Prior to joining BeyondTrust, Scott was director of security solution marketing at Dell, formerly Quest Software, where he was responsible for global security campaigns, product marketing for identity and access management and Windows server management.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Whitepapers

IDSA Report: 2022 Trends in Securing Digital Identities

Whitepapers

Microsoft Vulnerabilities Report 2022

Whitepapers

Mapping BeyondTrust Capabilities to NIST Zero Trust (SP 800-207)

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support
  • Cloud Privilege Broker

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Infographics
  • Podcast
  • Videos
  • Webinars
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press
BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2022 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.