1 / 33

Defending against Stack Smashing attacks

Defending against Stack Smashing attacks. Presented by: Micha Moffie. Stack Smashing. Occurs in C, C++ … not java … Buffer overflow & stack Smashing are one of the most frequently exploited program vulnerabilities. Vulnerabilities breakdown.

gasha
Download Presentation

Defending against Stack Smashing attacks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Defending against Stack Smashing attacks Presented by: Micha Moffie

  2. Stack Smashing • Occurs in C, C++ … • not java … • Buffer overflow & stack Smashing are one of the most frequently exploited program vulnerabilities.

  3. Vulnerabilities breakdown • Taken from: “Analysis of Security Vulnerabilities”

  4. Outline • Stack smashing attack • Solutions: • StackGuard • Compiler Based • Transparent Defense Against SSA • Run time code instrumentation • StackGhost • Hardware facilitated stack protection

  5. Stack Stack grows main( ) auto variables 10 +12 ptr to input string +8 return addr of foo( ) +4 Frame ptr frame ptr of foo( ) 0 dddd b[12] -4 Stack ptr cccc -8 b[8] bbbb -12 b[4] aaaa -16 b[0] Buffer grows Stack Smashing Attack - I main(int argc, char **argv) { … foo(argv[1], 10); … } void foo(int i, char *s) { char b[16]; strcpy(b, s); …… }

  6. Stack Smashing Attack - II Stack Stack grows Attacker code executed in Stack Segment.. attack code attack code attack code +12 start of attack code 0x0012ff12 0x0012ff08 +8 0x0012ff12 0x0012ff04 +4 0x0012ff12 0x0012ff00 0 0x0012ff12 **** b[12] -4 return addr of foo( ) Has changed! it will return to 0x0012ff12, the attacker code **** -8 b[8] **** -12 b[4] **** -16 b[0] Buffer grows

  7. Stack Smashing Attack • Exploits the fact that return address: • is on the stack • grows “down” • is located very close to a byte array with weak bounds checking

  8. StackGuard • StackGuard: Automatic Detection and Prevention of Stack smashing Attacks • A compiler tool  Recompile • Two techniques: • Detects • Prevent

  9. StackGuard – Detect I • Add Canary Word next to return address • Observation (true only for buffer o.f.) • Return address is unaltered IFF canary word is unaltered • Guessing the Canary ? • Randomize

  10. StackGuard – Detect II • When compiling the function, we add prologue and epilogue • Before execution of function push word canary into canary vector • in addition to the stack • After execution, before returning from function check whether canary is intact • Function returns Only if canary is intact

  11. StackGuard – Prevent I • While function is active make the return address read-only • attacker cannot change the return address • any attempt will be detected • Use a library called MemGuard • mark virtual memory pages as read-only and trap every write • legitimate writes to stack causes trap • Unacceptable Performance penalty

  12. StackGuard – Prevent II • Solution: cache 4 most recently return addresses using Pentium Debug registers • trap read/write/execute of virtual address loaded into debug register (return address) • Compiler is adjusted to emit stack frames with a minimum size of ¼ a page • eliminate the need for the top-of-stack page to be read only.

  13. StackGuard - Results • Effectiveness

  14. StackGuard - Results • Overhead

  15. Outline • Stack smashing attack • Solutions: • StackGuard • Compiler Based • Transparent Defense Against SSA • Run time code instrumentation • StackGhost • Hardware facilitated stack protection

  16. Run Time Transparent Defense • Transparent Run-Time Defense against stack smashing attacks • No need to recompile code • Does instrument the code (in memory) • libverify • Utilizing two dynamically loaded libraries • LibSafe • LibVerify

  17. LibSave I • library loaded automatically • Intercepts known unsafe functions • strcpy, gets, scanf, …. • Computes (run-time) length of source string and upper bound of destination buffer • Observation: • destination buffer on the top frame cannot extend beyond the frame pointer - (safe upper limit) • What about local buffers on a previous frame pointer?

  18. LibSave II

  19. LibVerify I • library loaded automatically • Upon loading, instruments code: • All Functions are copied to heap region • For each function: • First instruction jumps to wrapper entry • Last instruction jumps to wrapper exit • Similar to StackGuard: • Wrapper entry saves a copy of canary • Wrapper exit verifies canary word • To simplify: • Actual return address used as canary word

  20. LibVerify II

  21. Run Time Def - results • Effectiveness

  22. Run Time Def - results • Overhead

  23. Outline • Stack smashing attack • Solutions: • StackGuard • Compiler Based • Transparent Defense Against SSA • Run time code instrumentation • StackGhost • Hardware facilitated stack protection

  24. StackGhost • StackGhost: Hardware Facilitated Stack Protection • Using hardware mechanisms & kernel modifications to guard application return address

  25. Sparc Architectural Issues • Understand: • When stack is written to • Who initiates the request • Who operates the request

  26. StackGhost - cont • Each time the register window is overflows or underflows call StackGhost • When overflow (push) • Encrypt the return address • When underflow (pop) • Decrypt the return address • Check address alignment

  27. Encrypting … • Per-Kernel XOR cookie • XOR a fixed cookie with the return address • Per-Process XOR cookie • More Difficult to determine the cookie (still possible) • Encrypt address + stack frame using an encryption algorithm

  28. StackGhost - results • Effectiveness • Does not prevent changing the return address • Distort – difficult for attacker to know what the actual return address will be • Unpredictable execution

  29. StackGhost - results • Overhead

  30. The End • Questions ? • References • Crispin Cowan, Calton Pu, Dave Maier, Heather Hinton, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, and Qian Zhang. Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks. pages 63-78. Proc. 7th, USENIX Security Conference, Jan 1998. • Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent run time defense against stack smashing attacks. Proc. of USENIX Annual Technical Conference, Jun 2000. • Mike Frantzen and Mike Shuey. Stackghost: Hardware facilitated stack protection. Proc. of the 10th USENIX Security Symposium, Aug 2001.

  31. Backup

  32. Stack Smashing attack - cont • Change the Return Address: The buffer overflow changes the return address to point to the attack code. When the function returns, instead of jumping back to where it was called from, it jumps to the attack code.

More Related