Record-Replay Architecture As a General Security Framework
Total Page:16
File Type:pdf, Size:1020Kb
Record-Replay Architecture as a General Security Framework Yasser Shalabi, Mengjia Yan, Nima Honarmand,† Ruby B. Lee,‡ and Josep Torrellas University of Illinois at Urbana-Champaign †Stony Brook University ‡Princeton University http://[email protected] [email protected] [email protected] ABSTRACT An intriguing primitive that can help defend against secu- Hardware security features need to strike a careful balance rity threats is Record and Deterministic Replay (RnR) (e.g., between design intrusiveness and completeness of methods. [6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, In addition, they need to be flexible, as security threats con- 22]). With RnR, a workload’s initial execution creates a log, tinuously evolve. To help address these requirements, this which can be deterministically replayed on another machine. paper proposes a novel framework where Record and Deter- RnR has been used for security purposes, most often off-line, ministic Replay (RnR) is used to complement hardware se- to provide insight into how and when an attack took place curity features. We call the framework RnR-Safe. RnR-Safe (e.g., [8, 11]). reduces the cost of security hardware by allowing it to be In this paper, we explore an approach to hardware secu- less precise at detecting attacks, potentially reporting false rity design where RnR is used to complement hardware se- positives. This is because it relies on on-the-fly replay that curity features—to offload intrusion checks and/or to elimi- transparently verifies whether the alarm is a real attack or nate check imprecision. We call the framework RnR-Safe. In a false positive. RnR-Safe uses two replayers: an always- RnR-Safe, we reduce the cost of security hardware, by al- on, fast Checkpoint replayer that periodically creates check- lowing the hardware to be less precise at detecting attacks, points, and a detailed-analysis Alarm replayer that is trig- potentially reporting false positives. This is because we rely gered when there is a threat alarm. on an on-the-fly replayer that transparently verifies whether As an example application, we use RnR-Safe to thwart the alarm is a real attack or a false positive. The result is a Return Oriented Programming (ROP) attacks, including on very general security framework that can be combined with the Linux kernel. Our design augments the Return Address a variety of relatively inexpensive security hardware. Stack (RAS) with relatively inexpensive hardware. We eval- RnR-Safe relies on two types of on-the-fly replayers run- uate RnR-Safe using a variety of workloads on virtual ma- ning on a different machine: an always-on fast replayer that chines running Linux. We find that RnR-Safe is very effec- periodically creates checkpoints of the monitored execution tive. Thanks to the judicious RAS hardware extensions and (Checkpointing replayer), and an analyzing replayer—triggered hypervisor changes, the checkpointing replayer has an exe- by an alarm—that starts from a checkpoint and analyzes the cution speed comparable to the recorded execution. Also, the execution to determine whether the alarm was due to a real alarm replayer needs to handle very few false positives. attack or a false positive (Alarm replayer). The alarm re- player can execute multiple times, with different levels of Keywords: Record and Deterministic Replay; Hardware Se- analysis, until the attack is fully understood. curity; Return Oriented Programming. As an example application, this paper then applies this ap- proach to thwart ROP attacks—including on the kernel, a 1. INTRODUCTION challenging target to defend. A ROP attack causes a Return Address Stack (RAS) misprediction. However, a RAS mis- As security attacks become more frequent and varied, there prediction is an imprecise ROP detector, as it may also occur is increasing interest in augmenting processor and system for benign software. Hence, rather than augmenting the RAS hardware with security features. As a result, processor man- hardware to guarantee perfect detection, RnR-Safe makes ufacturers have developed new hardware architectures, such simple modifications to the RAS hardware to eliminate the as Intel’s MPX [1], AMD’s Secure Processor [2], and ARM vast majority of the false positives. The few remaining false TrustZone technology [3]. positives are identified by the alarm replayer, thus minimiz- A general difficulty in this area is that security threats ing hardware changes. This follows the RnR philosophy. are continuously evolving, circumventing existing security To evaluate RnR-Safe, we execute a set of varied work- defenses. What used to be an effective defense yesterday loads on Virtual Machines (VMs) running Linux. We find is less effective today. Hence, defense systems have to be that RnR-Safe is an effective hardware-software co-design flexible. For example, to defend against code injection at- point. Thanks to the judicious RAS hardware extensions and tacks, W⊕X features [2, 4] have been widely deployed in hypervisor changes, the checkpointing replayer has a speed processors. They prevent the execution of data by enforc- that is comparable to that of the recorder, and can be replay- ing the invariant that memory pages are either executable or ing continuously. In addition, the alarm replayer has to han- writable, but never both. Unfortunately, new attacks have ap- dle only very few false positives. peared that do not need code injection. In particular, an attack The contribution of this paper is threefold. First, we pro- based on code reuse called Return Oriented Programming pose a novel RnR-based hardware-software approach to en- (ROP) [5] is now the preferred technique. It builds attack hance security called RnR-Safe. Second, we tailor RnR-Safe code by chaining together multiple snippets of code from the to detect ROPs—with a focus in the kernel—and discuss the victim program, hence bypassing W⊕X defenses. challenges encountered during its implementation. Finally, 2.2 Example Threat: Return Oriented Program- we evaluate RnR-Safe in this use. ming (ROP) Assumed System and Threat Models. ROP attacks can oc- RnR-Safe is a general framework that can be used to thwart cur within the kernel or user contexts, and RnR-Safe can se- a variety of attacks. As an illustration, in this paper, we con- cure both. The target most difficult to secure is the kernel, sider ROP [5] attacks, focusing on those on the kernel. Ap- as it is privileged and multi-context. The protected system pendix A describes ROP attacks. (kernel and applications) runs inside a VM whose execution At a high level, ROP attacks can be detected with a struc- is continuously recorded. The recorded execution is concur- ture called Shadow Stack (e.g., [27, 28, 29, 30]). When a call rently being replayed on a different machine, where ROP at- instruction is executed, the address of the instruction follow- tacks may be uncovered. ing the call is pushed to the shadow stack. At return instruc- We assume the attacker can launch a ROP attack against tions, the top of the shadow stack is popped. ROP attacks the kernel via any combination of address disclosure and can be detected when the return address used by the proces- memory corruption vulnerabilities to hijack and corrupt the sor mismatches the one popped from the shadow stack. kernel stack. We assume that the host machine OS and hyper- However, shadow stacks present several implementation visor (in the recording and replaying machines) are benign, challenges. First, the validity of the shadow stack hinges on and that they can safeguard against compromised guest VMs its integrity. Hence, the shadow stack must be secured against through traditional memory page permissions. the very software it protects. This includes protecting it against the kernel itself, which might be compromised and mali- cious. Also, codes can be highly nested (e.g., recursive), multi- 2. BACKGROUND context (e.g., the kernel), or imperfectly nested (e.g., error and exception handling). Since false positives are unaccept- 2.1 Record and Replay able, proper handling of all these corner cases is necessary. Most solutions add instructions to manipulate the shadow Record and deterministic Replay (RnR) of workloads is a stack in these cases. Such instructions, even if privileged, popular architectural technique (e.g., [6, 7, 8, 9, 10, 11, 12, provide a security vulnerability. 13, 14, 15, 16, 17, 18, 19, 20, 21, 22]). As a workload runs, There have been a variety of approaches that focus on pro- RnR records all the non-deterministic events that can affect tection against ROP attacks (e.g., [31, 32, 28, 29, 30, 27, 33, the execution and stores them in a log. Then, in a poten- 34, 35, 36, 37, 38, 39, 40]). Unfortunately, while some of tially different platform, the workload is re-run. At this time, them are provable prevention techniques, they appear insuf- the system injects the recorded events at the correct times, ficient from a practical point of view. Indeed, it is a matter enforcing a deterministic execution (Replay). Typically, the of fact that systems today still remain vulnerable to such at- non-deterministic events are the inputs to the workload and, tacks. We discuss the reasons in the next section. in parallel programs, the interleaving of memory accesses. RnR can be done at different abstraction layers. In this work, we use VM-level RnR [7, 8, 15, 14]. Moreover, we 2.3 ROP is Still Unsolved Today consider uniprocessor hardware. As a result, the sources of There are three reasons why existing ROP protection tech- non-determinism are interrupts raised and data copied by niques have limitations from a practical point of view: virtual devices into the guest machine. We also assume the Hardware Intrusiveness. Some approaches [27, 28, 34, 37] widely used model of hypervisor-mediated I/O, as used in require intrusive hardware changes.