Address-space randomisation on a pre-forking daemon: why does a crashed worker help the attacker?

## Where the draw actually happens The randomised bases are chosen when a program image is loaded into a fresh address space. Creating a process by copying an existing one does not load anything: the child receives a copy-on-write duplicate of the parent's mappings, at the same addresses, with the same permissions. Only replacing the image - loading the executable again in that process - causes a new draw. That one implementation detail decides how much protection a long-lived service actually gets, and it is invisible in any datasheet that says the mitigation is enabled. ## The pre-forking daemon A classic memory-unsafe network daemon starts a parent, loads its libraries, then forks a pool of workers. When a worker exits - cleanly, or by dying on a fault - the parent forks another from itself. Every worker in the pool, and every worker created for the rest of the daemon's uptime, has the identical layout that was drawn the day the service last started. The stack-guard value behaves the same way. It is generated once per process image from randomness supplied by the kernel at load, kept where the running code can find it cheaply, and copied into every child. All workers share one cookie. ## What that hands the attacker Three things, and the third is the one people miss. 1. **Retries are free.** A wrong address costs one worker, and a fresh one appears. Guessing that would be hopeless against a single-shot target becomes a matter of patience against a service designed to survive worker death. 2. **A leak in one interaction is usable in another.** Disclose an address through one connection and use it in a later one against a different worker, because both share the draw. 3. **Crash versus survival is itself an oracle.** With no disclosure defect at all, the attacker overwrites the cookie one byte at a time: try a byte value, and if the child dies the guess was wrong, and if it lives the guess was right. Eight bytes at a couple of hundred tries each is a few thousand connections, not an astronomical number. The same technique then walks memory to locate usable instruction fragments. This is the published blind return-oriented method, and the only precondition it needs is that the replacement child has the parent's layout. ## The condition that breaks it If a worker is created by loading the image afresh rather than by copying the parent, each worker gets its own draw and its own cookie. Then a wrong guess costs the attacker not one worker but the entire accumulated knowledge, and the arithmetic returns to what the mitigation's datasheet implied. That is the concrete design change available here, and it is cheap compared with a rewrite: pay a process-creation cost per worker in exchange for a fresh draw per attempt. Two weaker measures are worth naming honestly. Restarting the parent periodically re-draws for everyone, which shortens the window an attacker has to work within but does not make an individual campaign expensive. Limiting how fast replacements are created raises the wall-clock cost of a byte-at-a-time search without changing its feasibility - useful against somebody with a weekend, irrelevant against somebody with a month. ## The general lesson, which is the reason this leaf exists A mitigation is a price, and the price is set by the *deployment*, not by the compiler flag. The same binary, with the same flags, is priced very differently depending on whether workers are copies or fresh loads. When someone reports that a mitigation is enabled across the estate, the follow-up question is what an attempt costs the attacker and whether a failed attempt costs them anything at all. On a pre-forking daemon the answer is: almost nothing, which is why the two adversaries in the same position get different outcomes. Someone running a public proof of concept written for a different build still just kills workers. Someone willing to spend weeks turns free retries into the address secret the exploit needs.