Host and Application Security

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-libcwithout Function Calls (on the x86) • Smashing the Stack for fun and profit

Questions?

Host and Application Security