Size Does Matter Why Using Gadget-Chain Length to Prevent Code-reuse - - PowerPoint PPT Presentation

Size Does Matter

Why Using Gadget-Chain Length to Prevent Code-reuse Attacks is Hard

Enes Göktaş - Elias Athanasopoulos - Michalis Polychronakis Herbert Bos - Georgios Portokalidis

presented by: Flora Karniavoura Katerina Karagiannaki Irini Stavrakantonaki

Code-reuse Attacks

• Exploits:

○ Return-to-libc ○ Return-Oriented Programming (ROP) ○ Jump-oriented Programming ○ Sigreturn Return Oriented Programming (SROP)

• ROP Defences:

○ Data Execution Protection (DEP) ○ Adress Space Layout Randomization (ASLR) ○ Stack Smashing Protection (SSP) ○ Control Flow Integrity (CFI)

ROP & Gadgets

• Gadgets:

Call-site Gadget (CG)

Entry-point Gadget (EG)

• Gadget chains

ROP Defence Mechanisms

• Intel’s LBR (Last Branch Record) registers:

○

Track indirect branches & detect attacks

○

“too many indirect branches to short gadgets”.

• Tools using LBR:

❏ kBouncer attacks → must chain a significant number ❏ ROPecker

• f small gadgets

Defining Thresholds

Alarming gadget chain: TC or more gadgets with a length

• f at most TG instructions each.

Weaknesses

❖ Gadget’s #instructions > TG? → Gadget not detected ❖ TC gadgets of at most TG instructions ? → False Positive (FP) ➔ Larger TC or smaller TG → ROP attacks difficult but more FPs. What is the right size?

kBouncer

• Detects sensitive API calls (e.g. VirtualProtect()).
• Scans LBR registers to determine call source.

○ If source == ROP gadget chain, terminate proccess.

• Identifies abnormal function returns.

○ Checks if targets of return instructions in LBR preceded by a call ! ROP attacks achieved even with gadgets following intended calls.

• Gadget-Chain length: TG = 20 , TC = 8

ROPecker

• Checks LBR registers more often

○ Sliding window of executable code, check when control flow outside the window (Permission fault)

• Gadget-chain length

○ ROPecker Gadget definition:

1. Ends with indirect branch 2. Does NOT contain direct branches 3. TG = 6, TC = 11

! Multiple smaller gadget chains mixing long and short gadgets

• Uses multiple windows

TCC: cumulative gadget length (check every 3 windows). TCC = 14.

The Problem I

• What is the right size?

Attackers bypass kBouncer, ROPecker Detectable Gadgets

The Problem II

• Evade kBouncer

ROP payload of Call-Preceded Gadgets

• Evade ROPecker

Uses Tcc but: Sequences with direct branches Gadgets ⇒ Build short Undetectable Gadgets (UG) using direct branches.

Proof-of-Concept Attack

Vulnerability & Preparation

Vulnerability: a real heap-overflow in IE8

How: accessing span and width attributes of an HTML column table through JavaScript.

Exploit:

• Bypasses: kBouncer, DEP, ASLR
• Controls the target address of an indirect jump instruction
• Undetectable!

○ Short ROP payload ○ Detected only if TC,TG are restricted

→ Can be triggered several times!

1. Overwrite size of a string to read data beyond its boundaries 2. Overwrite Virtual Function Table (VFT) pointer within a button object 3. Control indirect jump via access to button

Proof-of-Concept Attack

Preparation

Bypass ASLR using the previous steps Goal: read a pointer to “shell32.dll” to locate VirtualProtect() → change memory permissions → inject executable shellcode

Proof-of-Concept Attack

Collecting Gadgets - How to find usable gadgets?

Disassemble the target binary multiple times until we encounter a stop condition (indirect control flow transfer, invalid or privileged instruction)

• Direct branches → Follow path

○ Gadget length: shortest number of instructions from the beginning till an indirect branch

• Conditional branches → Follow both paths

○ Gadget length: shortest path

Proof-of-Concept Attack

Heuristic Breakers

Remember: kBouncer Tc = 8

• > Use no more than 7 short gadgets
• Long gadgets → minimal work (i.e. set a single register)

○ Intersperse the ROP chain → kBouncer does not detect them

• Position of HB: flexibility needed depending on exploit’s semantics

Proof-of-Concept Attack

Putting It All Together

• 1. Control of an indirect jump
• 2. Stack pivoting

point the stack pointer (esp) to our buffer to perform ROP exchange eax and esp → terminate with ret

• 3. Interpose a HB gadget

use it at this point to reset Tc,

• ther entries in LBR→ detection
• 4. Indirect call gadget to call VirtualProtect()

kBouncer check does not detect attack everything is OK → VirtualProtect returns after the “call”

• 5. Code following indirect call

ret → transfers control to our executable shellcode

Proposed Countermeasures

TC, TG Parameters (I)

TG→more app execution paths as gadgets→ longer gadgets chains TC→to avoid pass control flow as attack ⇒ attacks use more gadgets

• 1. Per-Application: different TG, Tc

strictest rules→Avoids FPs gadgets larger than TG→chained together→No chains identified!

• 2. Per-Call: different TC / part of code executing

kBouncer: great benefit (check certain API calls) avoids FPs security, stability

Proposed Countermeasures

TC, TG Parameters (II)

• 3. Cumulative Chain-Length Calculation:

ROPecker: uses TCC (for smaller gadgets-chains) Not effective in this exploit.

• 4. Recursive functions→large num of returns→hard to set TC
• a. kBouncer:
• i. Only checks LBR for API calls → “away” from algorithms
• b. ROPecker:
• i. Checks every transfer to new pages→more fragile

Proposed Countermeasures

CFI

CFI→ can prevent this exploit

• CCFIR

Prevent use of unintended gadgets Low performance overhead→couple with kBouncer

• binCFI

Vulnerable to attack CCFIR with kBouncer ? → Exploit used to bypass CFI

• Replace smaller gadgets → longer HB gadgets (allowable by CFI)
• As CFI does not allow transfers to new code

○ mark code as writable ○

• verwrite it with our shellcode

Proposed Countermeasures

CCFIR with kBouncer: Is it still vulnerable? (I)

CCFIR:

• Prevents use of unintended gadgets

○ No indirect calls to API calls ( VirtualProtect()) ○ Need to use direct calls! blocks 2 gadgets of our exploit!

• Return instructions→ not transfer control to unintended gadgets

○ use only CS gadgets

• Indirect calls / jumps → restricted

○ transfer control to EP gadgets.

2nd exploit: previous one + bypassing CCFIR

• Stack Pivoting: 5 gadgets

○ 1-3 EP gadgets: corrupt stack→take control of return instr ○ 4th: loads ebp with pointer to our sprayed buffer ○ 5th: stack pivoting gadget→copy ebp to esp

• HB gadget → prepares ebp, ebx
• Call VirtualProtect()→gadgets used against CFI
• HB gadget → prepares eax
• Call memcpy() → gadgets used against CFI
• Last gadget’s return→ control to our shellcode

○ shellcode ⇒ code area of binary ⇒ Still undetected attacks even with tweaked Tc, TG

Proposed Countermeasures

CCFIR with kBouncer: Is it still vulnerable? (II)

Evaluation

Gadget Availability even for large gadget sizes of 60 instructions → numerous gadgets

How many gadgets of different sizes apps contain?

All gadgets CP gadgets

Evaluation

Per-Application Parameters

Do apps benefit from using tighter parameters?

Conclusion

★ Choosing the right thresholds for ROP detection is difficult! ★ The “long gadgets are not usable” assumption is broken. ★ Define parameters per-application → ease problem. We need better tools to evaluate our defenses