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

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

4. 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

5. 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

6. 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

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

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

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
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

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
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

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

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

13. 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

14. 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

15. 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

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

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?
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

18. 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

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

20. LibVerify II
11/22/2018

21. Run Time Def - results
Effectiveness
11/22/2018

22. Run Time Def - results
Overhead
11/22/2018

23. 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

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

25. 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

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

27. 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

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

29. StackGhost - results
Overhead
11/22/2018

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 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

31. Backup
11/22/2018

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

33. 11/22/2018