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.