1 / 26

Part III Counter measures

Part III Counter measures. HOW DO WE STOP THE ATTACKS?. The best defense is proper bounds checking but there are many C/C++ programmers and some are bound to forget  Are there any system defenses that can help?. HOW DO WE STOP THE ATTACKS?. A variety of tricks in combination

rowdy
Download Presentation

Part III Counter measures

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. Part IIICounter measures

  2. HOW DO WE STOP THE ATTACKS? • The best defense is proper boundschecking • butthere are many C/C++ programmersand some are bound to forget  Are thereanysystem defensesthatcan help?

  3. HOW DO WE STOP THE ATTACKS? • A variety of tricks in combination NX bit Canaries ASLR fin

  4. III.ACanaries

  5. Compiler-level techniquesCanaries • Goal: make sure we detect overflow of return address • The functions' prologues insert a canary on the stack • The canary is a 32-bit value inserted between the return address and local variables • Types of canaries: • Terminator • Random • Random XOR • The epilogue checks if the canary has been altered • Drawback: requires recompilation

  6. Canaries

  7. How good are they? • Assume random canariesprotect the stack

  8. Can you still exploit this?

  9. III.B“DEP”

  10. DEP / NX bit / W⊕X • Idea: separate executable memory locations from writable ones • A memory page cannot be both writable and executable at the same time • “Data Execution Prevention (DEP)”

  11. Bypassing W⊕X • Return into libc • Three assumptions: • We can manipulate a code pointer • The stack is writable • We know the address of a “suitable" library function (e.g., system())

  12. System() arg 0xbfffeee8 Stack arg 0xbfffeee4 “ret address” 0xbfffeee0 0xbfffeedc 0x08048430 0xbfffeed8 • Why the “retaddress”? • Whatcould we do withit? 0xbfffeed4 0xbfffeed0 0xbfffeecc 0xbfffeec8 0xbfffeec4 buf 0xbfffeec0 0xbfffeebc 0xbfffeeb8 0xbfffeeb4 0xbfffeeb0 0xbfffeeac 0xbfffeea8 0xbfffeea4

  13. Return Oriented Programming • ROP chains: • Small snippets of code ending with a RET • Can be chained together

  14. Return Oriented Programming • ROP chains • Small snippets of code ending with a RET • Can be chained together -- … … ret … ret &gadget3 &gadget2 &gadget1 stack

  15. How good are they? • Assume random canariesprotect the stack • Assume DEP preventsexecution of the stack

  16. Can you still exploit this?

  17. III.CASLR

  18. Let usmakeit a little harder still…

  19. Address Space Layout Randomisation • Idea: • Re-arrange the position of key data areas randomly (stack, .data, .text, shared libraries, . . . ) • Buffer overflow: the attacker does not know the address of the shellcode • Return-into-libc: the attacker can't predict the address of the library function • Implementations: Linux kernel > 2.6.11, Windows Vista, . . .

  20. ASLR: Problems • 32-bit implementations use few randomisation bits • An attacker can still exploit non-randomised areas, or rely on other information leaks (e.g., format bug) • So… (I bet you saw this one coming)….

  21. How good are they? • Assume random canariesprotect the stack • Assume DEP preventsexecution of the stack • Assume ASLR randomized the stackand the start address of the code • but let usassumethat all functions are still at the samerelative offset from start address of code • (in otherwords: needonly a single code pointer)

  22. Can you still exploit this?

  23. Finally

  24. We constructed “weird machines” • New spin onfundamentalquestions:  “What is computable?” • Shellcode, ROP, Ret2Libc  Turing Complete

  25. That is all folks! • We have coveredquite a lot: • Simple buffer overflows • Counter measures • Counter countermeasures • Research suggeststhat buffer overflows willbewithusforquitesome time • Best avoidthem in your code!

More Related