1 / 22

RIPE:Runtime Intrusion Prevention Evaluator

John Wilander , Mariam Kamkar Linkopings Universitet Nick Nikiforakis , Yves Younan , Wouter Joosen Katholieke Universiteit Leuven Belgium ACSAC 2011. RIPE:Runtime Intrusion Prevention Evaluator. Agenda. Introduction How RIPE Works Attack Forms Countermeasures Evaluated Result

efrem
Download Presentation

RIPE:Runtime Intrusion Prevention Evaluator

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. John Wilander, Mariam Kamkar LinkopingsUniversitet Nick Nikiforakis, Yves Younan, WouterJoosen KatholiekeUniversiteit Leuven Belgium ACSAC2011 RIPE:Runtime Intrusion Prevention Evaluator

  2. Agenda • Introduction • How RIPE Works • Attack Forms • Countermeasures Evaluated • Result • Future Work

  3. Introduction • RIPE • Adeliberately vulnerable C program that attacks itself to allow evaluation of countermeasures. • Contributions • 850 working buffer overflow attack forms • Evaluation of 8 countermeasures • 7% to 89% of attack forms prohibited

  4. How RIPE Works Frontend (Python) Backend (C) Drives Performs one attack per execution Can be run stand-alone, command-line Report

  5. Attack Forms • NDSS ’03 Testbed Target Technique location 20 attack forms

  6. Attack Forms • RET • Old base ptr • Funcptr • Longjmpbuffer • Structwith buffer & funcptr • ACSAC ’11 Testbed • Shellcode • Shellcode+ NOP • Shellcode+ Polym. NOP • Return-into-libc • ROP Target Attack code Technique • Direct • Indirect • Stack (local var & param) • Heap • BSS • Data • memcpy • str(n)cpy • s(n)printf • str(n)cat • {s|f}scanf • loop equiv of memcpy location Function 850 attack forms 20 attack forms

  7. Attack Forms • Example • Direct Overflow • Indirect Overflow • Overflow Within Struct • Injected Stackframe

  8. Countermeasures Evaluated • ProPolice (canary-based, variable reorder) • CRED(boundary checking, referent object) • StackShield, Libverify(copy & check) • Libsafe, LibsafePlus, LibsafePlus+TIED(library wrappers) • PAE & XD(non-executable memory)

  9. Result All code injection countermeasured. Apart from that: All struct attack forms were successful. All direct attacks against function pointers on the heap and the data segment were successful. Indirect attacks against the old base pointer work in general on the heap, BSS, and data segment for memcpy(), strcpy(), strncpy(), sprintf(), snprintf(), strcat(), strncat(), sscanf(), fscanf(), and loop equivalent Fails to protect against direct and indirect, stack/BSS/ data-based overflows toward function pointers, longjmp buffers, and structs for sprintf(), snprintf(), sscanf(), and fscanf(). Attacks against structs also successful for memcpy() and loop equivalent and are the only attacks successful from buffers on the heap Totally focused on protecting the stack. Doesn’t wrap memcpy or loop equivalent of memcpy.

  10. Future Work • Save/load offsets to allow testing of ASLR,probabilisticmemory safety • Other attack forms: • Heap spraying • Non-control data attacks

  11. Direct Overflow

  12. Indirect Overflow

  13. Overflow Within Struct

  14. Injected Stackframe

  15. ProPolice

  16. CRED(C Range Error Detector)

  17. StackShield

  18. StackShield

  19. Libverify All Functions

  20. Libsafe

  21. LibsafePlus&TIED Instruments all functions to check bounds Binary Source code Compile with -g Debug info Offset from frame pointer and size for all buffers

  22. XD(eXecute-Disable) + PAE(Physical Address Extension)

More Related