A Binary Rewriting Defense Against Buffer Overflow Attacks

1. A Binary Rewriting Defense Against Buffer Overflow Attacks From USENIX 2003 Paper by Prasad & Chiueh Presentation by Bryan Pass

2. Outline • Outline • Background • Buffer Overflow methods • Open Research Problems • Previous/Related Work • Binary Rewriting • Newness • Significance • Technique • Limitations • Results • Disassembly Accuracy • Performance Overhead • Executable Size Overhead

3. Two Methods of Overflow • Classic Return Address hacks • Overflow a buffer and change the return address • Causes execution to jump to code inside the buffer when the function returns • Overwriting other pointers • Overflow a pointer used in another (potentially safe) copy operation • Insert code at any location in the executable • Usually used to overwrite the windows Global Offset Table

4. Yes, it is a problem.

5. Open Research Problems • Overflow safe compiler extensions • Why aren’t these more widespread and widely used? • Education • How many of you were taught how to avoid buffer overflows? • Overflow protection in hardware • Separate stack for return addresses • Interference with benign code? • Fixing legacy code • Binary Rewriting

6. Previous/Related Work • “Canary” words • Languages & tools for compilers to use to identify potential overflows char *strcpy (char *s1, const char *s2) /*@requires maxSet(s1) >= maxRead(s2)@*/ /*@ensures maxRead(s1) == maxRead(s2) /\ result == s1@*/;

7. A New Approach: Binary Rewriting • Alter assembly code of programs to prevent Return Address vulnerabilities • Uses compiled programs rather than their source code • Since source code is not required, this can help ensure the security of legacy applications/utilities and binaries provided by outside programmers

8. Basic Method • Search a program’s assembly code for functions • Modify function prologs to store the proper return address in another area of memory (created by the binary rewriter) called the “return address stack” • Modify epilogs to use this “return address stack” to ensure they return to the proper address

9. Architecture

10. Issues with Disassembly • As it turns out, finding functions in disassembly is no simple task • Data in code regions • Variable Instruction size on x86 • Position independent code • Indirect branches • Functions without explicit CALLs • Hand written assembly • Cross function jumps

11. Disassembly Methods • Recursive Traversal • Does not do well with complex code, especially GUIs • Linear Sweep • Hard to identify code segments • Misidentified segments can cause a “chain reaction” breaking most of the disassembly results • Combined approach with “Compiler independent heuristics”

12. System Limitations • Intel Only • PE/Windows Only • Only protects return addresses • False negatives in function detection • False positives Fn1: // no ’interesting’ prologue : jne label : ret // no ’interesting’ epilogue Fn2: // ’interesting prologue’ : label: : ret // ’interesting’ epilogue • Hand-written assembly • Self modifying code • Small epilogs (int 3)

13. Disassembly Accuracy

14. Disassembly Accuracy

15. Run-Time Overhead

16. Executable Size Overhead

17. References • A Binary Rewriting Defense against Stack based Buffer Overflow Attacks. Manish Prasad and Tzi-cker Chiueh.Proceedings of the General Track: 2003 USENIX Annual Technical Conference. June 9-14, 2003. http://www.usenix.org/publications/library/proceedings/usenix03/tech/prasad.html • Statically Detecting Buffer Overflow Vulnerabilities. Larochelle and Evans. http://lclint.cs.virginia.edu/usenix01.pdf • A First Step Towards Automated Detection of Buffer Overrun Vulnerabilities. Wagner, Foster, Brewer, Aiken. http://www.cs.berkeley.edu/~daw/papers/overruns-ndss00.pdf