Guarding Vulnerable Code: Module 2: Mitigation Mathias Payer, - PowerPoint PPT Presentation

Guarding Vulnerable Code: Module 2: Mitigation Mathias Payer, Purdue University http://hexhive.github.io 1

Defense: Testing vs. Mitigations Software Testing Mitigations ● Discover bugs ● Stop exploitation ● Development tool ● Always on ● Result oriented ● Low overhead 2

Heartbleed: reactive patching* ● 11% of servers remained vulnerable after 48 hours ● Patching plateaued at 4% ● Only 10% of vulnerable sites replaced certificates ● 15% of replaced cert's used vulnerable keys Heartbleed vulnerable hosts Update process is slow, incomplete, and faulty * The Matter of Heartbleed. Zakir Durumeric, James Kasten, J. Alex Halderman, Michael Bailey, Frank Li, Nicholas Weaver, Bernhard Amann, Jethro Beekman, Mathias Payer, Vern Paxson. In ACM IMC'14 (best paper) 3

Bugs are everywhere? https://en.wikipedia.org/wiki/Pwn2Own 4

Different threat models 5

Problem: broken abstractions? C/C++ void log( int a) { printf("Log: "); printf("%d", a); } void (* fun )( int ) = &log; void init() { fun(15); } ASM log: ... fun : .quad log init: ... movl $15, %edi movq fun(%rip), %rax call *%rax 6

Control-Flow Hijack Attack 7

Attack scenario: code injection ● Force memory corruption to set up attack ● Redirect control-flow to injected code Code Heap Stack 8

Attack scenario: code reuse ● Find addresses of gadgets ● Force memory corruption to set up attack ● Redirect control-flow to gadget chain Code Heap Stack 9

Attacker model: hijacking control-flow Attacker may read/write arbitrary data – Code is read-only, vtables are read-only – Code pointers remain writable! Code RX Heap Stack RW RW vtables R 10

Demo Time! 11

Control-Flow Bending ● Attacker-controlled execution along valid CFG – Generalization of non-control-data attacks ● Each individual control-flow transfer is valid – Execution trace may not match non-exploit case ● Circumvents protection of CFI Nicholas Carlini, Antonio Barresi, Mathias Payer, David Wagner, and Thomas R. Gross “Control-Flow Bending”, Usenix SEC'15 12

What does a CFG look like? system() vuln() 13

What does a CFG look like? Really? system() vuln() memcpy() 14

Necessity of shadow stack* ● Defenses without stack integrity are broken – Loop through two calls to the same function – Choose any caller as return location void func() { ● Shadow stack enforces stack integrity … bar(); – Attacker restricted to arbitrary targets on the stack … void bar() { … } – Each target can only be called once, in sequence bar(); … } * Control-Flow Bending: On the Effectiveness of Control-Flow Integrity. Nicholas Carlini, Antonio Barresi, Mathias Payer, David Wagner, and Thomas R. Gross. In Usenix SEC'15 15

CFB key lessons ● CFI without shadow stack is broken – Stateless defenses insufficient for stack attacks ● Turing-complete programming in most contexts – Bend execution to dispatcher/functional gadgets – In case study CFI not effective for 5/6 vulnerabilities ● Attack is program-dependent, harder to pull off 16

Counterfeit OO Programming ● OO-programs use vtables for inheritance ● Introduce fake objects – Use valid vtables – Functions become gadgets – Chaining functions gives Turing-completeness ● Stateless defenses struggle Felix Schuster, Thomas Tendyck, Christopher Liebchen, Lucas Davi, Ahmed-Reza Sadeghi, and Thorsten Holz. Counterfeit Object-Oriented Programming, Oakland'15 17

Mitigation space in a nutshell [SP13] SoftBound [PLDI09, POPL12, Memory/type safety Corruption ISCA12]; CCured [POPL02]; DShield/nC [2x AsiaCCS17] Code Integrity [AMD06]; Integrity C C *C SafeO [FSE03]; WIT [SP08]; CPI [OSDI14]; OTI [NDSS18] ASLR [CCS03, 04, 10, 12]; Confidentiality &C &C DSR [DIMVA08]; PG [SEC03]; Diversity SoK [SP14]; CFI [CCS05]; MCFI [PLDI14]; Flow Integrity *&C *&C FCFI [SEC14]; vTrust [NDSS17]; SoK [CSUR17] Code Control-flow Bad things corruption hijack 18

Attack classification ● Data-only attack – Overwriting arguments to exec() ● Non-control-data attack – Overwriting is_admin flag ● Control-Flow Bending – Modify function pointer to (valid) alternate target 19

Control-Flow Integrity 20

Control-Flow Integrity (CFI)* ● Restrict a program’s dynamic control-flow to the static control-flow graph – Requires static analysis – Dynamic enforcement mechanism * Control-Flow Integrity. Martin Abadi, Mihai Budiu, Ulfar Erlingsson, Jay Ligatti. CCS ‘05 * Control-Flow Integrity: Protection, Security, and Performance. Nathan Burow, Scott A. Carr, Joseph Nash, Per Larsen, Michael Franz, Stefan Brunthaler, Mathias Payer. ACM CSUR ‘17 21

Control-Flow Integrity (CFI) CHECK(fn); (*fn)(x); CHECK_RET(); return 7; 22

Three directions for CFI Goal: minimize target sets, increase precision 23

Enforce CFI in the kernel* ● Kernel protection crucial for system integrity ● So far, kernel only coarsely protected (if at all) ● Enforce strict pointer propagation rules – Function pointers can only be assigned – Data pointers to function pointers are forbidden ● Compiler enforces type system, instruments ● High compatibility for hypervisors, kernels * Fine-Grained Control-Flow Integrity for Kernel Software. Xinyang Ge, Nirupama Talele, Mathias Payer, and Trent Jaeger. In EuroS&P'16 24

Lockdown*: enforce CFI for binaries ● Fine-grained CFI relies on source code ● Coarse-grained CFI is imprecise ● Goal: enforce fine-grained CFI for binaries – Support legacy, binary code and modularity (libraries) – Leverage precise, dynamic analysis – Low performance overhead ● Binary translator runs online analysis, adds checks * Fine-Grained Control-Flow Integrity through Binary Hardening Mathias Payer, Antonio Barresi, and Thomas R. Gross. In DIMVA'15 25

Enforce CFI for C++ applications* ● C++ applications are prone to Counterfeit Object-Oriented Programming (COOP) ● Virtual inheritance scatters code pointers ● Protect all virtual function calls – Enforce type check of prototype for virtual calls – Sanitize VTable pointers before use ● Compiler encodes types and enforces checks * VTrust: Regaining Trust on Your Virtual Calls. Chao Zhang, Scott A. Carr, Tongxin Li, Yu Ding, Chengyu Song, Mathias Payer, and Dawn Song. In NDSS'16 26

CFI: analysis precision [CSUR17] Greeter *o = new Greeter(); o->sayHi(char *str); // o[0][1](); Valid functions Arity kBouncer [SEC13]; CCFIR [SP13]; binCFI CFI? [CCS05]; FCFI [SEC14] [SEC13]; ROPecker [NDSS14]; DynCFI [DIMVA15] Prototype Class Hierarchy MCFI [CCS13, PLDI14]; RockJIT [CCS14]; ShrinkWrap [ACSAC15]; VTrust PICFI [CCS15]; C-CFI [CCS15]; [NDSS17]; LLVM-CFI [head] PathArmor [CCS15]; KCFI [EuroSP16] 27

CFI: strength of analysis 0xf000b400 int bar1(int b, int c, int d); int bar2(char *str); void bar3(char *str); Greeter *o = new Greeter(); o->sayHi(char *str); void B::foo(char *str); class Greeter :: Base {... }; void Base::bar5(char *str); void Greeter::sayHi(char *str); class Related :: Greeter {... }; void Related::sayHi(char *str); 28

Are we making progress? 2007 2017 29

Class hierarchy depth Impl. Count Chromium Firefox [1-10] 13,751 (99.33%) 4,632 (99.90%) >10 78 (0.57%) 47 (0.10%) Max 78 107 CFI prohibits use of corrupted pointer. Can we do better? 30

Summary: Control-Flow Integrity ● CFI restricts indirect control-flow to target set – Inherently stateless defense – Effectiveness depends on precision of analysis and program functionality – Low performance overhead ● Limitations – Large target sets, statelessness – Backward edge often neglected 31

Object-Type Integrity 32

Two stages of control-flow hijacking ● Stage 1: corrupt a code pointer – Overwrite where with what? ● Stage 2: dereference the code pointer – Guide execution to dispatch 33

Mitigation space in a nutshell [SP13] SoftBound [PLDI09, POPL12, Memory/type safety Corruption ISCA12]; CCured [POPL02]; DShield/nC [2x AsiaCCS17] Code Integrity [AMD06]; Integrity C C *C SafeO [FSE03]; WIT [SP08]; CPI [OSDI14]; OTI [NDSS18] ASLR [CCS03, 04, 10, 12]; Confidentiality &C &C DSR [DIMVA08]; PG [SEC03]; Diversity SoK [SP14]; CFI [CCS05]; MCFI [PLDI14]; Flow Integrity *&C *&C FCFI [SEC14]; vTrust [NDSS17]; SoK [CSUR17] Code Control-flow Bad things corruption hijack 34

Object Type Integrity (OTI)* ● Enforce integrity of vtable pointer – Relocate to safe area – Use protected version for dispatch Safe memory area Code Heap Stack vtables * CFIXX: Object Type Integrity for C++ Virtual Dispatch. Nathan Burow, Derrick McKee, Scott A. Carr, and Mathias Payer. In ISOC NDSS '18 35

CFIXX instrumentation ● C++ dynamic dispatch has single target – Only constructor allowed to write vtable pointer – Deallocation invalidates vtable pointer – Dispatch uses vtable pointer ● Enforcing OTI protects against – VTable injection even with correct method signature – Swap vtable even in the same hierarchy – Fake object creation (COOP) 36

CFIXX performance ● Chromium: 2.03% (Octane), 1.99% (Kraken) 37

Future Directions 38

39