Definition
Randomizing the base (start) address of one or more segments of memory during the initialization of a process.
How it works
Many application exploits rely on an attacker specifying a location in memory, which points to data or code used by the attacker. If the addresses are changed each time the program is run, then it becomes more difficult for the attacker to determine the location that will contain the code they wish to run.
Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing." Just as not all code is built for participation in ASLR, not all modules can be rebased; instead, modules must indicate whether they implement support for rebasing. Such information to relocate the executable is typically stored in the ".reloc" segment -- each of the addresses pointed to in this segment has its address increased by the amount of the offset. (An alternative method for relocation would be to add an amount to a global variable each time -- leading to less overhead in the module load, but more for each access. Still another implementation could instead contain code to deference each changeable memory location on the fly, so that each of the references do not need to be updated.
Considerations
As the offset for each segment is constant, it is possible to guess at the value of the address given the address of another variable. Alternatively, memory pointers may be kept around, which contain the address of another variable. Another bypass technique is known as an "egg hunt," whereby the attacker searches for a rather unique piece of the data or code in memory to determine its likely address.
The program needs to store these addresses for the functions somewhere. In Linux, the PLT contains a "trampoline" to these addresses. If an attacker desires to jump to the start of an existing function, they can jump directly to the trampoline anyway, and may have the opportunity to provide their own stack frame to the function with a write to the stack. If they overwrite a saved stack pointer which is loaded back into memory, or execute a function, that changes the address of a stack pointer.
If an attacker wants to inject some data into the program, for example as a parameter to a known function that is not under ASLR or a pointer to a trampoline function in the PLT, then they can repeat the data until they exceed the range of ASLR coverage, which on 32-bit systems is accomplishable in a few seconds with a heap spray. Microsoft's EMET and Windows 10 Exploit Guard can pre-allocate particular addresses that are commonly used in heap sprays. However, in many products, there does not seem to be nearly a complete coverage of such addresses, which only need to be executable and in the range of the heap; 0x0c0c0c0c is such an address that is commonly used for the x86 processor architecture, as when executed it only performs a numeric operation to a register four times.
Implementation perspective
Segment Address Offset Randomization should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes Process Segment.
Use the technique to increase the effort, prerequisites, or constraints an adversary must overcome before exploitation or misuse succeeds.
Questions to ask
- Which component, configuration, credential, interface, or behavior is being hardened?
- What secure baseline or policy defines the intended state?
- How are exceptions approved, time-limited, and reviewed?
- How is the hardened state verified after deployment and significant change?
Evidence and validation
- Approved hardening standards and configuration baselines
- Automated configuration or integrity assessment results
- Exception records with owners, rationale, and expiration dates
- Test results demonstrating that the intended restriction is enforced
Common failure patterns
- A secure setting is documented but not enforced consistently across the environment.
- Hardening breaks required functions and is permanently weakened through undocumented exceptions.
- Teams measure deployment of a product rather than verification of the hardened condition.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
Show inferred artifact relationship paths (1)
Offensive-technique relationships
These relationships are generated from D3FEND graph paths and are explicitly experimental. They should be treated as hypotheses for defensive analysis—not as proof that the technique prevents, detects, or removes an offensive behavior.
ATT&CK Enterprise (12)
ATT&CK for ICS (5)
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- /DYNAMICBASE (Use address space layout randomization) ↗Microsoft · Microsoft · UserManualReference
- How ASLR protects Linux systems from buffer overflow attacks ↗Network World · Sandra Henry-Stocker · InternetArticleReference
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.