Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications

Automatic Patch-Based Exploit Generation is Possible:Techniques and Implications

David Brumley, Pongsin Poosankam, Dawn Song and Jiang Zheng

Presented by Nimrod Partush

Outline

Introduction & Motivation Problem Definition Problem Solution

3 Step Plan Demos

Discussion & Conclusions

Security patches are good

Good software vendors constantly review and test their products’ security

They periodically release patches for new found security bugs This is bad, apparently.

Security patches are bad

Common attacker practice: manually review the patch in reference to the original program Changes can infer security bugs in the

original program Quickly create an attack (exploit) and

compromise un-patched systems

Our goal: Make the attacker’s life easier. Not really

The Automatic Patch-Based Exploit Generation Problem

Given a program P and a patched version of the program P’, automatically generate an exploit for the potentially unknown vulnerability present in P but fixed in P’

Show this is feasible. Thus raise awareness that an attacker

with a patch should be considered as armed with an exploit

A scary equation Windows Update takes 24 hours to reach

80% of the clients+

A worm (slammer for instance) can spread to most vulnerable clients in minutes

+ The paper claims to generate an exploit

within minutes=

Millions of compromised clients for every patch release

The attacker experience

Exploit this:

How about now?

* Based on the DSA_SetItem IE Vulnerability

1. if (input % 2 == 0) goto 2 else goto 4;

2. s := input+2;3. goto 5;4. s := input+3;5. ;6. ptr := realloc(ptr,s);7. // use ptr[0], ptr[1], …

ptr[input-1]1. if (input % 2 == 0) goto 2 else goto 4;

2. s := input+2;3. goto 5;4. s := input+3;5. if (s>input) goto 6 else

goto ERROR;6. ptr := realloc(ptr,s);7. // use ptr[0], ptr[1], …

ptr[input-1]

232 – 3 ≤ input ≤ 232 – 1

Exploitable inputs

All Inputs

Safe Inputs

Challenges Pin-point the bug

Within millions of binary instructions Correlate it to the original code

Not every code addition is a vulnerability fix Ignore feature addition, etc.

A line of code is just a line of code Remember that input is needed to exploit the

bug.

Input sanitation is key

Observation: input validation bugs are usually fixed by adding missing sanitation checks. Pick on those, leave the rest.

Intuition: input that fails the sanitation check in P’ is likely an exploit for P. Easily verified by running them

Game Plan

1) Identify new sanitation checks in P’

2) Generate candidate exploit input Calculate weakest precondition to fail the check,

a formula is generated Use a solver to find an input that satisfies the

formula

3) Verify as an exploit Define a “security policy” Check for violations using external checkers

Step 1: Binary Diffing An off-the-shelf solution, EBDS, is used to

find new sanitation checks. Within function bounds Purely syntactical

Problem: i > 10 differs from i – 1 > 9

Solution: The verification step will overcome this.

Binary Diffing Demonstrated

Step 2: Generate candidate exploit We generate a formula that encapsulates

the program paths that lead to the sanitation check We do this by collecting constrains deduced

from the instructions and conditionals. The X86 instruction set was modeled in Vine. F(input) = ((input % 2 == 0) and (s == input +2(mod 232))) and !

(s > input)

Problem: Usually only a fraction of all paths that lead to the check are exploitable

1. if (input % 2 == 0) goto 2 else goto 4;

2. s := input+2;3. goto 5;4. s := input+3;5. if (s>input) goto 6

else goto ERROR;6. ptr := realloc(ptr,s);7. // use ptr

Static Vs. Dynamic

Reducing the number of paths will result in faster and more successful analysis

3 approaches: Pure Static

▪ Consider all possible executions that lead to the test.▪ F(input) =( ( (input % 2 == 0) and (s == input +2(mod 232)) ) or

( (input % 2 != 0) and (s == input +3(mod 232)) ) ) and !(s > input)

Pure Dynamic▪ Pick an path from a known trace, build constraints and fail the test.▪ F(input) = ( (input % 2 == 0) and (s == input +2(mod 232)) ) and !(s > input)

Half and half▪ For a known input, build constraints for a potion of the path and consider all

paths for the rest.

1. if (input % 2 == 0) goto 2 else goto 4;

2. s := input+2;3. goto 5;4. s := input+3;5. if (s>input) goto 6

else goto ERROR;6. ptr := realloc(ptr,s);7. // use ptr

Formula -> Exploit

The STP constraint solver was used to generate exploits Supports bit operations

An iterative process.

Exploit extraction Demonstrated

Step 3: Verify the exploit Define a “Security Policy”

A predicate on the program state space that indicates whether a certain attack occurred

Generic▪ Control flow hijacking – return address integrity.▪ Information disclosure – read beyond bounds.▪ Denial of service – crash.

Basically a monitoring tool is used to see if warnings are raised. Sometimes TEMU Mostly run and crash

Exploit verification Demonstrated

Results

5 real world exploits for MS programs derived from patches. Some previously unknown

Patch generated within minutes. Polymorphic exploits

Abuse anti-virus signature writers

Advantages

Real life exploits exposed Fast and (semi) automatic exploit

production Interesting dynamic + static

integration Work on binaries

Disadvantages

As strong as the weakest tool its build upon Binary diffing is sometimes weak.

Input sanitation oriented Easily manipulated

Needs run traces The purely static approach usually fails

Works on binaries

Conclusions & Solutions

Finding and fixing security bugs will expose the software to attacks

Patch release strategies need to change Fast patch distribution▪ P2P

Patch encryption Patch obfuscation