Address space layout randomization (ASLR) is an exploit mitigation that places a program’s code, libraries, stack and heap at random memory addresses, so attackers cannot predict where to jump.
How ASLR works
Memory corruption exploits traditionally relied on fixed addresses: an attacker who overwrote a return address with a buffer overflow needed to know where useful code, such as a system library function, was located. With ASLR the operating system chooses a different base address for the executable, shared libraries, stack and heap each time a program starts (or, on Windows, for system DLLs at each boot). The attacker’s hard-coded addresses then point to invalid memory and the process crashes instead of being taken over.
The PaX project introduced ASLR for Linux in 2001; it reached the mainline Linux kernel in 2005, Windows Vista in 2007 and iOS and Android later. KASLR applies the same idea to the operating system kernel.
Why ASLR matters and its limits
ASLR, together with non-executable memory (DEP/NX) and stack canaries, made reliable exploitation much harder and more expensive. It is not a complete defence, though:
- information leaks – a second bug that reveals a single pointer lets attackers calculate the real layout, so modern exploit chains combine a leak with, for example, a use-after-free;
- low entropy – on 32-bit systems the number of possible positions is small enough to brute-force;
- non-randomised modules – a single library compiled without ASLR support gives attackers fixed addresses;
- hardware side channels – research has repeatedly shown that CPU caches and branch predictors can reveal KASLR offsets.
Best practices
- Compile software as position-independent executables (PIE) and keep ASLR enabled system-wide.
- Use 64-bit builds for higher randomisation entropy.
- Combine ASLR with other mitigations such as Control Flow Guard and fast patching of memory-safety bugs.
