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

Abstract

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.

The Guardian Council

“…Software schemes [3,13,27,45,52,57] to improve security typically have unacceptably high performance overheads. Hardware schemes [11,23,28,31,32,36,37,47] are slow to react to new attacks, and can be rendered ineffective if limitations in their fixed functionality can be exploited. We want to provide a system that can avoid the shortcomings of each.…”

“…Enforcing security properites in hardware is a tempting proposition [11,23,28,31,32,36,37,47]. However, fixedfunction hardware is limited in utility if an attacker can simply change their targets to components without protection, or design software to deliberately circumvent the defences.…”

Hurdle: Securing Jump Instructions Against Code Reuse Attacks

“…Traditional control-flow integrity techniques rely on static information about the control-flow of the application to determine which paths are valid [9,[11][12][13][14][15][16][17][18][19]42]. For example, Control-Data Isolation [43] converts indirect branches into a series of direct branches based on the set of staticallyreachable targets, using hardware support to reduce the instruction cache impact [44]. The REV system [42] records cryptographic hashes of each basic block to thwart code injection and invalid control-flow transfers, but relies on static analysis to determine basic block boundaries.…”