Address-space randomisation is on: what exactly does one leaked pointer buy an attacker?

## What randomisation randomises At process start the loader places each region at a base chosen at random: the stack, the heap, the region that shared libraries are mapped into, and - if the executable was built position independent - the program image too. The point is that the attacker's chain needs *addresses*: the address of a resident function to return into, the address of an instruction fragment, the address of a controlled buffer. If those move on every start, an exploit written against one machine does not run on the next. ## What it does not randomise The distance from a mapping's base to anything inside it. A library's internal layout is fixed at build time, so if the attacker learns the runtime address of any one thing inside it, subtracting the known build-time offset yields the base, and the base plus any other build-time offset yields any other address inside that mapping. One pointer collapses the whole mapping. Two consequences follow immediately. - The leak has to be *of the right mapping*. A stack address does not give up the library base and vice versa, because those bases were drawn independently. An attacker who needs both usually needs a disclosure that reaches both, or two leaks. - Randomisation is page-granular, so the low bits that index within a page are not randomised at all. That is why partially overwriting only the low bytes of a stored pointer is a real technique: it needs far less unknown information than forging a full address. ## Why this makes it a price rather than a fix Before randomisation, one memory-corruption defect was an exploit. After it, one defect is usually a crash, and an exploit needs a *second* capability: something that discloses memory. The catalogue of disclosure sources in a memory-unsafe network daemon is unglamorous and long: - a reply built from a buffer that was never fully initialised, so the tail carries whatever the last request left there, including pointers; - an out-of-bounds read where a length or index taken from the request is trusted past the data actually written; - a format-string defect that prints stack contents; - an error or diagnostic string that quotes a pointer value back to the caller; - a data structure serialised out with an embedded pointer field that nobody thought was reachable. None of those are exotic, and this is the honest core of the subject: the second bug is a cost, not an impossibility. Add a month of somebody's time to the estimate and the cost is met. ## Guessing instead of leaking Where the entropy in the base is small, the attacker can simply guess. On 32-bit systems the number of possible bases was small enough that brute force over a service that survives failed attempts was practical. Moving to 64-bit addresses raised that number enormously, which is precisely why the leak - not the guess - became the standard route. Note the shape of that history: the mitigation was not broken, it was *repriced*, and the attacker moved to the cheaper of two options. ## Directionality worth stating precisely A leaked address proves where one object is *in that process, at that moment*. It does not prove the same layout holds in another process; a freshly started process gets a fresh draw. This matters when you reason about whether a disclosure is fatal: a leak in a short-lived process spawned per request is worth much less than the same leak in a daemon whose workers all share one draw, because in the second case the attacker can leak in one interaction and corrupt in another. ## An out-of-bounds read is not a lesser bug Engineers routinely triage a read-only out-of-bounds defect as low severity because it does not corrupt anything. Against a hardened target it is the *enabling* half of the pair. The exploit needs both halves, and the market price of the corruption defect goes up or down depending on whether a disclosure is available in the same reachable surface. When you rate two defects in the same daemon, rate them as a set. ## What this means for the argument you will actually have Someone will say the layout is random, therefore the class is handled. The precise reply is that randomisation stores a secret and the exploit's job is now to learn that secret; secrets in a process that talks to untrusted input have many ways out. What randomisation reliably buys is that a copy-pasted public exploit no longer works unmodified - which is genuinely worth having, and is a statement about which adversaries are priced out, not about the defect.