Architectural Support for Run-Time Validation of Control Flow Transfer

Shi, Yixin; Dempsey, S.; Lee, Gyungho

doi:10.1109/iccd.2006.4380863

Cited by 8 publications

(9 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Additionally, these attacks have received considerable attention within the research community. Earlier works such as Program Shepherding [6] have attempted to address control-flow attacks, as well as Control Flow Integrity (CFI) [7] which has inspired many descendant works [8,9,10,11,12,13,14,15]. Adoption of these countermeasures serves to make control-flow increasingly difficult, but ultimately, these countermeasures only represent stumbling blocks for attackers, as they have repeated devised more sophisticated attacks (e.g., heap spray attacks), and blended attacks (e.g., canary key read attacks), such that control flow attacks remain a dire software vulnerability to this day.…”

Section: Control-flow Attacksmentioning

confidence: 99%

Locking down insecure indirection with hardware-based control-data isolation

Arthur

Madeka

Das

et al. 2015

Proceedings of the 48th International Symposium on Microarchitecture

View full text Add to dashboard Cite

Arbitrary code injection pervades as a central issue in computer security where attackers seek to exploit the software attack surface. A key component in many exploits today is the successful execution of a control-flow attack. Control-Data Isolation (CDI) has emerged as a work which eliminates the root cause of contemporary control-flow attacks: indirect control flow instructions. These instructions are replaced by direct control flow edges dictated by the programmer and encoded into the application by the compiler. By subtracting the root cause of control-flow attack, ControlData Isolation sidesteps the vulnerabilities and restrictive threat models adopted by other solutions in this space (e.g., Control-Flow Integrity). The CDI approach, while eliminating contemporary control-flow attacks, introduces non-trivial overheads to validate indirect targets at runtime. In this work we introduce novel architectural support to accelerate the execution of CDIcompliant code. Through the addition of an edge cache, we are able to cache legal indirect target edges and eliminate nearly all execution overhead for indirection-free applications. We demonstrate that through memoization of compiler-confirmed control flow transitions, overheads are reduced from 19% to 0.5% on average for ControlData Isolated applications. Additionally, we show that the edge cache can efficiently provide the double-duty of predicting multi-way branch targets, thus providing even speedups for some CDI-compliant executions, compared to an architecture with unsophisticated indirect control prediction (e.g., BTB). Categories and Subject Descriptors[Security and privacy]: Domain-specific security and privacy architectures, Software security engineering Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Permissions@acm.org.

show abstract

Section: Control-flow Attacksmentioning

confidence: 99%

Locking down insecure indirection with hardware-based control-data isolation

Arthur

Madeka

Das

et al. 2015

Proceedings of the 48th International Symposium on Microarchitecture

View full text Add to dashboard Cite

show abstract

“…Countermeasures such as stack protection, Address Space Layout Randomization (ASLR), and Non-Executable Data (NXD) have been widely adopted. Though many countermeasures have been devised [1,6,7,26,27,30,34], controlflow attacks remain a pervasive threat to computer security [35] due to the persistence of mixing runtime data with program control. Recently, mitigating techniques such as Control Flow Integrity (CFI) [1] and its descendents [33,34], Program Shepherding [17], and taint analysis [13] have been proposed.…”

Section: Control-flow Attacksmentioning

confidence: 99%

“…Contemporary research to protect control-flow has been focused on verifying the user data to be injected into the program counter (PC) [1,6,13,17,26,30,33,34] in an effort to establish trusted user data for control-flow targets. These previous works approach control-flow security by layering additional complexity on top of user data in an effort to shield the vulnerability from attack.…”

Section: Introductionmentioning

confidence: 99%

Getting in control of your control flow with control-data isolation

Arthur

Mehne

Das

et al. 2015

2015 IEEE/ACM International Symposium on Code Generation and Optimization (CGO)

View full text Add to dashboard Cite

Computer security has become a central focus in the information age. Though enormous effort has been expended on ensuring secure computation, software exploitation remains a serious threat. The software attack surface provides many avenues for hijacking; however, most exploits ultimately rely on the successful execution of a control-flow attack. This pervasive diversion of control flow is made possible by the pollution of control flow structure with attacker-injected runtime data.Many control-flow attacks persist because the root of the problem remains: runtime data is allowed to enter the program counter. In this paper, we propose a novel approach: Control-Data Isolation. Our approach provides protection by going to the root of the problem and removing all of the operations that inject runtime data into program control. While previous work relies on CFG edge checking and labeling, these techniques remain vulnerable to attacks such as heap spray, read, or GOT attacks and in some cases suffer high overheads. Rather than addressing control-flow attacks by layering additional complexity, our work takes a subtractive approach; subtracting the primary cause of contemporary control-flow attacks. We demonstrate that control-data isolation can assure the integrity of the programmer's CFG at runtime, while incurring average performance overheads of less than 7% for a wide range of benchmarks.

show abstract

“…There are two ways to collect the records [18]. We can either extract the normal behavior through static analysis of the legacy code, or perform training as many models-based approaches have done [11].…”

Section: B Training the Full Record Set (Frs)mentioning

confidence: 99%

“…If the full record does not completely cover the normal behavior, using it as a reference to validate program execution at run-time will incur false alarms (false positives). Previous works have shown that the number of control flow transfers actually converges quickly as the number of indirect control instructions increases [18]. In our study, we use train-data inputs for SPECINT benchmarks to profile them and to get their FRS.…”

Section: B Training the Full Record Set (Frs)mentioning

confidence: 99%

Leveraging speculative architectures for run-time program validation

Martínez-Santos

Fei

2008

2008 IEEE International Conference on Computer Design

View full text Add to dashboard Cite

Program execution can be tampered by malicious attackers through exploiting software vulnerabilities. Changing the program behavior by compromising control data and decision data has become the most serious threat to computer systems security. Although several hardware approaches have been presented to validate program execution, they mostly suffer great hardware area or poor ambiguity handling. In this paper, we propose a new hardware-based approach by leveraging the existing speculative architectures for run-time program validation. The on-chip branch target buffer (BTB) is utilized as a cache of the legitimate control flow transfers stored in a secure memory region. In addition, the BTB is extended to store the correct program path information. At each indirect branch site, the BTB is used to validate the decision history of conditional branches before it, and more information about the future decision path is fetched to monitor the execution path at run-time. Implementation of this approach is transparent to the upper operating system and programs. Thus, it is applicable to legacy code. Due to good code locality of the executable programs and effectiveness of branch prediction, the frequency of run-time control flow validations against the secure off-chip memory is low. Our experimental results show a negligible performance penalty and small storage overhead with ambiguity reduced.

show abstract

Architectural Support for Run-Time Validation of Control Flow Transfer

Cited by 8 publications

References 13 publications

Locking down insecure indirection with hardware-based control-data isolation

Locking down insecure indirection with hardware-based control-data isolation

Getting in control of your control flow with control-data isolation

Leveraging speculative architectures for run-time program validation

Contact Info

Product

Resources

About