Host and Application Security Lesson 10: Code Injection

Vulnernabities: Easy!  However, a more interesting class is code injection vulns…

What is code?  Actually, that’s not nearly as simple a question as it sounds  What about interpreted versus native?

Binary (native) code  Ultimately, machine code  Runs directly on the chip  Turns into microcode at the next layer down  Running native code is the holy grail when it comes to exploits

Understanding basic injection  The goal of code injection: Get something that is not code to run as code Why does it have to be not code?

Buffer Overflow  Five pounds of sugar in a four pound bag…  So, in a language like C/C++ what is the implication  Now, how can we turn that into code injection

How functions get called  stdcall calling convention: Parms on the stack, right to left Callee is responsible for cleaning up the stack

Stack-based injection  Let’s work our example now on the stack of a real program

Defenses  No execute flag: mark something in memory that makes memory non-executable  In particular, the non-executable stack  Stack cookies (canaries) help… but they leave a gap in protection

Return to libc attacks  We have a library with a known address (such as libc on Unix)  We have control of the stack, but have a non- executable stack…  What does the stack need to look like before a call? Bingo!

Return Oriented Programming  Much like return to libc, but we jump to “gadgets”  Using our gadgets, we build the program we want to run

Assignment  There’s a vulnerable program in your SVN…  Figure out how to exploit it  If you cannot figure it out, you should tell me what you tried and what you learned  By the midterm, you should read: The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86) Smashing the Stack for fun and profit

Questions?