Address-Oblivious Code Reuse: on the Effectiveness of Leakage-Resilient Diversity

Address-Oblivious Code Reuse: On the Effectiveness of Leakage-Resilient Diversity Robert Rudd,∗ Richard Skowyra,∗ David Bigelow,∗ Veer Dedhia,∗ Thomas Hobson,∗ Stephen Crane,y Christopher Liebchen,z Per Larsen,x Lucas Davi,{ Michael Franz,x Ahmad-Reza Sadeghi,z Hamed Okhravi∗ ∗MIT Lincoln Laboratory. ffirstname.lastname,[email protected] yImmunant, Inc. [email protected] zCYSEC/TU Darmstadt.fchristopher.liebchen,[email protected] xUniversity of California, Irvine. fperl,[email protected] {University of Duisburg-Essen. [email protected] Abstract—Memory corruption vulnerabilities not only allow I. INTRODUCTION modification of control data and injection of malicious payloads; they also allow adversaries to reconnoiter a diversified program, Memory corruption has been a primary attack vector customize a payload, and ultimately bypass code randomization against computer systems for decades [2]. Memory corruption defenses. In response, researchers have proposed and built various attacks range from conventional stack smashing techniques [44] leakage-resilient defenses against code reuse. Leakage-resilient to more sophisticated code-reuse attacks (CRAs) such as defenses use memory protection techniques to prevent adversaries return-oriented programming (ROP) [50], which emerged in from directly reading code as well as pointer indirection or response to the widespread adoption of defenses such as W⊕X encryption techniques to decouple code pointers from the ran- (Write⊕eXecute). Part of the appeal of memory corruption to domized code layout, avoiding indirect leakage. In this paper, we attackers is the ability to execute arbitrary code on a remote show that although current code pointer protections do prevent leakage per se, they are fundamentally unable to stop code target system after hijacking the control flow. Despite numerous reuse. Specifically, we demonstrate a new class of attacks we advances, comprehensively protecting native code written in call address-oblivious code reuse that bypasses state-of-the-art C/C++ from ROP and other CRAs remains an open challenge. leakage-resilience techniques by profiling and reusing protected Code-reuse defenses are either based on enforcement [1, 33, code pointers, without leaking the code layout. We show that an attacker can accurately identify protected code pointers of 41] or randomization [7, 23, 34, 37]. In this paper, we focus interest and mount code-reuse attacks at the abstraction level on state-of-the-art code randomization techniques that provide of pointers without requiring any knowledge of code addresses. resilience against information leakage attacks and have shown We analyze the prevalence of opportunities for such attacks in to be both efficient and scalable to large codebases. We call popular code bases and build three real-world exploits against such techniques leakage-resilient defenses. Nginx and Apache to demonstrate their practicality. We analyze recently proposed leakage resilient defenses and show that they Preventing all types of information leakage is extremely are vulnerable to address oblivious code reuse. Our findings challenging. Direct leakage of memory content (a.k.a., memory indicate that because of the prevalence of code pointers in realistic disclosure) [53, 56], indirect leakage of addresses from the programs and the fundamental need to expose them to “read” stack or heap [17], and side-channels [5, 9, 42, 48] are different operations (even indirectly), diversity defenses face a fundamental forms of information leakage that have been used successfully design challenge in mitigating such attacks. to bypass recent code randomization defenses [17, 18]. Due to the prevalence and threat of such information leakage attacks, recent defenses have been based on a threat model that assumes the attacker can read and write arbitrary memory if allowed DISTRIBUTION STATEMENT A. Approved for public release: distribution by the page permissions [7, 11, 15, 16]. unlimited. Execute-only code memory (a.k.a. execute-no-read, XnR, This material is based upon work supported by the Department of Defense under Air Force Contract No. FA8721-05-C-0002 and/or FA8702-15-D-0001. or X-only) is used by many leakage-resilient defenses [3, 11, Any opinions, findings, conclusions or recommendations expressed in this 15, 22] to shield randomized code layouts from direct leakage. material are those of the author(s) and do not necessarily reflect the views of Some defenses [3, 58, 61] relax ideal X-only code permissions the Department of Defense. to handle legacy binaries that may embed readable data in code, but these defenses have been shown to be lacking [54, 61]. The most powerful leakage-resilient defenses also prevent indirect Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation leakage by hiding code pointer destinations, e.g., using pointer on the first page. Reproduction for commercial purposes is strictly prohibited encryption [38] or an indirection layer [15]. without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author’s employer if the paper was prepared within the scope of employment. Goals and Contributions. NDSS ’17, 26 February - 1 March 2017, San Diego, CA, USA In this paper, we will consider a state-of-the-art leakage- Copyright 2017 Internet Society, ISBN 1-891562-46-0 http://dx.doi.org/10.14722/ndss.2017.23477 resilient defense that combines the strengths of all concrete, leakage-resilient defenses [3, 11, 15, 16, 22, 38] proposed filesystem to directly leak memory content even in the presence to date. We will not consider leakage-tolerant defenses of defenses such as GRSecurity [55]. Both these vectors can which seek to obsolete leaked information via runtime re- be used to maliciously leak actual non-readable code pages, randomization [7, 23, 37]. We use Readactor–one of the after which conventional ROP attacks become straightforward. most comprehensive implementations of a leakage-resilient In other words, if these vectors are not blocked by the defense, code randomization defense–to demonstrate a new class of the attacker can use conventional ROP attacks instead of having CRAs, which we call Address-Oblivious Code Reuse (AOCR), to resort to AOCR. that can generically bypass leakage-resilient defenses without knowledge of the code layout. The intuition behind AOCR In summary, our contributions are as follows: is that execute-only permissions apply just to code, not code • We present AOCR, a new class of CRAs that generi- pointers (e.g., function pointers and return addresses). Code cally bypass state-of-the-art leakage-resilient defenses pointers/identifiers must be readable for programs to function by reusing indirect code pointers. Unlike existing correctly. Various execute-only defenses use indirection or attacks, AOCR does not rely on the layout of vtables encryption to protect these code pointers, but these alternative or the allocation and use of registers which renders code pointer representations remain exploitable by adversaries. COOP-centric defenses ineffective [16, 59]. Specifically, we demonstrate that an attacker can profile this • We demonstrate that code-reuse attacks can be con- layer of indirection in code pointers by observing the state of structed out of protected code pointers without direct the protected program remotely, and extract these indirect code knowledge of the code layout. We do so by building pointers. We then show that by only reusing these indirect code three AOCR exploits targeting Nginx and Apache. pointers, an attacker can achieve malicious behavior without explicitly requiring read access to the diversified code. We call • We present two techniques to accurately profile the our attack Address-Oblivious Code Reuse because its strength indirection layer (Malicious Thread Blocking) and lies in the fact that it does not need to leak or otherwise learn the chain (Malicious Loop Redirection) AOCR gadgets address of code snippets in order to successfully exploit them. that make our attacks highly practical. Rather, by stitching together their indirect code pointers, the • attacker can successfully execute code snippets while remaining We discuss two main implementation challenges to oblivious to their randomized (hidden) addresses. Unlike COOP achieve ideal leakage resilience in modern operating attacks [47], our AOCR attack does not rely on the layout of systems that further demonstrate the difficulty of effec- vtables, the allocations, or the use of registers. In a sense, AOCR tively and universally enforcing memory permissions. can be thought of as position-independent form of CRA. II. THREAT MODEL To accurately profile indirect code pointers in a running process remotely, we devise a new attack technique that we Our threat model assumes that a remote attacker uses a call Malicious Thread Blocking (MTB). To chain indirect memory corruption vulnerability to access arbitrary memory code pointers, we show a new exploitation technique against and achieve remote code execution on the victim machine. imperative programming languages we call Malicious Loop We assume W⊕X is deployed to prevent code injection and Redirection (MLR). modification. Moreover, we assume that the software executing on the target system is protected by a state-of-the-art leakage- Using these techniques, we build two real-world AOCR resilient randomization-based defense capable of

Load more