# Exploit Mitigation (ASLR / DEP)
Exploit mitigation describes the collection of operating system and hardware-enforced controls that raise the cost and complexity of turning software vulnerabilities into working attacks. Even when a memory corruption bug is confirmed and unpatched, well-configured mitigations force an attacker to solve additional, often unsolvable, technical problems before achieving code execution. Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) are the two foundational controls in this category.
These mechanisms do not eliminate vulnerabilities. A buffer overflow still exists in the binary whether ASLR is enabled or not. Instead, they break the exploitation chain by removing predictable memory layout (ASLR) and blocking execution of injected code (DEP). This transforms a reliable exploit into an unreliable one, or an unreliable exploit into an impossible one.
Both controls have been standard in mainstream operating systems since the mid-2000s. Windows Vista introduced system-wide DEP and ASLR support. Linux gained executable space protection in the early 2000s and position-independent executable support shortly after. macOS implemented similar protections beginning with Mac OS X 10.5. Despite this maturity, misconfiguration, legacy components, and incomplete deployment remain common enough to keep them operationally relevant for every defensive program today.
ASLR and DEP operate at the memory management layer, below application logic but above hardware. They are enforcement mechanisms, not detection mechanisms. They do not identify attacks or log suspicious behavior. They make certain classes of exploitation mechanically impossible or statistically improbable, forcing attackers to find alternative paths or abandon the attack entirely.
Before ASLR, operating systems loaded process components at fixed, predictable virtual addresses. An attacker writing a buffer overflow exploit could hardcode the address of useful functions, such as system() in the C runtime library, because that address was identical across every machine running the same OS version. Public exploit code worked reliably across millions of targets without modification.
ASLR changes this by introducing entropy at load time. When a process starts, the OS kernel selects random offsets for each memory region within predetermined ranges. The base address of the main executable shifts by a random amount. Each shared library loads at a different random offset. The stack and heap are placed at randomized locations within their allocated virtual address space. Critical data structures like the Process Environment Block (PEB) on Windows or the Global Offset Table (GOT) on Linux move to unpredictable locations.
The entropy varies by platform and architecture. 32-bit Windows provides 8 bits of entropy for the executable base and 8 bits for the stack base, creating 65,536 possible locations for each. 64-bit systems offer significantly more entropy: modern Windows implementations provide up to 19 bits of entropy for executable placement and 17 bits for the stack. Linux ASLR entropy is configurable through /proc/sys/kernel/randomize_va_space and can be enhanced with additional kernel patches.
Implementation Requirements and Weaknesses
ASLR only protects memory regions for modules compiled as position-independent. An executable compiled without the Position Independent Executable (PIE) flag, or a DLL compiled without ASLR support, loads at a fixed address regardless of system ASLR settings. Attackers systematically identify these non-ASLR modules and build exploits around the known addresses within them.
This creates a "weakest link" problem. A process may load dozens of modules: the main executable, system libraries, third-party DLLs, browser plugins, or shared objects. If even one module lacks ASLR support, that module provides predictable addresses that can anchor an entire exploit chain. The attacker uses Return-Oriented Programming (ROP) or Jump-Oriented Programming (JOP) gadgets from the non-ASLR module to call functions like VirtualProtect() or mprotect(), disable memory protections on other regions, and proceed with code execution.
A concrete example: a web browser process includes a vulnerable third-party PDF rendering library compiled without ASLR support. The main browser binary and all modern system DLLs are ASLR-enabled and load at randomized addresses. The PDF library consistently loads at 0x10000000. An attacker crafting a malicious PDF document can reliably use gadgets from addresses within that library to pivot into shellcode or call system functions, effectively negating the browser's ASLR protections for this attack path.
Traditional buffer overflow exploits work by writing shellcode (attacker-supplied machine instructions) into a data buffer, then redirecting execution to that shellcode through a corrupted return address, function pointer, or exception handler. Before DEP, this succeeded because processors would execute instructions from any readable memory location, including stack and heap regions intended for data storage.
DEP marks data pages with a No-Execute (NX) bit at the hardware page table level. When the CPU attempts to fetch an instruction from a page marked non-executable, it generates a processor exception instead of executing the instruction. The operating system handles this exception as a fatal access violation, typically terminating the process with an error message like "Data Execution Prevention has blocked this program."
The hardware support varies by processor vendor but achieves the same result. Intel processors implement Execute Disable (XD) bit support in the page table entry. AMD processors provide the No-Execute (NX) bit. ARM processors use the Execute Never (XN) attribute. All modern x86-64 and ARM processors include this functionality, and most x86 processors manufactured after 2003 support it.
DEP Configuration and Bypass Techniques
DEP operates in multiple modes on Windows systems. System DEP protects only core OS components. OptIn DEP requires applications to explicitly request protection through the SetProcessDEPPolicy() API call or specific linker flags. OptOut DEP applies to all processes except those explicitly excluded through system configuration. AlwaysOn DEP protects all processes without exception. The recommended configuration for production systems is OptOut or AlwaysOn, with documented exceptions granted only after security review.
However, DEP alone fails against Return-Oriented Programming attacks. ROP does not inject new executable code. Instead, it chains together short instruction sequences (gadgets) from already-loaded, already-executable code pages. Each gadget performs a small operation—loading a register, calling a function, performing arithmetic—then jumps to the next gadget. By carefully selecting and chaining gadgets, an attacker can perform arbitrary computation using only existing executable code.
Modern ROP attacks often target functions like VirtualProtect() on Windows or mprotect() on Linux to change memory page permissions at runtime. The attacker uses ROP gadgets to call these functions with parameters that mark a data page as executable, then jumps to shellcode stored in that newly-executable region. This bypasses DEP entirely through legitimate API usage.
Neither control provides sufficient protection alone, but their combination creates multiplicative difficulty for attackers. DEP alone fails against ROP-based permission-changing attacks. ASLR alone fails when any loaded module has a known address that can anchor a gadget chain.
When both are fully implemented across all loaded modules, an attacker faces compounding problems: they cannot predict where any ROP gadgets or system functions are located (ASLR), and they cannot execute injected data even if they successfully redirect control flow (DEP). Bypassing this combination typically requires an information disclosure vulnerability—a separate bug that reveals loaded addresses—which can then be used to defeat ASLR before mounting a DEP bypass.
This requirement for multiple vulnerabilities significantly narrows the attacker population and increases exploit development costs. Automated exploit tools and commodity malware typically cannot overcome full ASLR+DEP implementations. Targeted attackers with significant resources can and do defeat these protections, but they must invest substantially more effort per target and often require vulnerability chaining that makes their attacks more complex and detectable.
The presence or absence of ASLR and DEP fundamentally changes the economics of vulnerability exploitation. Without these mitigations, a single memory corruption vulnerability translates directly into reliable code execution across all vulnerable systems. Reliable exploitation enables automated, wormable attacks that spread without human intervention, maximizing the attacker's return on exploit development investment.
The 2017 EternalBlue exploitation of CVE-2017-0144 in Windows SMB demonstrates this dynamic. While affected Windows systems had ASLR and DEP capabilities, the specific exploitation technique used kernel pool manipulation and did not rely on traditional userland shellcode injection. The exploit achieved reliable kernel-level code execution across hundreds of thousands of unpatched systems, enabling the WannaCry and NotPetya campaigns that caused billions of dollars in damage worldwide.
Conversely, when ASLR and DEP are fully deployed, exploitation becomes significantly more expensive. Attackers must either find information disclosure vulnerabilities to defeat ASLR, develop ROP chains to bypass DEP, or both. This additional complexity places memory corruption exploits beyond the reach of most opportunistic attackers and script kiddies, concentrating the threat primarily among well-resourced threat actors with substantial technical capabilities.
From a business risk perspective, gaps in exploit mitigation coverage create asymmetric exposure. A single legacy application or third-party component without proper ASLR support can undermine the security posture of an entire system. This is particularly problematic in environments with long software lifecycles, such as industrial control systems, medical devices, or financial trading platforms where software updates are carefully controlled and infrequent.
The operational impact extends beyond direct exploitation risk. Systems without proper exploit mitigation coverage are more vulnerable to commodity malware, which often relies on simple exploitation techniques that ASLR and DEP would block. This translates to higher incident response costs, more frequent reimaging requirements, and greater exposure to ransomware campaigns that combine exploitation with encryption attacks.
One persistent misconception is that enabling ASLR and DEP at the operating system level guarantees protection. In reality, these features only protect processes and modules that were compiled with appropriate support flags. Legacy applications, third-party software compiled without position-independent execution support, and certain kernel components may not benefit from OS-level ASLR configuration.
Another common error is treating exploit mitigation as a binary security state rather than a continuous configuration requirement. New software installations, library updates, and system patches can introduce non-compliant modules or change DEP policy settings. Organizations that verify mitigation compliance once during initial deployment but never re-audit often discover significant gaps during security assessments or, worse, during actual attacks.
CDA approaches exploit mitigation through the Planetary Defense Model's Vulnerability Surface Defense (VSD) domain, specifically applying the Continuous Surface Reduction methodology: every surface you expose is a surface we eliminate. ASLR and DEP enforcement directly supports this principle by systematically reducing the exploitable surface of every process on every system, continuously and without requiring threat intelligence about specific attack campaigns.
Within the VSD framework, CDA treats exploit mitigation gaps as surface exposure findings equivalent in severity to unpatched vulnerabilities. A process running with a non-ASLR third-party library represents nearly the same exploitation risk as a process with a known CVE. Most security programs treat mitigation configuration as a one-time baseline requirement; CDA tracks it as a continuous control that degrades when new software is installed, libraries are updated, or applications are migrated.
CDA's operational approach differs from conventional security frameworks in several key ways. Rather than simply verifying that DEP is enabled and ASLR is configured, CDA analysts enumerate every process running on in-scope systems and identify all loaded modules. Each module is individually verified for ASLR compilation flags using tools like Process Explorer, VMMap, or custom PowerShell scripts that query process memory attributes. Any module lacking proper mitigation support is documented with the specific process path, vendor information, and business justification for its presence.
The Continuous Surface Reduction methodology means CDA does not simply assess and report gaps. After identifying non-compliant modules, CDA works with application owners to remediate the findings through recompilation with proper flags, vendor engagement for updated versions, or architectural changes that eliminate the dependency. The goal is surface closure, not indefinite risk acceptance.
Within the Surface Protection Hygiene (SPH) domain, CDA extends this approach to system hardening documentation and configuration management. Every system baseline CDA produces includes specific DEP mode requirements, ASLR entropy settings, and approved processes for granting exceptions. Exceptions require documented business justification, identification of compensating controls, and defined sunset dates for remediation. This keeps mitigation posture visible, auditable, and actionable rather than buried in technical configuration details.