ASLR, or address space layout randomization, is an exploit mitigation that places a process’s key memory regions at random addresses, including the executable image, shared libraries, the stack and the heap, so that an attacker cannot predict where code and data are located. In OS security, ASLR is one of the standard built-in protections of Windows, macOS, Linux, Android and iOS.
Many memory corruption attacks need a precise address: the location of a useful function, a sequence of instructions or a data structure. ASLR does not remove the underlying bug, but it turns a reliable exploit into a guess. Its strength depends on how many bits of randomness each region receives and on whether the attacker can leak an address from the running program.
How ASLR randomizes memory
When the operating system creates a process, its loader decides where each component is mapped in the virtual address space. Without ASLR, the same program and libraries land at the same addresses on every run and on every computer with the same software version. With ASLR, the loader adds a random offset to the base address of each region, and the program works normally because its code uses relative addressing or is adjusted through relocation.
For the main executable to move, it must be built as position-independent code. On Linux this is a position-independent executable, enabled by compiler options such as -fPIE and linker option -pie. On Windows, images opt in through the DYNAMICBASE flag, and the system can also force relocation of older images. On Windows, libraries are randomized once per boot and shared across processes, while on Linux they are typically randomized per process.
Kernels apply the same idea to themselves. Kernel ASLR, often called KASLR, randomizes the kernel’s base address at boot, which makes kernel exploits harder to aim.
Randomized regions and entropy
The protective value of ASLR is measured as entropy, the number of random bits in a region’s base address. Each extra bit doubles the number of possible locations. The values below are typical for 64-bit desktop systems and vary by kernel version, configuration and architecture.
| Memory region | Randomized | Typical entropy on 64-bit systems |
|---|---|---|
| Executable image | Only if built position-independent | Roughly 17-30 bits |
| Shared libraries | Yes | Roughly 19-30 bits |
| Stack | Yes | Roughly 22-30 bits or more |
| Heap | Yes | Varies by allocator and system |
| Memory-mapped regions | Yes | Roughly 28-32 bits on Linux |
| Kernel base | With KASLR | Often 9 bits or fewer |
On 32-bit systems, the small address space limits entropy to roughly 8-16 bits for many regions, which makes brute-force guessing practical when a service restarts automatically after a crash. This is one of the main reasons security guidance favors 64-bit operating systems and applications.
ASLR among other exploit mitigations
ASLR is designed to work as part of a layered defense. It hides addresses, while other mitigations prevent injected code from running or restrict where execution may jump. The table places it next to its closest neighbors.
| Mitigation | What it prevents | How it complements ASLR |
|---|---|---|
| ASLR | Reliable use of known addresses | Forces attackers to discover addresses |
| Executable space protection | Running injected code from data memory | Pushes attackers toward code reuse, which ASLR obstructs |
| Stack canaries | Silent return address overwrites | Detect common stack overflows |
| Control-flow integrity | Jumps to unintended code locations | Limits targets even if addresses leak |
| Process isolation | One process reading another’s memory | Contains the impact of a compromise |
The pairing with executable space protection, also known as DEP or NX, is the classic combination. Non-executable memory stops injected code, so attackers turn to return-oriented programming, which reuses existing instructions. ASLR then hides where those instructions are.
Checking and configuring ASLR
ASLR is enabled by default on all mainstream desktop operating systems, but its coverage depends on how each program was built and on system policy. Administrators and developers should verify both.
| System | Control point | Recommended state |
|---|---|---|
| Windows | Exploit protection settings, image flags | Mandatory and bottom-up ASLR on |
| Linux | kernel.randomize_va_space setting | Value 2 for full randomization |
| macOS | Built into the system and toolchain | Default, applications built as PIE |
| Developer builds | Compiler and linker options | PIE or DYNAMICBASE always enabled |
Disabling ASLR is sometimes done temporarily for debugging, because stable addresses make crash analysis easier. It should never stay disabled on production systems, and debugging tools usually offer a per-process option that avoids changing the global setting.
Limitations and bypass techniques
ASLR is a probabilistic defense, so its protection disappears once the attacker learns a single relevant address. Most real exploits against modern systems combine a memory corruption bug with an information leak.
- Information leaks reveal a pointer, after which the offset of a whole module can be calculated.
- Non-randomized modules loaded into an otherwise protected process give attackers fixed addresses.
- Low entropy on 32-bit systems allows brute-force attempts against services that restart.
- Shared randomization across processes or until reboot lets one leak serve several attacks.
- Hardware side channels in processors have been used to infer randomized kernel addresses.
A common misconception is that ASLR fixes vulnerabilities. It only raises the cost of exploitation. Patching the underlying memory safety bug, and increasingly writing new code in memory-safe languages, remains the real remedy.
Understanding it simply
ASLR shuffles where a program keeps its parts in memory every time it starts. An attacker who wants to misuse a program often needs exact locations. It is like a burglar who must know which drawer holds the keys.
With ASLR, the drawers move every time. A plan that worked on one computer fails on the next. The drawers are not locked, though. An attacker who can peek inside once may still succeed, so ASLR is combined with other protections.
Applied in practice
A company runs an older 32-bit document conversion service on Linux, and a security assessment finds a buffer overflow in one of its image libraries. The testers show that, because the service restarts automatically after each crash and its library addresses have only about 8 bits of entropy, they can guess the correct address within a few hundred attempts.
The team rebuilds the service as a 64-bit position-independent executable, confirms that kernel.randomize_va_space is set to 2, and limits automatic restarts so repeated crashes raise an alert. The library is also updated to fix the overflow itself.
A repeat test finds that the brute-force approach is no longer feasible within any realistic time, and the crash alerting would expose such an attempt quickly. The assessment notes that the fix to the library, not ASLR, closed the vulnerability, while ASLR now protects against similar undiscovered bugs.