Hardwarelevel defense NonExecutable Stack Prevent attack code execution
Hardware-level defense: Non-Executable Stack Prevent attack code execution by marking stack and heap as nonexecutable • NX bit in every Page Table Entry (PTE) • Deployment: • Linux • GCC enables by default, disable it with –zexecstack option • Windows DEP (data execution prevention): since XP SP 2 (2004) • Visual Studio: /NXCompat[: NO] • Limitations: • Some apps need executable heap (e. g. JITs). • Can be easily bypassed using Return Oriented Programming (ROP) Next lecture 12/20/2021 Zhou Li 1
Examples: DEP controls in Windows DEP terminating a program 12/20/2021 Zhou Li 3
Countermeasure: Control-Flow Integrity • CFI is a defense mechanism that protects applications against control-flow hijack attacks. • The control-flow of the application never leaves the predetermined, valid control-flow that is defined at the source code/application level. • An attacker cannot redirect control-flow to alternate or new locations. • Shadow stack is a weaker form (only on stack)
Basics of a CFI mechanism • Core idea: restrict the dynamic control flow of the application to the control-flow graph of the application. • Target set construction • Dynamic enforcement mechanism to execute runtime checks
CFI: target set construction • How do we infer the control-flow graph (for C/C++ programs)? • A static analysis (on source code or binary) can recover an approximation of the control-flow graph. • Precision of the analysis is crucial! • Policies (detailed in the SS 3 P book) • • Valid functions Arity Function prototypes Class hierarchy analysis
CFI: runtime checks • The runtime check leverages the runtime value and the target set to execute a set check. • The most efficient implementation uses a set of bit masks. void (*fn)(int) = &func; . . . if (!contains(targetset, fn)) { abort("Error: illegal target"); } fn(12); • Note that the check and dispatch are atomic as otherwise, this would result in a TOCTTOU vulnerability.
CFI availability • Microsoft: control-flow guard ( /guard: cf ) • Windows 8. 1 and VS 2015 and newer • Return flow guard • GCC: vtable verification (VTV) • Clang (LLVM): -fsanitize=cfi • https: //clang. llvm. org/docs/Control. Flow. Integrity. html • Intel: Control-flow Enforcement Technology (CET) • ARM: Branch Target Integrity (BTI) 12/20/2021 Zhou Li 8
CFI: limitations • CFI allows the underlying bug to fire and the memory corruption can be controlled by the attacker. • The defense only detects the deviation after the fact, i. e. , when a corrupted pointer is used in the program. • Over-approximation in the static analysis reduces security • What kind of attacks are possible?
CFI: limitations • CFI itself is stateless, no dynamic control-flow or data-flow • Each state is verified without context • CFI is clueless about constraints between states • Any target in the target set is valid • What kind of attacks are possible? • For return instructions: one set of return targets is too broad and even localized return sets are too broad for most cases. • For indirect calls and jumps, attacks like COOP (Counterfeit Object Oriented Programming) have shown that full functions can be used as gadgets.
Slides credit • Computer & Internet Security, a Hands-on Approach, Wenliang Du • SS 3 P, Mathias Payer 12/20/2021 Zhou Li 11
- Slides: 11