bunshin compositing security mechanisms through
play

Bunshin: Compositing Security Mechanisms through Diversification - PowerPoint PPT Presentation

Bunshin: Compositing Security Mechanisms through Diversification Meng Xu, Kangjie Lu, Taesoo Kim, Wenke Lee Georgia Institute of Technology 1 Memory Corruptions Are Costly 2 3 4 Name your phone Nexus 5X %x.%x 5 Battle against


  1. Bunshin: Compositing Security Mechanisms through Diversification Meng Xu, Kangjie Lu, Taesoo Kim, Wenke Lee Georgia Institute of Technology 1

  2. Memory Corruptions Are Costly… 2

  3. 3

  4. 4

  5. Name your phone “Nexus 5X %x.%x” 5

  6. Battle against Memory Errors Existing security mechanisms: W ⊕ R, ASLR, CFI → Not hard to by pass 6

  7. Battle against Memory Errors Existing security mechanisms: W ⊕ R, ASLR, CFI → Not hard to by pass Protect all dangerous operation using sanity checks : → Auto-applied at compile time void foo(T *a) { if(!is_valid_address(a) { void foo(T *a) { Sanitize report_and_abort(); *a = 0x1234; } } *a = 0x1234; } 7

  8. Battle against Memory Errors Memory Error Main Causes Defenses Lack of length check Integer overflow Softbound Out-of-bound read/write AddressSanitizer Format string bug Bad type casting Dangling pointer CETS Use-after-free AddressSanitizer Double free Lack of initialization Data structure alignment MemorySanitizer Uninitialized read Subword copying Divide-by-zero Pointer misalignment UndefinedBehaviorSanitizer Undefined behaviors Null-pointer dereference 8

  9. Comprehensive Protection: Goal and Reality • Accumulated execution slowdown • Example: Softbound + CETS → 110% slowdown • Implementation conflicts • Example: AddressSanitizer and MemorySanitizer 9

  10. Comprehensive Protection with Bunshin • Accumulated execution slowdown • Example: Softbound + CETS → 110% slowdown • Bunshin: Reduce to 60% or 40% (depends on the config) • Implementation conflicts • Example: AddressSanitizer and MemorySanitizer • Bunshin: Seamlessly enforce conflicting sanitizers 10

  11. The N-Version Way Input Program Output 11

  12. The N-Version Way Input Virtualization Input Variant 1 Program Variant 2 Variant 3 Output Synchronize Execution & Consolidate Outputs Output 12

  13. The N-Version Way Input (benign) Virtualization Input Variant 1 Program Variant 2 Variant 3 Output Synchronize Execution & Consolidate Outputs Output (consensus) 13

  14. The N-Version Way Input (malicious) Virtualization Input Variant 1 Program Variant 2 Variant 3 Output Synchronize Execution & Consolidate Outputs Output (divergence) 14

  15. The N-Version Way Input (malicious) Virtualization Input An attacker has to simultaneously compromise all variants in order to to compromise the whole system Variant 1 Program Variant 2 Variant 3 Output Synchronize Execution & Consolidate Outputs Output (divergence) 15

  16. Similar Ideas • Two variants placed in disjoint memory partitions [ N-Variant Systems ] • Two variants with stacks growing in di ff erent directions [ Orchestra ] • Multiple variants with randomized heap object locations [ DieHard ] • Multiple versions of the same program [ Varan, Mx ] 16

  17. Bunshin Overview • Goal: • Reduce slowdown caused by security mechanisms • Enable di ff erent or even conflicting mechanisms 17

  18. Challenges for Bunshin • How to generate these variants? • What properties they should have? • How to make them appear as one to outsiders? • What is a “behavior” and what is a divergence? • What if the sanitizers introduces new behaviors? • Multi-threading support? 18

  19. Variant Generation Intuitions • Scope of protection required → Sanitizers selected Memory Error Defenses Softbound, AddressSanitizer Out-of-bound read/write CETS, AddressSanitizer Use-after-free MemorySanitizer Uninitialized read UndefinedBehaviorSanitizer Undefined behaviors • Instrumented checks by each sanitizer void foo(T *a) { void bar(T *b) { if(!is_valid_address(a) { if(!is_valid_address(b) { report_and_abort(); report_and_abort(); } } *a = 0x1234; *b = 0x5678; } } 19

  20. Variant Generation Principles • Check distribution • Sanitizer distribution 20

  21. Check Distribution Input Virtualization Input Partition 1 Partition 1 Partition 2 Partition 2 Partition 3 Partition 3 Variant 1 Program Variant 2 Variant 3 Output Synchronize Execution & Consolidate Outputs Output 21

  22. Sanitizer Distribution Input Virtualization Input A A M M D U D U E E D N D N M M R D R D O O E E E E R R S F S F Y Y S S Variant 1 Program Variant 2 Variant 3 Output Synchronize Execution & Consolidate Outputs Output 22

  23. Cost Profiling • Calculate the slowdown caused by the sanity checks void foo(T *a) { timing_start(); void foo(T *a) { if(!is_valid_address(a) { timing_start(); report_and_abort(); *a = 0x1234; } timing_end(); *a = 0x1234; } timing_end(); } 23

  24. Cost Distribution • Equally distribute overhead to variants so that they execute at the same speed 17% 17% Foo Foo Variant 1 (52% overhead) 35% Baz 28% Bar 35% Baz 28% Bar Variant 2 (48% overhead) 20% 20% Qux Qux 24

  25. Variant Generation Process Source code Variant generator Costs profiling Security opt. Variants mechanisms Overhead (e.g., ASan, MSan, UBSan) full distribution w/ MSan w/ ASan opt. ... ... Variant compiling w/ UBSan w/ ASan selective 25

  26. Variant Sync Considerations • What is a behavior and what is a divergence? • System call (both order and arguments) • How to hook it? • By patching the system call table with a kernel module • What if di ff erent sanitizers introduce di ff erent system calls? • Sync only when a program is in its main function • Do not check system calls for memory management 26

  27. System Call Synchronization Partition 1 Partition 2 Partition 3 Userspace Leader Follower 1 Follower 2 Kernel Syscall number Arguments Execution result sync slot 27

  28. System Call Synchronization Partition 1 Partition 2 Partition 3 Userspace Leader Follower 1 Follower 2 ① Leader enters syscall Kernel Syscall number Arguments Execution result sync slot 28

  29. System Call Synchronization Partition 1 Partition 2 Partition 3 Userspace Leader Follower 1 Follower 2 Kernel ② Followers enter syscall Syscall number Arguments Execution result sync slot 29

  30. System Call Synchronization Partition 1 Partition 2 Partition 3 Userspace Leader Follower 1 Follower 2 Kernel Syscall number Arguments ③ Kernel execute the syscall only once Execution result sync slot 30

  31. System Call Synchronization Partition 1 Partition 2 Partition 3 Userspace Leader Follower 1 Follower 2 Kernel Syscall number ④ Leader fetches syscall result ④ Followers fetch syscall result Arguments Execution result sync slot 31

  32. Strict and Selective Lockstep Partition 1 Partition 2 Partition 3 Userspace Leader Follower 1 Follower 2 Followers read at Kernel their own speed Leader writes at the next available slot sync ring buffer 32

  33. Strict and Selective Lockstep Partition 1 Partition 2 Partition 3 Userspace Leader Follower 1 Follower 2 Kernel Always strictly synchronized for “write” related system calls sync ring buffer 33

  34. Strict and Selective Lockstep Partition 1 Partition 2 Selective-locksteps mitigates address leaks Partition 3 Address leak involves a "write" Userspace Leader Follower 1 Follower 2 system call and with ASLR enabled, such leak attempt will be captured Kernel Reduce sync. overhead by 3% - 5% Always strictly synchronized for “write” related system calls sync ring buffer 34

  35. Multi-threading Support Before fork Original Execution group After fork New Execution group Leader Follower 1 Follower 2 New ring buffer 35

  36. Multi-threading Support Before fork Works if there is Original Execution group no interleaving between threads After fork New Execution group Leader Follower 1 Follower 2 New ring buffer 36

  37. Multi-threading Support Leader Follower 1 Follower 2 Userspace Record Enforce Enforce Kernel Total order of lock acquisition and releases 37

  38. Multi-threading Support Leader Follower 1 Follower 2 Userspace Works under Record Enforce Enforce weak determinism Kernel (data race-free programs) Implementation specific ( pthread APIs only) Total order of lock acquisition and releases 38

  39. Evaluate Bunshin • Robustness and Security • E ffi ciency and Scalability • Protection Distribution Case Studies 39

  40. Robustness Benchmark Single/Multi-thread Featuer Pass ? Single SPEC CPU2006 Multi CPU Intensive SPLASH-2x Multi 6 out of 13 PARSEC Single lighttpd I/O Intensive Multi nginx Single Interpreter python, php 40

  41. Security • RIPE Benchmark Config Succeed Probabilistic Failed Not possible 114 16 720 2990 Default 8 0 842 2990 AddressSanitizer 8 0 842 2990 Bunshin • Real-world CVEs Config CVE Exploits Sanitizer Detect 2013-2028 Blind ROP AddressSanitizer nginx-1.4.0 2016-5636 Integer overflow AddressSanitizer cpython-2.7.10 2015-4602 Type confusion AddressSanitizer php-5.6.6 2014-0160 Heartbleed AddressSanitizer openssl-1.0.1a 2014-3581 Null dereference UndefinedBehaviorSanitizer httpd-2.4.10 41

  42. Performance Benchmark Items Strict-Lockstep Selective-Lockstep Max 17.5% 14.7% SPEC CPU2006 Min 1.6% 1.0% (19 Programs) Ave 8.6% 5.6% Max 21.4% 18.9% SPLASH-2X / PARSEC Min 10.7% 6.6% (19 Programs) Ave 16.6% 14.5% lighttpd Ave 1.44% 1.21% 1MB File Request nginx Ave 1.71% 1.41% 1MB File Request

Recommend


More recommend