by David Brumley, Pongsin Poosankam, Dawn Song, Jiang Zheng

1. SMU SRG reading by Tey Chee Meng:Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications by David Brumley, Pongsin Poosankam, Dawn Song, Jiang Zheng

2. What the paper is trying to achieve

3. Program P if (input % 2 == 0) { s = input + 2; } else { s = input + 3; } ptr = realloc (ptr, s); /* use of ptr */ Program P' if (input % 2 == 0) { s = input + 2; } else { s = input + 3; } if (s <= input) { /* exit with error */ } ptr = realloc (ptr, s); /* use of ptr */ Given 2 binaries

4. Create an 'exploit' • Exploit as defined by paper: • input that crashes P • input causing information leakage • input that hijacks control flow • Note: 'exploit' as defined by paper not the same 'exploit' as used in the security community which assumed • something usable • bypasses all counter measures • Halvar Flake used the term "vulnerability trigger"

5. How it was done

6. Program P if (input % 2 == 0) { s = input + 2; } else { s = input + 3; } ptr = realloc (ptr, s); /* use of ptr */ Program P' if (input % 2 == 0) { s = input + 2; } else { s = input + 3; } if (s <= input) { /* exit with error */ } ptr = realloc (ptr, s); /* use of ptr */ Step 1: Compare the binary differences

7. Concerned with input sanitisation that is missing in P but added in P' Where there are many changes, use of heuristics: minimal change => likely to be added input sanitisation lots of changes, maybe new feature Program P' if (input % 2 == 0) { s = input + 2; } else { s = input + 3; } if (s <= input) { /* exit with error */ } ptr = realloc (ptr, s); /* use of ptr */ Step 2: Determine which is the vulnerable point vul point

8. Path 1: start point (input % 2 == 0)is true s = input + 2 (s <= input)is true vulnerable point Program P' if (input % 2 == 0) { s = input + 2; } else { s = input + 3; } if (s <= input) { /* exit with error */ } ptr = realloc (ptr, s); /* use of ptr */ Step 3: Determine path(s) to the vulnerable point

9. Path 2: start point (input % 2 == 0)is false s = input + 3 (s <= input)is true vulnerable point Program P' if (input % 2 == 0) { s = input + 2; } else { s = input + 3; } if (s <= input) { /* exit with error */ } ptr = realloc (ptr, s); /* use of ptr */ Step 3: Determine path(s) to the vulnerable point

10. Not individual paths, but a graph of many paths: Program P' if (input % 2 == 0) { s = input + 2; } else { s = input + 3; } if (s <= input) { /* exit with error */ } ptr = realloc (ptr, s); /* use of ptr */ Step 3: Determine path(s) to the vulnerable point

11. Step 3: Determine path(s) to the vulnerable point • Single paths can be found via dynamic tracing, i.e. monitor the sequence of steps executed upon normal input • Control flow graphs (CFG) determined via static analysis • Combination: • find single path dynamically • choose any step in the path • determine statically the partial CFG from that step to the vulnerable point

12. From the start point to the vulnerable, the sequence of conditions that are met in P', but not in P (input % 2 == 0)is true s = input + 2 (s <= input)is true Constraint formula: (input % 2 == 0)is true AND (s <= input)is true AND s = input + 2 Possible to generate constraint formula over a CFG Program P' if (input % 2 == 0) { s = input + 2; } else { s = input + 3; } if (s <= input) { /* exit with error */ } ptr = realloc (ptr, s); /* use of ptr */ Step 4: Generate constraint formula

13. Step 5: Give constraint formula to solver for solution • NP-hard problem => the larger the constraint formula, the longer (exponential time) it takes to solve • Solution of example constraint formula: • (input % 2 == 0)is true AND (s <= input)is true • where s = input + 2 • addition is mod 232 • possible answer: input = 232 - 2 • Polymorphic exploit: solve the new constraint formula: • (input % 2 == 0)is true AND (s <= input)is false AND (input != solutions_we_already_know) • where s = input + 2 • addition is mod 232

14. Step 6: Verify the 'exploit' • There exists engines (TEMU) that can verify certain security policies, e.g. whether a return address on the stack is overwritten • Verification: • Run software under engine with specified policy • Feed 'exploit' input • Examine results of engine • If negative, and other paths exists, try other paths

15. 3rd party comments (Robert Graham, Halvar Flake) • Exploit stated in paper not the same exploit used by others • Able to generate input that triggers a vulnerability • Not yet a usable exploit that can: • defeat security mechanisms (chk_esp (), safe_unlink ()) • steal info for info-leakage or equivalent of shell code for hijack control flow • Useful, but not yet ready to generate the equivalent of a worm using this. Overstated the impact • Practical cases may involve large constraints beyond capability of solver. • Automated part least time consuming of steps in developing usable exploits

16. My comments • Output of binary difference, which one is relevant ? • For GDI vulnerability test case • vulnerable procedure: GetEvent () • Static analysis start point: CopyMetaFileW () • Remember solver cannot solve large constraints quickly or it may run out of memory • How to automate finding of suitable start point for static case ?

17. Conclusion • Novel approach • Overstated claims