1 / 13

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.

klaus
Download Presentation

Host and Application Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Host and Application Security Lesson 10: Code Injection

  2. Vulnernabities: Easy! • However, a more interesting class is code injection vulns…

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

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

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

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

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

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

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

  10. 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!

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

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

  13. Questions?

More Related