isolation
play

Isolation William Arthur , Sahil Madeka, Reetuparna Das, Todd Austin - PowerPoint PPT Presentation

Locking Down Insecure Indirection with Hardware-Based Control-Data Isolation William Arthur , Sahil Madeka, Reetuparna Das, Todd Austin MICRO, Waikiki, Hawaii, US December 7 th 2015 Goal of this work MAKE SOFTWARE MORE SECURE Reducing the


  1. Locking Down Insecure Indirection with Hardware-Based Control-Data Isolation William Arthur , Sahil Madeka, Reetuparna Das, Todd Austin MICRO, Waikiki, Hawaii, US December 7 th 2015

  2. Goal of this work MAKE SOFTWARE MORE SECURE Reducing the software attack surface by subtracting the root cause leading to many software exploits today Accomplished by locking down insecure indirection 2

  3. Locking Down Insecure Indirection (1) Every control transfer in executing application comes from the programmer: Every PC address encoded in instructions, OR Is derived from secure hardware structures Executing application always adheres to the programmer-defined control-flow graph Stopping control-flow attacks which derail the CFG 3

  4. Locking Down Insecure Indirection (2) Achieved by hardware-software co-design Software: Eliminate all indirect control-flow instructions – via Control-Data Isolation (CDI) [1] Hardware: Memoization of secure control transitions in secure hardware – via Indirect Edge Cache [1] Getting in Control of Your Control Flow with Control-Data Isolation , Arthur et al., CGO 2015 4

  5. Outline Software (in)security – Control-Flow Attack Software (in)security Hardware-Based Control-Data Isolation Hardware-Based Control-Data Isolation Measure performance and security Measure performance and security Conclusions Conclusions 5

  6. Control-Flow Attack Control-Flow Attacks violate, at runtime, the CFG of an application by corrupting the PC with user-injected data return ????? Buffer Overflow local variables, return Heap Spray attack value Return-to-libc code Code Gadgets Stack Smash buffer 6

  7. Outline Software (in)security Hardware-Based Control-Data Isolation Measure performance and security Conclusions 7

  8. Control-Data Isolation int bar() { int bar() { int bar() { // function code // function code // function code return; if ([%esp]==_ret1) } jump _ret1; return; Vulnerable Code else if ([%esp]==_ret2) } jump _ret1; ret Vulnerable Code else call _abort; } White-list of valid “ Sled ” of conditional branches CFG edges and direct jumps 9

  9. Hardware-Based CDI Software- only CDI (CGO ’15) retains higher than desired runtime overheads for some applications – 31% for gcc Key insight: Caching previously executed sled edges obviates subsequent re- executions of the sled Addition of hardware edge cache 11

  10. Hardware-Based CDI Algorithm Indirect Instruction Execute (*jmp, *call, ret) Instructions Hit? Check Edge Cache Cache for <source,target> <source,target> of taken branch pair Miss? Fall-through to sled , retain Taken branch <source> from sled 12

  11. Hardware-Based CDI Algorithm Indirect Instruction Execute (jmp, call, ret) Instructions Hit? Check Edge Cache Cache for <source,target> <source,target> of taken branch pair Miss? Fall-through to sled , retain Taken branch <source> from sled 13

  12. Hardware-Based CDI Algorithm Indirect Instruction Execute (*jmp, *call, ret) Instructions Hit? Check Edge Cache Cache for <source,target> <source,target> of taken branch pair Miss? Fall-through to sled, retain Taken branch <source> from sled 14

  13. Hardware-Based CDI Algorithm Indirect Instruction Execute (jmp, call, ret) Instructions Hit? Check Edge Cache Cache for <source,target> <source,target> of taken branch pair Miss? Fall-through to sled , retain Taken branch <source> from sled 15

  14. Hardware-Based CDI Algorithm Indirect Instruction Execute (jmp, call, ret) Instructions Hit? Check Edge Cache Cache for <source,target> <source,target> of taken branch pair Miss? Fall-through to sled , retain Taken branch <source> from sled 16

  15. Hardware-Based CDI Algorithm Indirect Instruction Execute (jmp, call, ret) Instructions Hit? Check Edge Cache Cache for <source,target> <source,target> of taken branch pair Miss? Fall-through to sled, retain Taken branch <source> from sled 17

  16. Hardware-Based CDI Algorithm Indirect Instruction Execute (jmp, call, ret) Instructions Hit? Check Edge Place Cache for <source,target> in the Edge <source,target> Cache pair Miss? Fall-through to sled, retain Taken branch <source> from sled 18

  17. Hardware-Based CDI Algorithm Indirect Instruction Execute (jmp, call, ret) Instructions Hit? Check Edge Cache Cache for <source,target> <source,target> of taken branch pair Miss? Fall-through to sled, retain Taken branch <source> from sled 19

  18. Hardware-Based CDI Algorithm Indirect Instruction Execute (*jmp, *call, ret) Instructions Hit? Check Edge Cache Cache for <source,target> <source,target> of taken branch pair Miss? Fall-through to sled, retain Taken branch <source> from sled 20

  19. Hardware-Based CDI Algorithm Indirect Instruction Execute (jmp, call, ret) Instructions Hit? Check Edge Cache Cache for <source,target> <source,target> of taken branch pair Miss? Fall-through to sled , retain Taken branch <source> from sled 21

  20. Edge Cache(1) New hardware structure – edge cache Memoization of most recent indirect edges 22

  21. Edge Cache(2) Fetch Edge Cache Squash, execute <src,target> sled Commit No = Retire Yes 23

  22. Edge Cache(2) PC BTB Fetch Target Edge Index Cache Squash, GHR execute <src,target> sled Commit No = Retire Yes 24

  23. Challenges Edge Cache Source Target U V Address Address tag, full address 128 + 2 bits per entry! 1k entries = 16 kB 26

  24. Region Table Edge Cache Source Target Region Region G G U V Addr. Offset Addr. Offset Pointer(S) Pointer(T) offset, 18 bits index, 5 bits 27

  25. Region Table Edge Cache Source Target Region Region G G U V Addr. Offset Addr. Offset Pointer(S) Pointer(T) Region Table Region Address G U V 28

  26. Region Table Edge Cache Source Target Region Region G G U V Addr. Offset Addr. Offset Pointer(S) Pointer(T) 50 bits per Region Table entry! Region Address G U V 1k entries 6.75 kB total Region Offset full address 29

  27. Outline Software (in)security Hardware-Based Control-Data Isolation Measure performance and security Conclusions 30

  28. Experimental Setup gem5 architectural simulator Detailed O3 cpu model, configured similar to Intel Haswell processor, x86-64 SPECINT 2000 & 2006 1,024-entry edge cache 4-way set associative 32-entry region table 31

  29. Speedup Over Native Execution 1.2 0.995 Hardware-Based CDI Software-Based CDI 1 0.8 0.84 0.6 0.4 0.2 0 Benchmark Applications Branch prediction – 6% speedup 400.perlbench vs BTB 32

  30. Security Average Indirect target Reduction – AIR [2] Measure of the reduction in the software attack surface 99.999%+ reduction in indirect target set Average of tens of targets per indirect Previous works : average of tens of thousands of targets per indirect instruction [2] Control Flow Integrity for COTS Binaries , Zhang and Sekar, USENIX Security 2013 33

  31. Conclusions Locking down insecure indirection can eliminate contemporary control-flow attacks Hardware-based control-data isolation efficiently realizes this capability Minimal runtime overhead – 0 . 5% 34

  32. Thank You Questions? 35

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