Dead Store Elimination
Total Page：16
File Type：pdf, Size：1020Kb
Dead Store Elimination (Still) Considered Harmful Zhaomo Yang and Brian Johannesmeyer, University of California, San Diego; Anders Trier Olesen, Aalborg University; Sorin Lerner and Kirill Levchenko, University of California, San Diego https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/yang This paper is included in the Proceedings of the 26th USENIX Security Symposium August 16–18, 2017 • Vancouver, BC, Canada ISBN 978-1-931971-40-9 Open access to the Proceedings of the 26th USENIX Security Symposium is sponsored by USENIX Dead Store Elimination (Still) Considered Harmful Zhaomo Yang1 Brian Johannesmeyer1 Anders Trier Olesen2 Sorin Lerner1 Kirill Levchenko1 1 UC San Diego 2 Aalborg University Abstract being cleared, the compiler determines that the memory Dead store elimination is a widely used compiler op- scrubbing memset has no effect and eliminates it. timization that reduces code size and improves perfor- Removing buffer scrubbing code is an example of mance. However, it can also remove seemingly useless what D’Silva et al. [30] call a “correctness-security gap.” memory writes that the programmer intended to clear From the perspective of the C standard, removing the sensitive data after its last use. Security-savvy develop- memset above is allowed because the contents of un- ers have long been aware of this phenomenon and have reachable memory are not considered part of the seman- devised ways to prevent the compiler from eliminating tics of the C program. However, leaving sensitive data in these data scrubbing operations. memory increases the damage posed by memory disclo- In this paper, we survey the set of techniques found sure vulnerabilities and direct attacks on physical mem- in the wild that are intended to prevent data-scrubbing ory. This leaves gap between what the standard considers operations from being removed during dead store elim- correct and what a security developer might deem cor- ination. We evaluated the effectiveness and availabil- rect. Unfortunately, the C language does not provide a ity of each technique and found that some fail to pro- guaranteed way to achieve what the developer intends, tect data-scrubbing writes. We also examined eleven and attempts to add a memory scrubbing function to the open source security projects to determine whether their C standard library have not seen mainstream adoption. specific memory scrubbing function was effective and Security-conscious developers have been left to devise whether it was used consistently. We found four of the their own means to keep the compiler from optimizing eleven projects using flawed scrubbing techniques that away their scrubbing functions, and this has led to a pro- may fail to scrub sensitive data and an additional four liferation of “secure memset” implementations of vary- projects not using their scrubbing function consistently. ing quality. We address the problem of dead store elimination remov- The aim of this paper is to understand the current state ing scrubbing operations with a compiler-based approach of the dead store elimination problem and developers’ by adding a new option to an LLVM-based compiler attempts to circumvent it. We begin with a survey of ex- that retains scrubbing operations. We also synthesized isting techniques used to scrub memory found in open existing techniques to develop a best-of-breed scrubbing source security projects. Among more than half a dozen function and are making it available to developers. techniques, we found that several are flawed and that 1 Introduction none are both universally available and effective. Next, using a specially instrumented version of the Clang com- Concerns over memory disclosure vulnerabilities in C piler, we analyzed eleven high-profile security projects to and C++ programs have long led security application determine whether their implementation of a scrubbing developers to explicitly scrub sensitive data from mem- function is effective and whether it is used consistently ory. A typical case might look like the following: within the project. We found that only three of the eleven char * password = malloc(PASSWORD_SIZE); projects did so. // ... read and check password To aid the current state of affairs, we developed a memset(password, 0, PASSWORD_SIZE); single best-of-breed scrubbing function that combines free(password); the effective techniques we found in our survey. We The memset is intended to clear the sensitive password have shared our implementation with developers of the buffer after its last use so that a memory disclosure vul- projects we surveyed that lacked a reliable scrubbing nerability could not reveal the password. Unfortunately, function and have made it available to the public. While compilers perform an optimization—called dead store not a perfect solution, we believe ours combines the best elimination (DSE)—that removes stores that have no techniques available today and offers developers a ready- effect on the program result, either because the stored to-use solution for their own projects. value is overwritten or because it is never read again. We also developed a scrubbing aware C compiler In this case, because the buffer is passed to free after based on Clang. Our compiler protects scrubbing oper- USENIX Association 26th USENIX Security Symposium 1025 ations by inhibiting dead store elimination in case where may remain uninitialized and thus leak data if sent to the a store operation may have been intended as a scrubbing outside world. By looking for such data leakage, they operation by the developer. Our solution does not com- found previously undiscovered bugs in the Linux and pletely disable DSE, minimizing the performance impact Android kernels. Wang et al. [38] explore another in- of our mechanism. Our performance evaluation shows stance of the correctness-security gap: compilers some- that our modified compiler introduces virtually no per- times remove code that has undefined behavior that, in formance penalty. some cases, includes security checks. They developed a In total, our contributions are as follows: static checker called STACK that identifies such code in C/C++ programs and they used it to uncover 160 new v We survey scrubbing techniques currently found in the wild, scoring each in terms of its availabil- bugs in commonly deployed systems. ity and reliability. In particular, we identify several Our work examines how developers handle the flawed techniques, which we reported to developers correctness-security gap introduced by aggressive dead of projects relying on them. We also report on the per- store elimination. While the soundness and security of formance of each technique, where we found an order dead store elimination has been studied formally [28, 31, of magnitude difference between the best and worst 29], the aim of our work is to study the phenomenon em- performing techniques. pirically. Bug reports are littered with reports of DSE negatively v We present a case study of eleven security projects affecting program security, as far back as 2002 from Bug that have implemented their own scrubbing function. 8537 in GCC titled “Optimizer Removes Code Neces- We found that no two projects’ scrubbing functions sary for Security” [3], to January 2016 when OpenSSH use the same set of techniques. We also identify com- patched CVE-2016-0777, which allowed a malicious mon pitfalls encountered in real projects. server to read private SSH keys by combining a memory v We develop and make publicly available a best-of- disclosure vulnerability with errant memset and bzero breed scrubbing function that combines the most reli- memory scrubs [10]; or February 2016 when OpenSSL able techniques found in use today. changed its memory scrubbing technique after discussion v We develop a scrubbing-safe dead store elimination in Issue 445 [22]; or Bug 751 in OpenVPN from October optimization pass that protects memory writes in- 2016 about secret data scrubs being optimized away [26]. tended to scrub sensitive data from being eliminated. Despite developers’ awareness of such problems, there Our mechanism has negligible performance overhead is no uniformly-used solution. The CERT C Secure Cod- and can be used without any source code changes. ing Standard [37] recommends SecureZeroMemory as The rest of the paper is organized as follows. Section 2 a Windows solution, memset_s as a C11 solution, and provides background for the rest of the paper and de- the volatile data pointer technique as a C99 solution. Un- scribes the related work. Section 3 surveys the existing fortunately, each of these solutions has problems. The techniques that are used to implement reliable scrubbing Windows solution is not cross-platform. For the rec- functions and then Section 4 evaluates their performance. ommended C11 memset_s solution, to the best of our Section 5 examines the reliability and usage of scrub- knowledge, there is no standard-compliant implemen- bing functions of eleven popular open source applica- tation. Furthermore, while the CERT solution for C99 tions. Section 6 describes our secure_memzero imple- solution may prevent most compilers from removing mentation. Section 7 describes our secure DSE imple- scrubbing operations, the standard does not guarantee mentation and evaluates its performance. Section 8 dis- its correctness [36]. Furthermore, another common tech- cusses our results. Section 9 concludes the paper. nique, using a volatile function pointer, is not guaran- teed to work according to the standard because although 2