How to Make ASLR Win the Clone Wars: Runtime Re‐Randomization
Abstract
Existing techniques for memory randomization such as the widely explored Address Space Layout Randomization
(ASLR) perform a single, per‐process randomization that is applied before or at the process’ load‐time. The efficacy of
such upfront randomizations crucially relies on the assumption that an attacker has only one chance to guess the
randomized address, and that this attack succeeds only with a very low probability.
Recent research results have shown that this assumption is not valid in many scenarios, e.g., daemon servers fork child
processes that inherent the state – and if applicable: the randomization – of their parents, and thereby create clones
with the same memory layout. This enables the so‐called clone‐probing attacks where an adversary repeatedly probes
different clones in order to increase its knowledge about their shared memory layout.
In this paper, we propose RuntimeASLR – the first approach that prevents clone‐probing attacks without altering the
intended semantics of child process forking. The paper makes the following three contributions. First, we propose a
semantics‐preserving and runtime‐based approach for preventing clone‐probing attacks by re‐randomizing the address
space of every child after fork() at runtime while keeping the parent’s state. We achieve this by devising a novel,
automated pointer tracking policy generation process that has to be run just once, followed by a pointer tracking
mechanism that is only applied to the parent process. Second, we propose a systematic and holistic pointer tracking
mechanism that correctly identifies pointers inside memory space. This mechanism constitutes the central technical
building block of our approach. Third, we provide an opensource implementation of our approach based on Intel’s Pin
on an x86‐64 Linux platform, which supports COTS server binaries directly. We have also evaluated our system on Nginx
web server. The results show that RuntimeASLR identifies all pointers, effectively prevents clone‐probing attacks. Although it takes a
longer time for RuntimeASLR to start the server program (e.g., 35 seconds for Nginx), RuntimeASLR imposes no runtime
performance overhead to the worker processes that provide actual services.