Results 1 -
6 of
6
Return-Oriented Programming without Returns
- PROCEEDINGS OF THE 17TH ACM CONFERENCE ON COMPUTER AND COMMUNICATIONS SECURITY (CCS '10)
, 2010
"... We show that on both the x86 and ARM architectures it is possible to mount return-oriented programming attacks without using return instructions. Our attacks instead make use of certain instruction sequences that behave like a return, which occur with sufficient frequency in large libraries on (x86) ..."
Abstract
-
Cited by 13 (2 self)
- Add to MetaCart
We show that on both the x86 and ARM architectures it is possible to mount return-oriented programming attacks without using return instructions. Our attacks instead make use of certain instruction sequences that behave like a return, which occur with sufficient frequency in large libraries on (x86) Linux and (ARM) Android to allow creation of Turing-complete gadget sets. Because they do not make use of return instructions, our new attacks have negative implications for several recently proposed classes of defense against return-oriented programming: those that detect the too-frequent use of returns in the instruction stream; those that detect violations of the last-in, first-out invariant normally maintained for the return-address stack; and those that modify compilers to produce code that avoids the return instruction.
Return-oriented programming without returns on ARM
, 2010
"... In this paper we present a novel and general memory-related attack method on ARM-based computing platforms. Our attack deploys the principles of return-oriented programming (ROP), however, in contrast to conventional ROP, it exploits jumps instead of returns, and hence it can not be detected by retu ..."
Abstract
-
Cited by 4 (2 self)
- Add to MetaCart
In this paper we present a novel and general memory-related attack method on ARM-based computing platforms. Our attack deploys the principles of return-oriented programming (ROP), however, in contrast to conventional ROP, it exploits jumps instead of returns, and hence it can not be detected by return address checkers. Although a similar attack has been recently proposed for Intel x86, it was unclear if the attack technique can be deployed to ARM-based computing platforms as well. Developing a jump-based attack on ARM is more involved, because ARM is based on a RSIC architecture which differs in many aspects from Intel’s x86 architecture. Nevertheless, we show a Turing-complete attack that can induce arbitrary change of behavior in running programs without requiring code injection. As proof of concept, we instantiate our attack method on the Android platform. 1
Weak updates and separation logic
"... Separation logic provides a simple but powerful technique for reasoning about low-level imperative programs that use shared data structures. Unfortunately, separation logic supports only “strong updates”, in which mutation to a heap location is safe only if a unique reference is owned. This limits t ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Separation logic provides a simple but powerful technique for reasoning about low-level imperative programs that use shared data structures. Unfortunately, separation logic supports only “strong updates”, in which mutation to a heap location is safe only if a unique reference is owned. This limits the applicability of separation logic when reasoning about the interaction between many high-level languages (e.g., ML, Java, C#) and low-level ones since the high-level languages do not support strong updates. Instead, they adopt the discipline of “weak updates”, in which there is a global “heap type ” to enforce the invariant of type-preserving heap updates. We present SL w, a logic that extends separation logic with reference types and elegantly reasons about the interaction between strong and weak updates. We describe a semantic framework for reference types, which is used to prove the soundness of SL w. Finally, we show how to extend SL w with concurrency.
Retaining Sandbox Containment Despite Bugs in Privileged Memory-Safe Code
"... Flaws in the standard libraries of secure sandboxes represent a major security threat to billions of devices worldwide. The standard libraries are hard to secure because they frequently need to perform low-level operations that are forbidden in untrusted application code. Existing designs have a sin ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Flaws in the standard libraries of secure sandboxes represent a major security threat to billions of devices worldwide. The standard libraries are hard to secure because they frequently need to perform low-level operations that are forbidden in untrusted application code. Existing designs have a single, large trusted computing base that contains security checks at the boundaries between trusted and untrusted code. Unfortunately, flaws in the standard library often allow an attacker to escape the security protections of the sandbox. In this work, we construct a Python-based sandbox that has a small, security-isolated kernel. Using a mechanism called a security layer, we migrate privileged functionality into memory-safe code on top of the sandbox kernel while retaining isolation. For example, significant portions of module import, file I/O, serialization, and network communication routines can be provided in security layers. By moving these routines out of the kernel, we prevent attackers from leveraging bugs in these routines to evade sandbox containment. We demonstrate the effectiveness of our approach by studying past bugs in Java’s standard libraries and show that most of these bugs would likely be contained in our sandbox.
Privilege Separation for HTML5 Applications
- in Proceedings of the USENIX Security Symposium
, 2012
"... The standard approach for privilege separation in web applications is to execute application components in different web origins. This limits the practicality of privilege separation since each web origin has financial and administrative cost. In this paper, we propose a new design for achieving eff ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
The standard approach for privilege separation in web applications is to execute application components in different web origins. This limits the practicality of privilege separation since each web origin has financial and administrative cost. In this paper, we propose a new design for achieving effective privilege separation in HTML5 applications that shows how applications can cheaply create arbitrary number of components. Our approach utilizes standardized abstractions already implemented in modern browsers. We do not advocate any changes to the underlying browser or require learning new high-level languages, which contrasts prior approaches. We empirically show that we can retrofit our design to real-world HTML5 applications (browser extensions and rich client-side applications) and achieve reduction of 6x to 10000x in TCB for our case studies. Our mechanism requires less than 13 lines of application-specific code changes and considerably improves auditability. 1

