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. 11/22/2018

Vulnerabilities breakdown Taken from: “Analysis of Security Vulnerabilities” 11/22/2018

Outline Stack smashing attack Solutions: StackGuard Compiler Based Transparent Defense Against SSA Run time code instrumentation StackGhost Hardware facilitated stack protection Identify yourself 11/22/2018

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); …… main( ) auto variables return addr of foo( ) frame ptr of foo( ) Stack ptr Frame ptr Stack grows Buffer grows 10 ptr to input string +4 -4 +8 dddd +12 cccc bbbb aaaa -8 -12 -16 b[0] b[4] b[8] b[12] Stack 11/22/2018

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

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 11/22/2018

StackGuard StackGuard: Automatic Detection and Prevention of Stack smashing Attacks A compiler tool  Recompile Two techniques: Detects Prevent 11/22/2018

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 Note: If the attack can proceed without altering the canary value, either by carefully stepping over the canary word, or by including the canary word in the attack string, then the StackGuard integrity check produced by function_epilogue will fail Buffer attack is linear sequential write of bytes to memory…. 11/22/2018

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 Note: If the attack can proceed without altering the canary value, either by carefully stepping over the canary word, or by including the canary word in the attack string, then the StackGuard integrity check produced by function_epilogue will fail Buffer attack is linear sequential write of bytes to memory…. 11/22/2018

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 11/22/2018

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. 11/22/2018

StackGuard - Results Effectiveness 11/22/2018 The attack on Perl and superprobe is not a properly “stack smashing” attack The return address is not override But rather data structures in the global data area 11/22/2018

StackGuard - Results Overhead 11/22/2018 The “i++” is the base case, and thus has no % overhead. The “void inc()” entry is a function that does i++ where i is a global variable; this shows the overhead of a zero-argument void function, and is the worstpossible case, showing a 125% overhead on function calls. The “void inc(int *)” entry is a function that takes an int * argument and increments it as a side effect; this shows that there is 69% overhead on a one argument void function. The “int inc(int)” entry is an applicative function that takes an int argument, and returns that value + 1; this shows that the overhead of a one-argument function returning an int is 80%. 11/22/2018

Outline Stack smashing attack Solutions: StackGuard Compiler Based Transparent Defense Against SSA Run time code instrumentation StackGhost Hardware facilitated stack protection Identify yourself 11/22/2018

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 11/22/2018

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? Why does it need to compute the length of target string ? I think it doesn’t know, since it has only the binary the frame pointer is the only limit they know. 11/22/2018

LibSave II Why does it need to compute the length of target string ? I think it doesn’t know, since it has only the binary the frame pointer is the only limit they know. 11/22/2018

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 11/22/2018

LibVerify II 11/22/2018

Run Time Def - results Effectiveness 11/22/2018

Run Time Def - results Overhead 11/22/2018

Outline Stack smashing attack Solutions: StackGuard Compiler Based Transparent Defense Against SSA Run time code instrumentation StackGhost Hardware facilitated stack protection Identify yourself 11/22/2018

StackGhost StackGhost: Hardware Facilitated Stack Protection Using hardware mechanisms & kernel modifications to guard application return address 11/22/2018

Sparc Architectural Issues Understand: When stack is written to Who initiates the request Who operates the request Sparc processor has 32 visible general-purpose integer registers. These registers are divided into four groups When Sparc was designed The overhead associated with saving registers to the stack during a conventional function call was believed to be very large, Idea:parameters can be passed from one function to another without (usually) interaction with the stack Procedures window _____ | | output (input for the next) | | local |____ | input global registers for data common across function calls. input registers for incoming function parameters (including the frame pointer and return pointer). local registers for general use. output registers for parameters to deeper called functions, the return value from deeper function calls, the stack pointer, and the saved program counter after a jump and link. 11/22/2018

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 A corrupt address might not be aligned – this will cause an alignmetn trap 11/22/2018

Encrypting … Per-Kernel XOR cookie Per-Process 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 11/22/2018

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 11/22/2018

StackGhost - results Overhead 11/22/2018

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. Dong Ye – for all the papers 11/22/2018

Backup 11/22/2018

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. 11/22/2018

11/22/2018