RAD: a compile-time solution to buffer overflow attacks

Chiueh, Tzi‐cker; Hsu, Fu-Hau

doi:10.1109/icdsc.2001.918971

Cited by 105 publications

(38 citation statements)

References 1 publication

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Under such situation, researchers have developed several preventions which relied upon particular attributes of ROP attack, such as the frequency of ret instructions [6,7] or reliance on the protection of control flow data on the stack (e.g., return address) [8,9,10,11,12]. However, recent advancement in ROP has revealed that it need not rely on the stack [13] or the ret instructions to govern control flow [14], thus making those defenses ineffective.…”

Section: Introductionmentioning

confidence: 99%

Code Reuse Prevention through Control Flow Lazily Check

Chen

Jiang

Zhang

2012

2012 IEEE 18th Pacific Rim International Symposium on Dependable Computing

View full text Add to dashboard Cite

Despite the numerous prevention and protection techniques that have been developed, the exploitation of memory corruption vulnerabilities still represents a serious threat to the security of software systems and networks. Because of the adoption of the write or execute only policy (W X) and address space layout randomization (ASLR), modern operate systems have been strengthened against code injection attacks. However, attackers have responded by employing code reuse attacks, in which software vulnerability is exploited to weave control flow through existing code base. Solutions targeting different aspects of the attack itself have had some success, but none of them can be a silver bullet. Under this situation, it is necessary to develop a general prevention to mitigate code reuse attacks.In this paper, we present a novel and general defense technique called control flow lazily check (CFLC), which allows for effective enforcement of control flow integrity. Specifically, instead of immediately determining the violation of control flow before the control flow transfer takes place, CFLC detects the violation after the transfer. Further, CFLC ensures that no deviation can be used to bypass the checking code and craft a malicious system call neither. To reduce the performance overhead, we introduce a coarse-grained CFLC based on the principle that a success intrusion must invoke a system call. We have implemented CFLC with the help of dynamic binary instrumentation tool and the evaluation demonstrates that CFLC can not only prevent code reuse attacks but also code injection attacks. It is shown that CFLC has achieved significant safety than other existing defenses with a modest performance penalty.

show abstract

Section: Introductionmentioning

confidence: 99%

Code Reuse Prevention through Control Flow Lazily Check

Chen

Jiang

Zhang

2012

2012 IEEE 18th Pacific Rim International Symposium on Dependable Computing

View full text Add to dashboard Cite

show abstract

“…ROPDefender [7] rewrites binaries to maintain a shadow stack in order to verify each return address. This builds upon previous work in stack protection, including other shadow stack system [8,9,10], as well as canary-based stack protection such as StackGuard [22]. Systems like DROP [4] and DynIMA [5] can detect a ROPbased attack based on the short length of ROP gadgets, which results in a very high frequency of ret instructions being encountered.…”

Section: Code-reuse Attacksmentioning

confidence: 99%

“…In this technique, so-called gadgets (small snippets of code ending in ret) are weaved together in arbitrary ways to achieve Turing complete computation without code injection. In response to this threat, researchers developed defenses which relied upon particular attributes of this attack, such as the the frequency of ret instructions [4,5] or reliance on the stack [6,7,8,9,10]. Unfortunately, recent evidence has revealed that code-reuse attacks need not rely on the stack or the ret instruction to govern control flow, negating these defenses [11,12].…”

Section: Introductionmentioning

confidence: 99%

Mitigating code-reuse attacks with control-flow locking

Bletsch

Jiang

Freeh

2011

Proceedings of the 27th Annual Computer Security Applications Conference

112

View full text Add to dashboard Cite

Code-reuse attacks are software exploits in which an attacker directs control flow through existing code with a malicious result. One such technique, return-oriented programming, is based on "gadgets" (short pre-existing sequences of code ending in a ret instruction) being executed in arbitrary order as a result of a stack corruption exploit. Many existing codereuse defenses have relied upon a particular attribute of the attack in question (e.g., the frequency of ret instructions in a return-oriented attack), which leads to an incomplete protection, while a smaller number of efforts in protecting all exploitable control flow transfers suffer from limited deployability due to high performance overhead. In this paper, we present a novel cost-effective defense technique called control flow locking, which allows for effective enforcement of control flow integrity with a small performance overhead. Specifically, instead of immediately determining whether a control flow violation happens before the control flow transfer takes place, control flow locking lazily detects the violation after the transfer. To still restrict attackers' capability, our scheme guarantees that the deviation of the normal control flow graph will only occur at most once. Further, our scheme ensures that this deviation cannot be used to craft a malicious system call, which denies any potential gains an attacker might obtain from what is permitted in the threat model. We have developed a proof-of-concept prototype in Linux and our evaluation demonstrates desirable effectiveness and competitive performance overhead with existing techniques. In several benchmarks, our scheme is able to achieve significant gains.

show abstract

“…For instance, ROPDefender [22] rewrites existing binaries to record a separate shadow stack which is used to verify that each return address is valid; this prevents return-based attacks, including both ROP and RILC. Other systems also make use of a shadow stack, either in hardware or software, and can be used to similarly enforce stack integrity [23][24][25].…”

Section: Related Workmentioning

confidence: 99%

On the Expressiveness of Return-into-libc Attacks

Tran

Etheridge

Bletsch

et al. 2011

Lecture Notes in Computer Science

111

View full text Add to dashboard Cite

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 considered limited in its expressive power since it only allows the attacker to execute straight-line code. In other words, RILC attacks are believed to be incapable of arbitrary computation-they are not Turing complete. Consequently, 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 original 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 satisfies 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 expressiveness and practicality of the generalized RILC attack.

show abstract

RAD: a compile-time solution to buffer overflow attacks

Cited by 105 publications

References 1 publication

Code Reuse Prevention through Control Flow Lazily Check

Code Reuse Prevention through Control Flow Lazily Check

Mitigating code-reuse attacks with control-flow locking

On the Expressiveness of Return-into-libc Attacks

Contact Info

Product

Resources

About