Results 1 - 10
of
53
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 95 (9 self)
- Add to MetaCart
(Show Context)
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.
Jump-Oriented Programming: A New Class of Code-Reuse Attack
- NC State University
, 2010
"... Return-oriented programming is an effective code-reuse attack in which short code sequences ending in a ret instruction are found within existing binaries and executed in arbitrary order by taking control of the stack. This allows for Turing-complete behavior in the target program without the need f ..."
Abstract
-
Cited by 66 (2 self)
- Add to MetaCart
(Show Context)
Return-oriented programming is an effective code-reuse attack in which short code sequences ending in a ret instruction are found within existing binaries and executed in arbitrary order by taking control of the stack. This allows for Turing-complete behavior in the target program without the need for injecting attack code, thus significantly negating current code injection defense efforts (e.g., W⊕X). On the other hand, its inherent characteristics, such as the reliance on the stack and the consecutive execution of returnoriented gadgets, have prompted a variety of defenses to detect or prevent it from happening. In this paper, we introduce a new class of code-reuse attack, called jump-oriented programming. This new attack eliminates the reliance on the stack and ret instructions (including ret-like instructions such as pop+jmp) seen in return-oriented programming without sacrificing expressive power. This attack still builds and chains functional gadgets, each performing certain primitive operations, except these gadgets end in an indirect branch rather than ret. Without the convenience of using ret to unify them, the attack relies on a dispatcher gadget to dispatch and execute the functional gadgets. We have successfully identified the availability of these jump-oriented gadgets in the GNU libc library. Our experience with an example shellcode attack demonstrates the practicality and effectiveness of this technique. 1.
Binary stirring: Self-randomizing instruction addresses of legacy x86 binary code
- In Proc. ACM Conf. Computer and Communications Security
, 2012
"... Unlike library code, whose instruction addresses can be randomized by address space layout randomization (ASLR), application binary code often has static instruction addresses. Attackers can exploit this limitation to craft robust shell codes for such applications, as demonstrated by a recent attack ..."
Abstract
-
Cited by 60 (4 self)
- Add to MetaCart
(Show Context)
Unlike library code, whose instruction addresses can be randomized by address space layout randomization (ASLR), application binary code often has static instruction addresses. Attackers can exploit this limitation to craft robust shell codes for such applications, as demonstrated by a recent attack that reuses instruction gadgets from the static binary code of victim applications. This paper introduces binary stirring, a new technique that imbues x86 native code with the ability to self-randomize its instruction addresses each time it is launched. The input to STIR is only the application binary code without any source code, debug symbols, or relocation information. The output is a new binary whose basic block addresses are dynamically determined at load-time. Therefore, even if an attacker can find code gadgets in one instance of the binary, the instruction addresses in other instances are unpredictable. An array of binary transformation techniques enable STIR to transparently protect large, realistic applications that cannot be perfectly disassembled due to computed jumps, code-data interleaving, OS callbacks, dynamic linking and a variety of other difficult binary features. Evaluation of STIR for both Windows and Linux platforms shows that stirring introduces about 1.6 % overhead on average to application runtimes.
Smashing the Gadgets: Hindering Return-Oriented Programming Using In-Place Code Randomization
"... Abstract—The wide adoption of non-executable page protections in recent versions of popular operating systems has given rise to attacks that employ return-oriented programming (ROP) to achieve arbitrary code execution without the injection of any code. Existing defenses against ROP exploits either r ..."
Abstract
-
Cited by 56 (9 self)
- Add to MetaCart
(Show Context)
Abstract—The wide adoption of non-executable page protections in recent versions of popular operating systems has given rise to attacks that employ return-oriented programming (ROP) to achieve arbitrary code execution without the injection of any code. Existing defenses against ROP exploits either require source code or symbolic debugging information, or impose a significant runtime overhead, which limits their applicability for the protection of third-party applications. In this paper we present in-place code randomization, a practical mitigation technique against ROP attacks that can be applied directly on third-party software. Our method uses various narrow-scope code transformations that can be applied statically, without changing the location of basic blocks, allowing the safe randomization of stripped binaries even with partial disassembly coverage. These transformations effectively eliminate about 10%, and probabilistically break about 80 % of the useful instruction sequences found in a large set of PE files. Since no additional code is inserted, in-place code randomization does not incur any measurable runtime overhead, enabling it to be easily used in tandem with existing exploit mitigations such as address space layout randomization. Our evaluation using publicly available ROP exploits and two ROP code generation toolkits demonstrates that our technique prevents the exploitation of the tested vulnerable Windows 7 applications, including Adobe Reader, as well as the automated construction of alternative ROP payloads that aim to circumvent in-place code randomization using solely any remaining unaffected instruction sequences. I.
Control Flow Integrity for COTS Binaries
"... Control-Flow Integrity (CFI) has been recognized as an important low-level security property. Its enforcement can defeat most injected and existing code attacks, including those based on Return-Oriented Programming (ROP). Previous implementations of CFI have required compiler support or the presence ..."
Abstract
-
Cited by 55 (2 self)
- Add to MetaCart
(Show Context)
Control-Flow Integrity (CFI) has been recognized as an important low-level security property. Its enforcement can defeat most injected and existing code attacks, including those based on Return-Oriented Programming (ROP). Previous implementations of CFI have required compiler support or the presence of relocation or debug information in the binary. In contrast, we present a technique for applying CFI to stripped binaries on x86/Linux. Ours is the first work to apply CFI to complex shared libraries such as glibc. Through experimental evaluation, we demonstrate that our CFI implementation is effective against control-flow hijack attacks, and eliminates the vast majority of ROP gadgets. To achieve this result, we have developed robust techniques for disassembly, static analysis, and transformation of large binaries. Our techniques have been tested on over 300MB of binaries (executables and shared libraries).
Just-intime code reuse: On the effectiveness of fine-grained address space layout randomization
- In Proceedings of the 34th IEEE Symposium on Security & Privacy (S&P
, 2013
"... Abstract—Fine-grained address space layout randomization (ASLR) has recently been proposed as a method of efficiently mitigating runtime attacks. In this paper, we introduce the design and implementation of a framework based on a novel attack strategy, dubbed just-in-time code reuse, that undermines ..."
Abstract
-
Cited by 49 (2 self)
- Add to MetaCart
(Show Context)
Abstract—Fine-grained address space layout randomization (ASLR) has recently been proposed as a method of efficiently mitigating runtime attacks. In this paper, we introduce the design and implementation of a framework based on a novel attack strategy, dubbed just-in-time code reuse, that undermines the benefits of fine-grained ASLR. Specifically, we derail the assumptions embodied in fine-grained ASLR by exploiting the ability to repeatedly abuse a memory disclosure to map an application’s memory layout on-the-fly, dynamically discover API functions and gadgets, and JIT-compile a target program using those gadgets—all within a script environment at the time an exploit is launched. We demonstrate the power of our framework by using it in conjunction with a real-world exploit against Internet Explorer, and also provide extensive evaluations that demonstrate the practicality of just-in-time code reuse attacks. Our findings suggest that fine-grained ASLR may not be as promising as first thought. I.
ROPdefender: A detection tool to defend against return-oriented programming attacks
, 2010
"... Return-oriented programming (ROP) is a technique that enables an adversary to construct malicious programs with the desired behavior by combining short instruction sequences that already reside in the memory space of a program. ROP attacks have already been demonstrated on various processor architec ..."
Abstract
-
Cited by 48 (5 self)
- Add to MetaCart
(Show Context)
Return-oriented programming (ROP) is a technique that enables an adversary to construct malicious programs with the desired behavior by combining short instruction sequences that already reside in the memory space of a program. ROP attacks have already been demonstrated on various processor architectures ranging from PCs to smartphones and special-purpose systems. In this paper, we present our tool, ROPdefender, that dynamically detects conventional ROP attacks (that are based on return instructions) with a reasonable runtime overhead of 2x. In contrast to existing solutions, (i) ROPdefender does not rely on side information (e.g., source code or debugging information) and (ii) it instruments all return instructions issued during program execution including all returns from dynamic libraries, even if the adversary subverts the control-flow by other means. Moreover, ROPdefender can handle Unix signals, non-local control transfers, C++ exceptions, lazy binding, and can be applied to multi-threaded applications such as Mozilla Firefox or Acrobat Reader. Finally our implementation supports mainstream operating systems (Windows and Linux) for the Intel x86 architecture. As proof of concept we show that ROPdefender successfully detects recent Acrobat Reader exploits on Windows.
Out of control: Overcoming control-flow integrity
- In IEEE Symposium on Security and Privacy
, 2014
"... Abstract—As existing defenses like ALSR, DEP, and stack cookies are not sufficient to stop determined attackers from exploiting our software, interest in Control Flow Integrity (CFI) is growing. In its ideal form, CFI prevents any flow of control that was not intended by the original program, effect ..."
Abstract
-
Cited by 42 (4 self)
- Add to MetaCart
Abstract—As existing defenses like ALSR, DEP, and stack cookies are not sufficient to stop determined attackers from exploiting our software, interest in Control Flow Integrity (CFI) is growing. In its ideal form, CFI prevents any flow of control that was not intended by the original program, effectively putting a stop to exploitation based on return oriented programming (and many other attacks besides). Two main problems have prevented CFI from being deployed in practice. First, many CFI implementations require source code or debug information that is typically not available for commercial software. Second, in its ideal form, the technique is very expensive. It is for this reason that current research efforts focus on making CFI fast and practical. Specifically, much of the work on practical CFI is applicable to binaries, and improves performance by enforcing a looser notion of control flow integrity. In this paper, we examine the security implications of such looser notions of CFI: are they still able to prevent code reuse attacks, and if not, how hard is it to bypass its protection? Specifically, we show that with two new types of gadgets, return oriented programming is still possible. We assess the availability of our gadget sets, and demonstrate the practicality of these results with a practical exploit against Internet Explorer that bypasses modern CFI implementations. Keywords—Control-flow integrity evaluation, code-reuse attack I.
Return-Oriented Programming: Systems, Languages, and Applications
"... This paper explores “return-oriented programming, ” a technique by which an attacker can induce arbitrary behavior in a program whose control flow he has diverted — without injecting any code. A Return-oriented program chains together short instruction sequences already present in a program’s addres ..."
Abstract
-
Cited by 35 (4 self)
- Add to MetaCart
This paper explores “return-oriented programming, ” a technique by which an attacker can induce arbitrary behavior in a program whose control flow he has diverted — without injecting any code. A Return-oriented program chains together short instruction sequences already present in a program’s address space, each of which ends in a “return ” instruction. Return-oriented programming defeats the W⊕X protections recently deployed by Microsoft, Intel, and AMD; in this context, it can be seen as a generalization of traditional “return-into-libc” attacks. But the threat is more general: return-oriented programming is readily exploitable on multiple architectures, and bypasses an entire category of malware protections. To demonstrate the wide applicability of return-oriented programming, we construct a Turingcomplete set of building blocks called gadgets using the standard C library from each of two very different architectures: Linux/x86 and Solaris/SPARC. To demonstrate the power of returnoriented programming, we present a high-level, general-purpose language for describing returnoriented exploits and a compiler that translates it to gadgets. We argue that the threat posed by return-oriented programming, across all architectures and systems, has negative implications for an entire class of security mechanisms: those that seek to prevent malicious computation by preventing the execution of malicious code.
On the expressiveness of return-into-libc attacks
- In Recent Advances in Intrusion Detection
, 2011
"... Abstract. Return-into-libc (RILC) is one of the most common forms of code-reuse attacks. In this attack, an intruder uses a buffer overflow or other exploit to redirect control flow through existing (libc) functions within the legitimate program. While dangerous, it is generally consid-ered limited ..."
Abstract
-
Cited by 30 (0 self)
- Add to MetaCart
(Show Context)
Abstract. Return-into-libc (RILC) is one of the most common forms of code-reuse attacks. In this attack, an intruder uses a buffer overflow or other exploit to redirect control flow through existing (libc) functions within the legitimate program. While dangerous, it is generally consid-ered limited in its expressive power since it only allows the attacker to ex-ecute straight-line code. In other words, RILC attacks are believed to be incapable of arbitrary computation—they are not Turing complete. Con-sequently, to address this limitation, researchers have developed other code-reuse techniques, such as return-oriented programming (ROP). In this paper, we make the counterargument and demonstrate that the orig-inal RILC technique is indeed Turing complete. Specifically, we present a generalized RILC attack called Turing complete RILC (TC-RILC) that allows for arbitrary computations. We demonstrate that TC-RILC sat-isfies formal requirements of Turing-completeness. In addition, because it depends on the well-defined semantics of libc functions, we also show that a TC-RILC attack can be portable between different versions (or even different families) of operating systems and naturally has negative implications for some existing anti-ROP defenses. The development of TC-RILC on both Linux and Windows platforms demonstrates the ex-pressiveness and practicality of the generalized RILC attack.
