Virtual Ghost: Protecting Applications from Hostile Operating Systems
Total Page:16
File Type:pdf, Size:1020Kb
Virtual Ghost: Protecting Applications from Hostile Operating Systems John Criswell Nathan Dautenhahn Vikram Adve University of Illinois at University of Illinois at University of Illinois at Urbana-Champaign Urbana-Champaign Urbana-Champaign [email protected] [email protected] [email protected] Abstract Categories and Subject Descriptors D.4.6 [Operating Sys- Applications that process sensitive data can be carefully de- tems]: Security and Protection signed and validated to be difficult to attack, but they are General Terms Security usually run on monolithic, commodity operating systems, which may be less secure. An OS compromise gives the Keywords software security; inlined reference monitors; attacker complete access to all of an application’s data, re- software fault isolation; control-flow integrity; malicious op- gardless of how well the application is built. We propose a erating systems new system, Virtual Ghost, that protects applications from a compromised or even hostile OS. Virtual Ghost is the first 1. Introduction system to do so by combining compiler instrumentation and Applications that process sensitive data on modern commod- run-time checks on operating system code, which it uses to ity systems are vulnerable to compromises of the under- create ghost memory that the operating system cannot read lying system software. The applications themselves can be or write. Virtual Ghost interposes a thin hardware abstrac- carefully designed and validated to be impervious to attack. tion layer between the kernel and the hardware that provides However, all major commodity operating systems use large a set of operations that the kernel must use to manipulate monolithic kernels that have complete access to and control hardware, and provides a few trusted services for secure ap- over all system resources [9, 25, 32, 34]. These operating plications such as ghost memory management, encryption systems are prone to attack [21] with large attack surfaces, and signing services, and key management. Unlike previous including large numbers of trusted device drivers developed solutions, Virtual Ghost does not use a higher privilege level by numerous hardware vendors and numerous privileged ap- than the kernel. plications that are as dangerous as the OS itself. A compro- Virtual Ghost performs well compared to previous ap- mise of any of these components or of the kernel gives the proaches; it outperforms InkTag on five out of seven of the attacker complete access to all data belonging to the appli- LMBench microbenchmarks with improvements between cation, whether in memory or offline. Developers of secure 1.3x and 14.3x. For network downloads, Virtual Ghost ex- applications running on such a system generally have no periences a 45% reduction in bandwidth at most for small control over any of these components and must trust them files and nearly no reduction in bandwidth for large files implicitly for their own security. and web traffic. An application we modified to use ghost Several previous projects [11, 16, 22, 37] have created memory shows a maximum additional overhead of 5% due systems that protect applications from a compromised, or to the Virtual Ghost protections. We also demonstrate Vir- even a hostile, operating system. These systems have all tual Ghost’s efficacy by showing how it defeats sophisticated used hardware page protection through a trusted hypervi- rootkit attacks. sor to achieve control over the operating system capabilities. They rely on a technique called shadowing or cloaking that Permission to make digital or hard copies of all or part of this work for personal or automatically encrypts (i.e., shadows or cloaks) and hashes classroom use is granted without fee provided that copies are not made or distributed any application page that is accessed by the operating sys- for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the tem, and then decrypts it and checks the hash when it is next author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or accessed by the application. System call arguments must be republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. copied between secure memory and memory the OS is al- ASPLOS ’14, March 1–5, 2014, Salt Lake City, Utah, USA. lowed to examine. While these solutions are effective, they Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-2305-5/14/03. $15.00. have several drawbacks. First, they rely upon encrypting any http://dx.doi.org/10.1145/2541940.2541986 of an application’s memory that is accessed by the OS; an application cannot improve performance by protecting only Another set of differences from previous work is in the a selected subset of data, or requesting only integrity checks programming model. First, applications can use ghost mem- on data but not confidentiality (i.e., only using hashing and ory selectively for all, some, or none of their data. When not encryption). Second, they assume the OS runs as a guest using it for all their data, the secure features can be obtained on a standard hypervisor, which may not be attractive in transparently via a modified language library (e.g., libc for C certain settings, such as energy-constrained mobile devices. applications), just as in previous work. Second, applications Third, they require that all system call arguments must al- can pass non-ghost memory to system calls without the per- ways be copied, even if the data being transferred is not formance overheads of data copying. Third, when sending security-sensitive, which is the common case in many ap- sensitive data through the operating system (e.g., for I/O), plications. Fourth, these solutions do not provide any secu- ghost applications can choose which encryption and/or cryp- rity benefits to the kernel itself; for example, control flow tographic signing algorithms to use to obtain desired perfor- integrity or memory safety for the operating system kernel mance/security tradeoffs, whereas previous systems gener- cannot reuse the mechanisms developed for shadowing. ally baked this choice into the system design. Finally, a use- We propose a new approach we call ghosting that ad- ful point of similarity with previous work is that the usability dresses all these limitations. Our system, Virtual Ghost, is features provided by previous systems (e.g., secure file sys- the first to enforce application security from a hostile OS us- tem services in InkTag) are orthogonal to the design choices ing compiler instrumentation of operating system code; this in Virtual Ghost and can be directly incorporated. is used to create secure memory called ghost memory, which We have developed a prototype of Virtual Ghost and cannot be read or modified at all by the operating system (in ported the FreeBSD 9.0 kernel to it. To evaluate its effec- contrast, previous systems like Overshadow [11] and Ink- tiveness, we ported three important applications from the Tag [16] do not prevent such writes and only guarantee that OpenSSH application suite to Virtual Ghost, using ghost the tampering will be detected before use by the applica- memory for the heap: ssh, ssh-keygen, and ssh-agent. tion). Virtual Ghost introduces a thin hardware abstraction These three can exchange data securely by sharing a com- layer that provides a set of operations the kernel must use to mon application key, which they use to encrypt the private manipulate hardware, and the secure application can use to authentication keys used by the OpenSSH protocols. obtain essential trusted services for ghost memory manage- Since exploiting a kernel that runs on Virtual Ghost via an ment, encryption, signing, and key management. Although external attack is difficult, we evaluated the effectiveness of the positioning of, and some of the mechanisms in, this layer Virtual Ghost by adding a malicious module to the FreeBSD are similar to a hypervisor, Virtual Ghost is unique because kernel, replacing the read system call handler. This module (a) unlike a traditional hypervisor, there is no software that attempted to perform two different attacks on ssh-agent, runs at a higher privilege level than the kernel – in partic- including a sophisticated one that tries to alter application ular, the hardware abstraction layer runs at the same privi- control flow via signal handler dispatch. When running with- lege level; (b) Virtual Ghost uses (simple, reliable) compiler out Virtual Ghost, both exploits successfully steal the desired techniques rather than hardware page protection to secure its data from ssh-agent. Under Virtual Ghost, both exploits own code and data; and (c) Virtual Ghost completely denies fail and ssh-agent continues execution unaffected. OS accesses to secure memory pages, not just encrypting Our performance results show that Virtual Ghost outper- and signing the pages to detect OS tampering. forms InkTag [16] on five out of seven of the LMBench Moreover, the compiler instrumentation in Virtual Ghost microbenchmarks, with improvements between 1.3x and inherently provides strong protection against external ex- 14.3x. The overheads for applications that perform mod- ploits of the OS. First, traditional exploits, such as those that erate amounts of I/O (thttpd and sshd) is negligible, but the inject binary code, are not even expressible: all OS code must overhead for a completely I/O-dominated application (post- first go through LLVM bitcode form and be translated to na- mark) was high. We are investigating ways to reduce the tive code by the Virtual Ghost compiler. Second, attacks that overhead of postmark. leverage existing native code, like return-oriented program- The rest of the paper is organized as follows.