sok shining light on shadow stacks
play

SoK: Shining Light on Shadow Stacks Nathan Burow , Xinping Zhang, - PowerPoint PPT Presentation

SoK: Shining Light on Shadow Stacks Nathan Burow , Xinping Zhang, Mathias Payer Control-Flow Hijacking (CFH) Microsoft: 70% of bugs are memory corruptions Control and Data Planes are interleaved Memory corruption Control-Flow


  1. SoK: Shining Light on Shadow Stacks Nathan Burow , Xinping Zhang, Mathias Payer

  2. Control-Flow Hijacking (CFH) • Microsoft: 70% of bugs are memory corruptions • Control and Data Planes are interleaved • Memory corruption à Control-Flow Hijacking Data Code Pointer 2

  3. Control-Flow Hijacking (CFH) • Microsoft: 70% of bugs are memory corruptions • Control and Data Planes are interleaved • Memory corruption à Control-Flow Hijacking Data Code Pointer 3

  4. Forward Edge • Function pointers; virtual calls • Control-Flow Integrity (CFI) – statically calculates target sets 4

  5. Forward Edge • Function pointers; virtual calls • Control-Flow Integrity (CFI) – statically calculates target sets fptr() 5

  6. Forward Edge • Function pointers; virtual calls • Control-Flow Integrity (CFI) – statically calculates target sets fptr() 6

  7. Backward Edge • Return Instructions • Does CFI style analysis work? 7

  8. Backward Edge • Return Instructions • Does CFI style analysis work? ret 8

  9. Backward Edge • Return Instructions • Does CFI style analysis work? NO 9

  10. Backward Edge • CFI style target sets include every call site for the function • Target sets are too large to provide meaningful protection Security requires integrity for return addresses! 10

  11. CFH Mitigation Today • Seminal CFI paper by Abadi et. al. called for shadow stack • See Burow et al CSUR 2017[1] • Deployed versions by Microsoft / Google only cover forward edge No equally strong defense for backward edge! [1] Burow et. al. “Control-flow integrity: Precision, security, and performance.” CSUR 2017. 11

  12. Shadow Stacks • Separate return addresses from data plane • Provide integrity protection for return addresses • Performant and highly compatible Need to deploy Shadow Stack with CFI! 12

  13. Control-Flow Hijacking Illustrated Program Stack Return Address Stack Canary Pointer Array 13

  14. Control-Flow Hijacking Illustrated Program Stack Return Address Stack Canary Pointer Array 14

  15. Control-Flow Hijacking Illustrated Program Stack Return Address Stack Canary Pointer Array 15

  16. Control-Flow Hijacking Illustrated Program Stack Return Address Stack Canary Pointer Array 16

  17. Control-Flow Hijacking Illustrated Program Stack Return Address Stack Canary Pointer Array 17

  18. Control-Flow Hijacking Illustrated Program Stack ROP Pointer Stack Canary Pointer Array 18

  19. What is a Shadow Stack? Program Stack Shadow Stack Return Address Return Address foo() ⋮ Return Address ⋮ Return Address bar() 19

  20. Shadow Stack Defense Shadow Stack Program Stack Shadow RA ROP Pointer Stack Canary Pointer Array 20

  21. Shadow Stack Defense Shadow Stack Program Stack Shadow RA ROP Pointer Stack Canary Pointer Array 21

  22. Shadow Stack Defense Shadow Stack Program Stack ❌ Shadow RA ROP Pointer Stack Canary Pointer Array 22

  23. Advantages of Shadow Stacks • Know at runtime what function you were called from • Dynamic defense – does NOT rely on static analysis • Separates code and data planes for backward edges Fully precise backward edge protection! 23

  24. Shadow Stack Design Space [1] [2],[3] Direct Mapping Indirect Mapping Grows on Shadow demand Stack Shadow 8MB Stack constant 8MB Stack Stack 8MB Stack Stack [1] T. H. Dang, P. Maniatis, and D. Wagner, “The performance cost of shadow stacks and stack canaries,” in AsiaCCS ’15 [2] T.-c. Chiueh and F.-H. Hsu, “Rad: A compile-time solution to buffer overflow attacks,” in ICDCS ’01 [3] L. Davi, A.-R. Sadeghi, and M. Winandy, “Ropdefender: A detection tool to defend against return-oriented programming attacks,” in AsiaCCS’11 24

  25. Recommended Shadow Stack • Indirect mapping • Use a general purpose register for shadow stack pointer Optimal performance and high compatibility! 25

  26. Recommended Mapping • Indirect Mapping • As performant as direct mapping • Minimizes memory overhead Fastest mapping has lowest memory overhead! 26

  27. Recommended Encoding • Use general purpose (GP) register for shadow stack pointer • Does not increase register pressure • Significant optimization for shadow stacks Dedicating a register to the shadow stack pointer is an effective optimization! 27

  28. Compatibility of Recommended Shadow Stack • Threading: fully supported. GP registers are thread local • Stack Unwinding: provide instrumented setjmp / longjmp • Unprotected Code: save and restore shadow stack pointer Support all applications and incremental deployment! 28

  29. Intra-Process Memory Isolation • Shadow Stack splits code and data planes • Enables integrity enforcement by isolating return addresses Shadow Stacks enable code pointer integrity for return addresses! 29

  30. Intra-Process Memory Isolation • Software based randomization defense are defeasible • Intel MPX uses bounds checks for isolation, moderate performance • Intel MPK changes permissions of pages, slow performance None of these are fully satisfactory. Tagged architectures are a promising new approach. 30

  31. SPEC CPU2006 Performance Evaluation Shadow Geometric Max Min Stack Mean Direct 5.78% 38.68% 0.00% Recommended 3.65% 9.70% 0.00% 31

  32. SPEC CPU2006 Performance Evaluation Shadow Geometric Max Min Stack Mean Direct 5.78% 38.68% 0.00% Recommended 3.65% 9.70% 0.00% 32

  33. SPEC CPU2006 – Integrity Enforcement Integrity Geometric Max Min Scheme Mean Randomization 4.31% 13.68% 0.00% MPX 12.12% 33.02% 2.47% MPK 61.18% 419.81% 0.00% 33

  34. Conclusion • Stack remains vulnerable to code reuse attacks • Need to separate return addresses from data plane • Recommend a compact, register based shadow stack for deployment Shadow Stacks + CFI = practical CFH mitigation https://github.com/HexHive/ShadowStack 34

Recommend


More recommend