RIPE: Runtime Intrusion Prevention Evaluator

RIPE: Runtime Intrusion Prevention Evaluator

John Wilander, Nick Nikiforakis, Yves Younan,Mariam Kamkar, and Wouter Joosen

@johnwilander @nicknikiforakis ACSAC’11

RIPE is ...

... a deliberately vulnerable C program

... that attacks itself,

... to allow evaluation of countermeasures.


RIPE contributions:

850 working buffer overflow attack forms

Evaluation of 8 countermeasures

7% to 89% of attack forms prohibited


RIPE download (MIT license):

https://github.com/johnwilander/RIPE




A Quick Look at

How RIPE Works


RIPE backend

Backend(C)

Performsone attackper execution

Can be runstand-alone, command-line


RIPE backend

Backend(C)

Performsone attackper execution

Can be runstand-alone, command-line

./ripe_attack_generator -t direct -i simplenop -c ret -l stack -f strcpy


RIPE frontend

Frontend(Python)

Backend(C)

Report

Drives


RIPE frontend

Frontend(Python)

Backend(C)

Report

Drivespython ripe_tester.py {direct|indirect|both}number of times to repeat tests


RIPE frontend

Frontend(Python)

Backend(C)

Report

Drivespython ripe_tester.py both 5


Which Attack Formsare Possible?


Technique

Location

Target

NDSS ’03 Testbed

20 attack forms


Technique

Location

Targ

etFunction

Attack code

ACSAC ’11 Testbed

850 attack forms


Technique

Location

Targ

etFunction

Attack code

ACSAC ’11 Testbed•RET•Old base ptr•Func ptr•Longjmp buffer•Struct with buffer & func ptr


Technique

Location

Targ

etFunction

Attack code

ACSAC ’11 Testbed

•Direct• Indirect


Technique

Location

Targ

etFunction

Attack code

ACSAC ’11 Testbed

•memcpy•str(n)cpy•s(n)printf•str(n)cat•{s|f}scanf• loop equiv of memcpy


Technique

Location

Targ

etFunction

Attack code

ACSAC ’11 Testbed

•Stack (local var & param)•Heap•BSS•Data


Technique

Location

Targ

etFunction

Attack code

ACSAC ’11 Testbed•Shellcode•Shellcode + NOP•Shellcode + Polym. NOP•Create file•Return-into-libc•ROP


Examples ofAttack Forms


Optional Attack code Padded Address NNOP sled, (shell code bytes back to usimple or or NOP sled or lpolymorph create file) attack code l

Vulnerable Other variables Target codebuffer pointer

Direct Overflow with Injected Code

./ripe_attack_generator -t direct -i simplenop -c ret -l stack -f strcpy


Indirect Overflow

Optional Attack code Padded Address NNOP sled, (shell code bytes back to usimple or or NOP sled or lpolymorph create file) attack code l

Vulnerable Other variables Generalbuffer pointer

Target codepointer

./ripe_attack_generator -t indirect -i nonop -c ret -l stack -f strcpy


Overflow Within Struct

Optional Attack code AddressNOP sled, (shell code back tosimple or or NOP sled orpolymorph create file) attack code

Vulnerable Other Functionbuffer variables pointer

Struct

./ripe_attack_generator -t direct -i nonop -c structfuncptrstack -l stack -f strcpy


Injected Stackframe

Optional Attack code Fake Address NNOP sled, (shell code stack to fake usimple or or frame stack frame lpolymorph create file) l

Vulnerable Other variables Oldbuffer basepointer

./ripe_attack_generator -t indirect -i polynop -c baseptr -l heap -f fscanf


Injected Stackframe

Optional Attack code Fake Address NNOP sled, (shell code stack to fake usimple or or frame stack frame lpolymorph create file) l

Vulnerable Other variables Oldbuffer basepointer

./ripe_attack_generator -t indirect -i polynop -c baseptr -l heap -f fscanf


All in all, 850 working attack forms


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)


ProPolice

Local variables

Local buffers RET

Old Base Ptr

Guard

sorted


CRED

ExtentBase

ExtentBase

ExtentBase

ExtentBase

ExtentBase

ptr

Referent objects


CRED

ExtentBase

ExtentBase

ExtentBase

ExtentBase

ExtentBase

ptrAny pointer dereferencinghas to stay within bounds


CRED

ExtentBase

ExtentBase

ExtentBase

ExtentBase

ExtentBase

ptr

ValueObjOut-of-bounds object

Pointers allowed to beout of bounds duringartihmetics


Stack Shield

Stack frame A

Global RET stack

RET A RET A


Stack frame B

Stack Shield

Stack frame A

Global RET stack

RET A

RET B

RET B


Stack frame A

Stack frame B

Stack Shield

Global RET stack

RET A

RET B

RET B


Stack Shield

Text segment

Data segment

BSS

Heap

Stack

Boundary Function pointershave to point here


Libverify

Text segment

Data segment

BSS

Heap

Stack


Libverify

Text segment

Data segment

BSS

Heap

Stack

All functions


Libverify

Text segment

Data segment

BSS

Heap

Stack

All functions

Copy allfunctionsto theheap


Libverify

Text segment

Data segment

BSS

Heap

Stack

All functions

Instrument allfunctions to copytheir RET to acanary stack andcheck it beforereturn

RET A

RET B


Libsafe

Parameters

RET

Old base pointerBoundary

Library functions may never overwrite abuffer pass the oldbase pointer


LibsafePlus & TIED

Source code

BinaryCompile with -g

Debug info


LibsafePlus & TIED

Binary

Debug info

Libsafe-Plus

TIED


LibsafePlus & TIED

Binary

Debug info

Libsafe-Plus

TIED

Offset fromframe pointerand size forall buffers


LibsafePlus & TIED

Binary

Debug info

Libsafe-Plus

TIED

Offset fromframe pointerand size forall buffers

Instruments all functions to check bounds


Non-Executable Memory (XD + PAE)

Text segment

Data segment

BSS

Heap

Stack

W⊻Xwritable XOR executable

W

W

WW

X


Empirical Evaluation Results


Results

Ubuntu 6.06 (no protection)

Libsafe

LibsafePlus

StackShield

ProPolice

LibsafePlus + TIED

CRED

Ubuntu 9.10 (W⊻X + CRED)

7%

19%

36%

40%

77%

79%

89%

0%

Effective-ness

91%

79%

63%

59%

20%

20%

9%

99%

Successful attacks

2%

2%

1%

1%

3%

0.5%

1%

1%

Partly successful

7%

19%

36%

40%

77%

79%

89%

0%

Failed attacks


Results, top 4

ProPolice

LibsafePlus + TIED

CRED


40%

77%

79%

89%

Effective-ness

59%

20%

20%

9%

Successful attacks

1%

3%

0.5%

1%

Partly successful

40%

77%

79%

89%

Failed attacks


Results, top 4

ProPolice

LibsafePlus + TIED

CRED


40%

77%

79%

89%

Effective-ness

59%

20%

20%

9%

Successful attacks

1%

3%

0.5%

1%

Partly successful

40%

77%

79%

89%

Failed attacks

Totally focused on protecting the stack.Indirect, heap/BSS/data-based attacks against longjmp buffers as stack variables or function parameters not fully stable and thus categorized as partly successful.


Results, top 4

ProPolice

LibsafePlus + TIED

CRED


40%

77%

79%

89%

Effective-ness

59%

20%

20%

9%

Successful attacks

1%

3%

0.5%

1%

Partly successful

40%

77%

79%

89%

Failed attacks

Doen’t wrap memcpy or loop equivalent of memcpy.Spurious successful attacks abusing wrapped functions explains the fairly high ”Partly successful” figure.


Results, top 4

ProPolice

LibsafePlus + TIED

CRED


40%

77%

79%

89%

Effective-ness

59%

20%

20%

9%

Successful attacks

1%

3%

0.5%

1%

Partly successful

40%

77%

79%

89%

Failed attacks

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.


Results, top 4

ProPolice

LibsafePlus + TIED

CRED


40%

77%

79%

89%

Effective-ness

59%

20%

20%

9%

Successful attacks

1%

3%

0.5%

1%

Partly successful

40%

77%

79%

89%

Failed attacks

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.


Related Work


Dynamic Overflow Detecionby Zhivich, Leek, and Lippmann


Two Testbeds

1. ”Variable-overflow”various small overflowssynthesizednot attacks

2. ”Real exploits”modeled from real worlddetectionperformace


Seven Countermeasures Evaluated

1. Chaperoncommercial, works with binaries, monitors execution

2. Valgrindfree sw, simulated execution, up to 500% performance hit

3. CCuredfree sw, static analysis of pointers, may require annotationsSAFE = no arithmentic, no castSEQ = arithmeticWILD = arithmetic and cast


Seven Countermeasures Evaluated

4. CREDfree sw, bounds checking with referent object

5. Insure++commercial, instruments source code, up to 2500% performace hit

6. ProPolicefree sw, canary-based, reorders stack variables

7. TinyCCfree sw, basic referent object bounds checking


Results (Zhivich, Leek, and Lippmann)


Results (Zhivich, Leek, and Lippmann)


Future Work

• Save/load offsets to allow testing of ASLR, probabilistic memory safety

• Other attack forms;Memory mgmt data (free & double free)Heap sprayingNon-control data attacks

• Configurable memory layout model

Slides http://www.slideshare.net/johnwilander/ripe-runtime-intrusion-prevention-evaluator

@[email protected]

http://www.slideshare.net/johnwilander/ripe-runtime-intrusion-prevention-evaluator




Technology

RIPE: Runtime Intrusion Prevention Evaluator