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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend