Skip to content

AD2009: EnableAddressSpaceLayoutRandomization

Summary

Property Value
ID AD2009
Name EnableAddressSpaceLayoutRandomization
Category Security
Severity Error
Applies to PE (Windows)

Description

Binaries should be linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities.

How It Works

The rule checks for the IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag (0x0040) in the PE optional header's DLL characteristics field.

When this flag is set, the Windows loader can relocate the binary to a random base address at load time. This makes it difficult for attackers to predict memory addresses.

Why This Matters

Address Space Layout Randomization (ASLR) fundamentally changed the economics of exploit development. Before ASLR, an attacker could write an exploit once and have it work reliably across all systems. With ASLR, each execution presents a different memory layout, making reliable exploitation far more difficult.

Historical Context

Before ASLR (pre-2007 on Windows), exploits were trivially reliable:

1. Find buffer overflow in application
2. Determine address of useful code/gadgets
3. Craft payload with hardcoded addresses
4. Exploit works 100% of the time on all systems

With ASLR:

1. Find buffer overflow
2. Addresses are unknown and random
3. Must either:
   a. Find information leak (harder)
   b. Brute-force addresses (noisy, may crash)
   c. Find non-ASLR module (this rule prevents that)

ASLR protection is only as strong as the weakest module in a process:

Scenario Attacker Strategy
All modules ASLR Must find info leak or brute-force
One non-ASLR DLL Use gadgets from that DLL
Main executable non-ASLR Exploit becomes reliable again

This is why every module must have ASLR enabled. A single non-ASLR module provides a stable base for exploitation.

Security Impact Quantified

Configuration Exploitation Difficulty
No ASLR Trivial (100% reliable)
ASLR (all modules) Requires info leak + spray
ASLR + High Entropy Significantly harder

Common Bypass Techniques (and how DYNAMICBASE prevents them)

  1. Using non-ASLR modules: If even one DLL lacks DYNAMICBASE, attackers can use its code. This rule prevents that.

  2. Information disclosure: Attackers leak a pointer to defeat ASLR. ASLR still forces them to find such a leak.

  3. Brute-forcing: With 32-bit ASLR, ~65K attempts might succeed. High-entropy ASLR makes this infeasible.

Performance Considerations

ASLR has negligible performance impact:

  • Startup: Single relocation pass, typically <1ms
  • Runtime: Zero overhead after loading
  • Memory: Minimal (relocation data already exists)

Why DYNAMICBASE Must Be Explicit

Although DYNAMICBASE is enabled by default in modern Visual Studio, explicit verification is important because:

  • Build scripts may disable it inadvertently
  • Third-party components may not have it
  • Legacy project files may have explicit /FIXED

Resolution

Enable DYNAMICBASE

Linker flag: 

link.exe /DYNAMICBASE ...

This is enabled by default in modern versions of Visual Studio. To ensure it's not disabled:

link.exe /DYNAMICBASE:YES ...

Project Properties

  1. Open Project Properties
  2. Navigate to Linker → Advanced
  3. Set "Randomized Base Address" to "Yes (/DYNAMICBASE)"

CMake

if(MSVC)
    # DYNAMICBASE is on by default, but ensure it's not disabled
    add_link_options(/DYNAMICBASE)
endif()

Remove Fixed Base Address

If you have /FIXED specified, remove it:

# Bad - disables ASLR
link.exe /FIXED ...

# Good - allows ASLR
link.exe /DYNAMICBASE ...

When to Suppress

This rule should rarely be suppressed. Consider suppression only for:

  • Boot loaders: Very early boot code before ASLR is available
  • Embedded systems: Specialized systems without ASLR support
  • Debugging: Temporarily for debugging specific memory issues

Caveats

References