SoK: Shining Light on Shadow Stacks

Abstract

Control-Flow Hijacking attacks are the dominant attack vector against C/C++ programs. Control-Flow Integrity (CFI) solutions mitigate these attacks on the forward edge, i.e., indirect calls through function pointers and virtual calls. Protecting the backward edge is left to stack canaries, which are easily bypassed through information leaks. Shadow Stacks are a fully precise mechanism for protecting backwards edges, and should be deployed with CFI mitigations.We present a comprehensive analysis of all possible shadow stack mechanisms along three axes: performance, compatibility, and security. For performance comparisons we use SPEC CPU2006, while security and compatibility are qualitatively analyzed. Based on our study, we renew calls for a shadow stack design that leverages a dedicated register, resulting in low performance overhead, and minimal memory overhead, but sacrifices compatibility. We present case studies of our implementation of such a design, Shadesmar, on Phoronix and Apache to demonstrate the feasibility of dedicating a general purpose register to a security monitor on modern architectures, and Shadesmar's deployability. Our comprehensive analysis, including detailed case studies for our novel design, allows compiler designers and practitioners to select the correct shadow stack design for different usage scenarios.Shadow stacks belong to the class of defense mechanisms that require metadata about the program's state to enforce their defense policies. Protecting this metadata for deployed mitigations requires in-process isolation of a segment of the virtual address space. Prior work on defenses in this class has relied on information hiding to protect metadata. We show that stronger guarantees are possible by repurposing two new Intel x86 extensions for memory protection (MPX), and page table control (MPK). Building on our isolation efforts with MPX and MPK, we present the design requirements for a dedicated hardware mechanism to support intra-process memory isolation, and discuss how such a mechanism can empower the next wave of highly precise software security mitigations that rely on partially isolated information in a process.

Authenticated Call Stack

“…However, we expect the performance cost to be negligible, as cases where the compiler needs to utilize all callee-saved registers (X19-X29) are infrequent. Note that reserving exclusive use of a register has also been proposed for shadow stacks on the x86 architecture [10], even though x86 has fewer general purpose registers compared to 64-bit ARM processors. Unlike shadow stacks, ACS in general can avoid consuming additional registers by using LR to store auth (variant 1, Section 6.2) or aret (variant 2, Section 6.2).…”

“…Although shadow stacks provide precise protection, traditional shadow stacks incur significant performance overhead and lead to false positives for programming constructs that cause mismatches between calls and returns (C++ exceptions with stack unwinding, setjmp/ longjmp). Recent shadow designs demonstrate that performance can be increased by either leveraging a parallel shadow stack [15], or using a dedicated register for shadow stack addressing [10]. However, in these schemes the shadow stack still resides in the same address space as the target application, and can be compromised if the shadow stack location is known to A.…”

“…Integrity of the shadow stack is maintained by making it inaccessible to the adversary either by randomizing its location in memory or by using specialized hardware [25]. Recent software-based shadow stacks show reasonable performance [10], but are vulnerable to an adversary capable of exploiting memory vulnerabilities to infer the location of the shadow stack. To date, only hardware-assisted shadow stacks, such as Intel CET [25], achieve negligible overhead without any security trade-offs.…”

The Guardian Council

“…Overheads of below 5%, and significantly lower than in equivalent software techniques [2, 18,19], can be achieved for coarse-grained flow control integrity with 2 GPEs on average, and with 4 for a fine-grained technique. Shadow stack requires 6, a custom load counter 4, and Rowhammer prevention 6.…”

“…However, as all memory events must be observed, instead of just loads, overheads are typically higher, though 8 GPEs are still sufficient for overheads below 5%. Comparison to Software Techniques Figure 5 shows the performance of the Guardian Council versus the best performing equivalent software-only techniques we could find in the literature [18,19,52]. This is not a direct comparison as numbers are reported for x86 systems, and the software techniques feature complex optimisations not featured in our Guardian Council implementations.…”