Oo7: Low-Overhead Defense Against Spectre Attacks Via Program Analysis
Total Page：16
File Type：pdf, Size：1020Kb
1 oo7: Low-overhead Defense against Spectre Attacks via Program Analysis Guanhua Wang, National University of Singapore Sudipta Chattopadhyay, Singapore University of Technology and Design Ivan Gotovchits, Carnegie Mellon University Tulika Mitra & Abhik Roychoudhury, National University of Singapore Abstract—The Spectre vulnerability in modern processors has been widely reported. The key insight in this vulnerability is that speculative execution in processors can be misused to access the secrets. Subsequently, even though the speculatively executed instructions are squashed, the secret may linger in micro-architectural states such as cache, and can potentially be accessed by an attacker via side channels. In this paper, we propose oo7, a static analysis approach that can mitigate Spectre attacks by detecting potentially vulnerable code snippets in program binaries and protecting them against the attack by patching them. Our key contribution is to balance the concerns of effectiveness, analysis time and run-time overheads. We employ control flow extraction, taint analysis, and address analysis to detect tainted conditional branches and speculative memory accesses. oo7 can detect all fifteen purpose-built Spectre-vulnerable code patterns [1], whereas Microsoft compiler with Spectre mitigation option can only detect two of them. We also report the results of a large-scale study on applying oo7 to over 500 program binaries (average binary size 261 KB) from different real-world projects. We protect programs against Spectre attack by selectively inserting fences only at vulnerable conditional branches to prevent speculative execution. Our approach is experimentally observed to incur around 5.9% performance overheads on SPECint benchmarks. F 1 INTRODUCTION covert channels, for example, cache side-channel [4]. The The Spectre [2] vulnerabilities in processors were revealed website [5] of Spectre states that “As [Spectre] is not easy to in early 2018. The attacks that exploit these vulnerabilities fix, it will haunt us for a long time.” can potentially affect almost all modern processors irrespec- We focus on identifying program binaries that are vul- tive of the vendor (Intel, AMD, ARM) and the computer nerable to Spectre attack and patch those binaries as a system (desktop, laptop, mobile) as long as the processor mitigation technique with minimal performance overhead performs speculative execution. Speculative execution [3] . We present a comprehensive and scalable solution, called is an indispensable micro-architectural optimizations for oo7, based on static program analysis. Our solution employs performance enhancement, ubiquitous in almost all modern control flow extraction, taint analysis and address analysis processors except for the simplest micro-controllers. It is an at the binary level. Moreover, our analysis needs to model the aggressive optimization where the instructions are executed transient instructions along the speculative path that has never speculatively, but the temporary results created by the spec- been required in traditional program analysis dealing with only ulatively executed instructions are maintained in internal programmer visible execution. We have successfully introduced micro-architectural states that cannot be accessed by soft- accurate modeling of speculative execution in oo7. ware. The results are committed to the programmer-visible Once vulnerable code snippets are detected by oo7, we architectural states (registers and memory) only when the introduce fence instructions at selected program points to arXiv:1807.05843v6 [cs.CR] 12 Nov 2019 speculation is found to be correct; otherwise, the internal prevent speculative execution and thereby protect the code micro-architectural states are flushed. The most common from Spectre attack. We have validated the functional cor- example is that of the conditional branches being predicted rectness of our protection mechanism with all fifteen litmus in hardware and the instructions along the predicted branch test codes from [1] on Intel Xeon platform. We note that path are executed speculatively. Once the conditional branch the current Spectre mitigation approach introduced by Mi- direction is resolved, the instructions along the speculative crosoft C/C++ compiler [6], detects and protects only 2 out path are squashed in case of wrong prediction. of 15 litmus tests for Spectre vulnerabilities [1], whereas oo7 Spectre attacks exploit speculation to deliberately tar- can detect all fifteen purpose-built Spectre-vulnerable code get the execution of certain “transient” instructions. These patterns. We can launch successful Spectre attack to access transient instructions are speculatively executed, and are arbitrary locations in the victim code prior to the insertion tricked to bring in secret data into the cache. These transient of fence insertions by oo7; but our attempts at Spectre instructions are subsequently squashed but the secret re- attacks fail after oo7-directed automated identification and mains, for example, in the cache. The attacker then carefully patching of the victim code. We experimentally measure accesses the secret content (that is supposed to be hidden the performance overheads from our selective fence inser- to the outside world) through different micro-architectural tion and find that the overheads are 5.9% on average on SPECint benchmarks, thereby indicating the practicality of To appear in IEEE Transactions on Software Engineering, 2020. our approach. We also report the results of a large-scale experimental study on applying oo7 to over 500 program been disclosed recently. A summary of these variants appear binaries (average binary size 261 KB) from different real- in TABLE 1. We classify the different vulnerabilities into world projects. three categories: We demonstrate that oo7 can be tuned to defend against (a) Vulnerability in victim code: Many Spectre attacks rely multiple different variants of Spectre attack (see TABLE 1) on vulnerable code snippets inside the victim process and that exploit vulnerabilities in the victim code through specu- trigger speculative execution of the code snippet to read lative execution. We also note the limitations of our analysis- secret data by supplying carefully selected inputs to the based approach in defending against certain variants of victim process. We detect these vulnerabilities in oo7 by Spectre attacks. The variants that cannot be addressed by identifying the potentially susceptible code fragments via oo7 have potential system-level solutions introduced by binary analysis and then introducing fences at selected pro- different vendors with reasonably low overhead [7], [8]. gram points to prevent speculative execution and thereby The Spectre variants handled by oo7 with low performance harden the victim software against any such attacks. overhead are either not amenable to system-level defense (b) BTB or RSB poisoning: In these Spectre variants, the mechanisms, incur high performance overhead or escape attacker poisons the Branch Target Buffer (BTB) or Return detection with existing approaches. Thus oo7 approach via Stack Buffer (RSB) in the micro-architecture. The victim binary analysis is complementary to all other efforts in process, while using the poisoned BTB or the RSB for mitigating the impact of security vulnerabilities due to speculative execution, is then mislead to branch or return to speculative execution. a gadget that leaks the sensitive data. Any indirect branch or return instruction in the victim code is vulnerable to this Contributions attack and hence we do not attempt to mitigate these attacks in oo7. There exist potential solutions such as Retpoline [9] The contributions of this paper can be summarized as fol- or RSB refilling [10] for these vulnerabilities. lows. First, we present a program analysis based approach (c) Transient out-of order execution: These attacks can be called oo7 for mitigating Spectre attacks. Our solution is directly launched by a malicious code (malware) without based on binary analysis and does not involve changes the requirement of any specific vulnerable code fragment or to the underlying operating system and hardware. It uses pattern in the victim process. Since the objective of oo7 is taint analysis, address analysis and speculation modeling to to detect and repair vulnerable code fragments in general check potentially vulnerable program binaries, and inserts software, the detection of malware is orthogonal to the a small number of fences to mitigate the risks of Spectre objective of oo7. Thus, we do not consider the detection of attack. Our approach is accurate in identifying all the litmus Spectre-style malicious code fragments in this work. tests for Spectre vulnerabilities [1], has low performance Unlike the first class of attacks where the defense mech- overhead (average 5.9% overhead for SPECint benchmark anism is to harden the victim software, here oo7 performs suite), and is scalable as evidenced by our analysis of over malware detection, i.e., it looks for malicious code patterns 500 large program binaries. within a binary. The main contribution of this work is in proposing and demonstrating an efficient static analysis based approach 2.1 Vulnerability in Victim Code to accurately locate potential Spectre vulnerability in the Spectre Variant 1: The following victim code frag- code and then use well-established repair strategy (fences) ment exhibits Spectre vulnerability Variant 1. to fix these selected vulnerable code fragments. We have void