An attacker who finds a bug in a program still has to know where in memory the useful code sits. Address space layout randomisation, or ASLR, moves the pieces of a program to random places each time it starts. An exploit written for one layout then points at the wrong address, and the program crashes instead of being taken over.
That is the whole trick. It does not fix the bug. It hides the target.
Why a random address beats a known one
Most memory attacks, such as a buffer overflow, redirect a program to code the attacker chose. Many of them reuse code already loaded in memory, and those code-reuse attacks depend on that code sitting at a predictable spot. Microsoft added ASLR to Windows in Vista to break exactly that assumption. Ars Technica reported in 2017 that every major operating system had leant on the technique for about a decade.
The Register describes the defence as raising the bar rather than closing the door. An attacker who learns the layout gets the old, predictable machine back.
How attackers read the shuffle
In 2017 five researchers at Vrije Universiteit Amsterdam published an attack they called AnC. It ran as JavaScript in Chrome and Firefox. It timed the CPU’s memory management unit to work out which page-table entries the chip touched. That timing leaked where code had landed.
The team found it worked on 22 processor designs from vendors including Intel, AMD, and ARM. Their own figures show each page-table lookup gives away nine bits of randomness. That was enough to defeat even an ideal ASLR layout with 36 bits. The authors advised that ASLR should stop serving as a first line of defence.
Some failures were plainer. Will Dormann, an analyst at Carnegie Mellon’s CERT/CC, found that forcing ASLR on across Windows 8 and later did not randomise anything. Programs loaded at the same address on every reboot. Microsoft replied that ASLR worked as designed and that default settings were not at risk.
Why Google stopped patching
A Chromium contributor showed that Oilpan, the garbage collector in Chrome’s rendering engine, could reveal where an object sat in memory. Oilpan cannot always tell a number from a pointer, so a planted number that matches an object’s address keeps that object alive. If the object survives a clean-up, the guess was right.
Google engineer Chris Palmer marked the report “WontFix”. His reasoning was that Spectre-style chip flaws already defeat ASLR, so Chrome must plan for a world where it can be bypassed. Apple’s Safari uses a similar garbage collector and was also said to be affected.
ASLR still makes a crash more likely than a takeover. The open question is what replaces it as the thing exploit writers must beat first.
