ROPecker: A Generic and Practical Approach for Defending against ROP Attacks

Yueqiang Cheng, Zongwei Zhou, Miao Yu, Xuhua Ding, Robert H. Deng

NDSS 2014

2

Background

• Typical memory exploit involves code injection– Put malicious code in a predictable location – Pass control to it

• non-executable (NX), WX– Hardware support

• AMD “NX” bit, Intel “XD” bit (in post-2004 CPUs)

• NX block most (if not all) code injection exploits

3

Return-Oriented Programming

0x080484f4

0x0804a014

0x080484f6

0x080484cf

0x08048675

stack code

0x080484f4: pop %eax ret...0x080484f6: mov (%eax), %eax ret...0x080484cf: call %eax; ret…0x08048675: sh\0…0x0804a014: system addr

esp

actions

eax = 0x0804a014

eax = system addr

Call system(sh)

low

high

ROP cont.

• Gadgets– Code section: functionality– Linking section: control transfer • indirect jump instruction (e.g., ret, call %eax, jmp %eax)

– Aligned and unaligned • For non-fixed length instruction sets (e.g., x86)

– Sparse Distribution & Small size– ret-based ROP jmp/call-based ROP

0x080484f4:pop %eax

ret

5

Last Branch Record (LBR)

• Dedicated Registers – (src ip, dst ip)– 16 pairs available– Enabled through MSR– Accessible in Ring-0– NOT distinguish processes

Existing Approaches

• Prevention– Randomization:• Address Layout Space Randomization (ALSR)• Binary stirring (CCS’12)

– Control flow integrity• CCFIR (S&P’13)

• Detection– Abnormal behaviors– kBouncer, DROP

7

Existing ApproachesPe

rfor

man

ce O

verh

ead

Low

H

igh

Program binary Source code

Requirments

ROPdefender[AsiaCCS’11]

DROP[ICISS '09]

HyperCrop[ICISS’11]

G-Free[ACSAC’10]

Return-less[EuroSys’10]

CFLocking[ACSAC '11]

Binary rewritingNo rewriting

ILR and Smashing

[Oakland’12]

Enforce Control Flow Integrity

& Remove Gadgets

Check Every Ret&

Call-Ret-Pair Checking &

Ret Frequency CheckingRemove Gadgets&

InstructionRandomization

Binary Stirring [CCS’12]

8

Goals

Detection & Prevention• Generic– ret-based & jmp/call-based

• Transparent– w/o source code– keep the binary integrity

• Low performance overhead

9

Methodology

• How to detect– A long sequence of gadgets

• When to detect – Sliding window• Within, no intervention • Out of the window, check

– Critical system calls

10

Detection

• Call-ret violation– Jmp/call-based attack

• CFI– Completeness and accuracy

• Victim’s Execution consists of – a long sequence of gadgets – chained by indirect branch instructions.

11

Feasibility

Gadget chain length• Normal execution– Max length 10

• ROP execution– Min length 17

• Detection length

ROPnormal MinDetectionMax

12

Time to detect

• A sliding window– Within the window, no detection– When jump out, perform detection– Imple.• Only within the window, the code is executable• When jump out, page fault

• Critical syscalls– mmap, mprotect, execev

13

Sliding Window Update

14

Feasibility

• Sliding window size– large: better performance & worse accuracy– small: better accuracy & worse performance

• ROP requirement– 20KB code size

• 8KB (2 pages) or 16KB (4 pages)

15

Algorithm

16

Algorithm

1. Filter non-relevant events

2. Check the history– Gadget chain length in LBRs

3. Search the future – Gadget chain length in the future

4. Continue / Crash

17

LBR record

• NOT distinguish processes

• Search backwards – Until context switch– (kernel IP, user IP)

• Useful records– (context switch, Latest branch] 16 at most

18

Execution emulator

• Search the future execution– Possible gadgets

• ret – predictable• jmp/call – need emulation– shadow environment– copy-on-write execution

19

Pre-processing Phase

Disassembly Engine

Arbitrary Binary Code

Inst. & Gadget

lists

Inst. & Gadget

Bit-Vectors

ROPT Offline Processing Phase

Conversion Engine

• 6 bytes each time• Byte by byte• Instruction & gadgets info

20

IG Database

memory mapping

• syscall interception• data structure analysis

21

Architecture Offline Phase

App X Binary

Pre-processor

ROPeckerKernel Module

Run-time Phase

Kernel

lib1

libn

…

Instruction & Gadget Database

Stack…

CPUExecution

Trace

Apps

22

Implementation

• Prototype– Ubuntu 12.04 with kernel 3.2.0-29– A kernel module with 7K SLOC

• Checking points– #PF exception– Critical system calls• open, close• mmap2, munmap, mprotect• execve

23

Evaluation

• Accuracy – Application with ROP attack– Normal applications

• Performance– Micro-benchmark• Cost for system call interception, #PF exception• Cost for ROP checking

– Macro benchmark• Benchmark suite

24

Security Evaluation

• Real attacks– ROPeme– Htediter (exploitDB)

• Generated by Q– Gadgets inside 253 apps under /bin & /usr/bin– All detected

25

SPEC INT2006 Benchmarks: CPU

2.6 % performance lose

26

Disk I/O Performance: Bonnie++

1.56 % performance overhead

27

Network Performance: httpd

28

Micro Benchmark

29

Conclusion

• Generic detection of ROP attack

• Sliding window checks

• Implementation & evaluation

30

THANKS

31

Discussions

• Short gadget chain• Long gadget• ROP within sliding window– Dynamic sliding window size

• Dynamically-generated code• Sliding window thrashing