StackArmor: Comprehensive Protection from Stack-based Memory Error Vulnerabilities for Binaries

Abstract

StackArmor is a comprehensive protection technique for stack-based memory error vulnerabilities in binaries. It relies on binary analysis and rewriting strategies to drastically reduce the uniquely high spatial and temporal memory predictability of traditional call stack organizations. Unlike prior solutions, StackArmor can protect against arbitrary stack-based attacks, requires no access to the source code, and offers a policy-driven protection strategy that allows end users to tune the securityperformance tradeoff according to their needs. We present an implementation of StackArmor for x86 64 Linux and provide a detailed experimental analysis of our prototype on popular server programs and standard benchmarks (SPEC CPU2006). Our results demonstrate that StackArmor offers better security than prior binary-and source-level approaches, at the cost of only modest performance and memory overhead even with full protection. Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.

Secure and Efficient Multi-Variant Execution Using Hardware-Assisted Process Virtualization

“…MvArmor implements this novel technique for all the heap objects, by using the standard "compact" allocator in the leader and a custom "sparse" allocator in the followers. Extending such guarantees to all the other memory objects is, in principle, possible, but source-level information is generally necessary to accurately decouple stack [47] and data [48] objects-although binary-level approximations are at times possible [49].…”

Counterfeit Object-oriented Programming: On the Difficulty of Preventing Code Reuse Attacks in C++ Applications

“…Memory safety -various-[4]- [6], [13], [36], [45] Mostly source code () -see §VII-E CPI/CPS [31] Source code / [52] that solely aim at constraining indirect calls and jumps but not returns. As such, taken for itself, forward-edge CFI does not prevent ROP in any way.…”

“…Systems that provide forms of memory safety for C/C++ applications [4]- [6], [13], [31], [36], [45] can constitute strong defenses against control-flow hijacking attacks in general. As our adversary model explicitly foresees an initial memory corruption and information leak (see §III-B), we do not explore the defensive strengths of these systems in detail.…”

“…In other words, code reuse attacks cannot be instantiated, if spatial memory corruptions like buffer overflows and temporal memory corruptions like use-after-free conditions are prevented in the first place [51]. Indeed, a large number of techniques have been proposed that provide means of spatial memory safety [5], [6], temporal memory safety [4], or both [13], [31], [36], [45]. On the downside, for precise guarantees, these techniques typically require access or even changes to an application's source code and may incur considerable overhead.…”

On the Effectiveness of Hardware Enforced Control Flow Integrity

“…This, however, comes with significant overhead and is impractical using software alone [2]. Because of this, many implementations have attempted to use coarse-grained CFI [11,31,41]. Coarse-grained CFI sacrifices the completeness of the control-flow graph to improve performance [14,18].…”