SoK: Eternal War in Memory

117

Abstract-Memory corruption attacks continue to be a major vector of attack for compromising modern systems. Numerous defenses have been proposed against memory corruption attacks, but they all have their limitations and weaknesses. Stronger defenses such as complete memory safety for legacy languages (C/C++) incur a large overhead, while weaker ones such as practical control flow integrity have been shown to be ineffective. A recent technique called code pointer integrity (CPI) promises to balance security and performance by focusing memory safety on code pointers thus preventing most control-hijacking attacks while maintaining low overhead. CPI protects access to code pointers by storing them in a safe region that is protected by instruction level isolation. On x86-32, this isolation is enforced by hardware; on x86-64 and ARM, isolation is enforced by information hiding. We show that, for architectures that do not support segmentation in which CPI relies on information hiding, CPI's safe region can be leaked and then maliciously modified by using data pointer overwrites. We implement a proofof-concept exploit against Nginx and successfully bypass CPI implementations that rely on information hiding in 6 seconds with 13 observed crashes. We also present an attack that generates no crashes and is able to bypass CPI in 98 hours. Our attack demonstrates the importance of adequately protecting secrets in security mechanisms and the dangers of relying on difficulty of guessing without guaranteeing the absence of memory leaks.

Section: Introductionmentioning

confidence: 99%

Missing the Point(er): On the Effectiveness of Code Pointer Integrity

Evans

Fingeret

González

et al. 2015

117

“…Such violations are a common source of serious security vulnerabilities [12], [81] such as heap-based buffer overflows [1], [5], [33], [72], [76], confidential data leaks [4], and exploitable use-after-free [3], [10], and doublefree bugs [2], [41]. The micro-policy we study here only guards heap-allocated data, for which calls to the malloc and free monitor services tell us how to set up and tear down memory regions; we leave stack allocation and C-like unboxed structs as future work.…”

Section: Memory Safety Micro-policymentioning

confidence: 99%

Micro-Policies: Formally Verified, Tag-Based Security Monitors

Amorim¹,

Dénès

Giannarakis

et al. 2015

Abstract-Recent advances in hardware design have demonstrated mechanisms allowing a wide range of low-level security policies (or micro-policies) to be expressed using rules on metadata tags. We propose a methodology for defining and reasoning about such tag-based reference monitors in terms of a high-level "symbolic machine," and we use this methodology to define and formally verify micro-policies for dynamic sealing, compartmentalization, control-flow integrity, and memory safety; in addition, we show how to use the tagging mechanism to protect its own integrity. For each micro-policy, we prove by refinement that the symbolic machine instantiated with the policy's rules embodies a high-level specification characterizing a useful security property. Last, we show how the symbolic machine itself can be implemented in terms of a hardware rule cache and a software controller.

“…DEP has to manage the executable flag, which is essentially a form of annotation or metadata, and it requires a (hardware) check before each critical operation, i.e., before executing an instruction. For less than 1% overhead, DEP protects against basic forms of remote code execution attacks, but it can be circumvented relatively easily using more elaborate attacks based on "return-oriented programming" [35].…”

Section: Background and Related Workmentioning

confidence: 99%

“…Stack canaries incur below 1% overhead. They offer some protection against simple buffer overflows, but they can be neutralized by modifying attacks, e.g., by directly overriding the return address [35].…”

Section: Background and Related Workmentioning

confidence: 99%

High System-Code Security with Low Overhead

Wagner

Kuznetsov

Candea

et al. 2015

Abstract-Security vulnerabilities plague modern systems because writing secure systems code is hard. Promising approaches can retrofit security automatically via runtime checks that implement the desired security policy; these checks guard critical operations, like memory accesses. Alas, the induced slowdown usually exceeds by a wide margin what system users are willing to tolerate in production, so these tools are hardly ever used. As a result, the insecurity of real-world systems persists.We present an approach in which developers/operators can specify what level of overhead they find acceptable for a given workload (e.g., 5%); our proposed tool ASAP then automatically instruments the program to maximize its security while staying within the specified "overhead budget." Two insights make this approach effective: most overhead in existing tools is due to only a few "hot" checks, whereas the checks most useful to security are typically "cold" and cheap.We evaluate ASAP on programs from the Phoronix and SPEC benchmark suites. It can precisely select the best points in the security-performance spectrum. Moreover, we analyzed existing bugs and security vulnerabilities in RIPE, OpenSSL, and the Python interpreter, and found that the protection level offered by the ASAP approach is sufficient to protect against all of them.