Surgically Returning to Randomized lib(c)

Roglia, Giampaolo Fresi; Martignoni, Lorenzo; Paleari, Roberto; Bruschi, Danilo

doi:10.1109/acsac.2009.16

Cited by 85 publications

(44 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, there are several attacks which can bypass or seriously limit ASLR, especially on the 32-bit x86 architecture [1]. Additionally, ASLR can be defeated by leakage of sensitive information about the memory layout of the process [30]. Therefore, while ASLR is certainly useful, it is not a silver bullet to the problem of code-reuse attacks.…”

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

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

show abstract

“…Even when using dynamically-linked libraries, it is common for the main program text to start at a known fixed location. Because of these limitations, ASLR-protected code is subject to attack [5,22,27].…”

Section: Instruction Location Transformation (Ilx)mentioning

confidence: 99%

Kevlar: Transitioning Helix for Research to Practice

Davidson¹,

Knight²,

Co³

et al. 2016

View full text Add to dashboard Cite

“…It is important to point out that we do not make any assumptions about the attacker's methodology of executing malicious code. Thus, in our model, the attacker can utilize all the known ways of executing malicious code, i.e., injecting malicious shellcode in the process' address space [3,12], return2libc attacks [14,32] and return-oriented programming [10,33].…”

Section: Control-data Attacksmentioning

confidence: 99%

HeapSentry: Kernel-Assisted Protection against Heap Overflows

Nikiforakis

Piessens

Joosen

2013

Detection of Intrusions and Malware, and Vulnerability Assessment

View full text Add to dashboard Cite

The last twenty years have witnessed the constant reaction of the security community to memory corruption attacks and the evolution of attacking techniques in order to circumvent the newly-deployed countermeasures. In this evolution, the heap of a process received little attention and thus today, the problem of heap overflows is largely unsolved.In this paper we present HeapSentry, a system designed to detect and stop heap overflow attacks through the cooperation of the memory allocation library of a program and the operating system's kernel. HeapSentry places unique random canaries at the end of each heap object which are later checked by the kernel, before system calls are allowed to proceed. HeapSentry operates on binaries (no source code needed) and has, by design, no false-positives. At the same time, the active involvement of the kernel provides stronger security guarantees than the current state of the art in heap protection mechanisms for a modest performance overhead.

show abstract

Surgically Returning to Randomized lib(c)

Cited by 85 publications

References 5 publications

On the Expressiveness of Return-into-libc Attacks

On the Expressiveness of Return-into-libc Attacks

Kevlar: Transitioning Helix for Research to Practice

HeapSentry: Kernel-Assisted Protection against Heap Overflows

Contact Info

Product

Resources

About