Outline Return-oriented programming (ROP) CSci 5271 Announcements - PDF document

Outline Return-oriented programming (ROP) CSci 5271 Announcements Introduction to Computer Security BCECHO Day 6: Low-level defenses and counterattacks, part 2 Stephen McCamant Control-flow integrity (CFI) University of Minnesota, Computer Science & Engineering More modern exploit techniques Basic new idea ret2pop (M¨ uller) Take advantage of shellcode pointer already present Treat the stack like a new instruction set on stack “Opcodes” are pointers to existing code Rewrite intervening stack to treat the shellcode Generalizes return-to-libc with more programmability pointer like a return address A long sequence of chained returns, one pop ret2pop (M¨ uller) Gadgets Basic code unit in ROP Any existing instruction sequence that ends in a return Found by (possibly automated) search Another partial example Overlapping x86 instructions push %esi mov $0x56,%dh sbb $0xff,%al inc %eax or %al,%dh movzbl 0x1c(%esi),%edx incl 0x8(%eax) ... 0f b6 56 1c ff 40 08 c6 Variable length instructions can start at any byte Usually only one intended stream

Where gadgets come from Building instructions String together gadgets into manageable units of Possibilities: functionality Entirely intended instructions Examples: Entirely unaligned bytes Loads and stores Fall through from unaligned to intended Arithmetic Standard x86 return is only one byte, 0xc3 Unconditional jumps Must work around limitations of available gadgets Hardest case: conditional branch Further advances in ROP Existing jCC instructions not useful Can also use other indirect jumps, overlapping not But carry flag CF is required Three steps: Automation in gadget finding and compilers 1. Do operation that sets CF In practice: minimal ROP code to allow transfer to 2. Transfer CF to general-purpose register other shellcode 3. Add variable amount to ✪❡s♣ Anti-ROP: lightweight Gaps in lightweight anti-ROP Three papers presented at 2014’s USENIX Security Check stack sanity in critical functions Hide / flush jump history Check hardware-maintained log of recent indirect Very long loop ✦ context switch jumps (kBouncer) Long “non-gadget” fragment Unfortunately, exploitable gaps (Later: call-preceded gadgets) Anti-ROP: still research Outline Return-oriented programming (ROP) Modify binary to break gadgets Announcements Fine-grained code randomization BCECHO Beware of adaptive attackers (“JIT-ROP”) Control-flow integrity (CFI) Next up: control-flow integrity More modern exploit techniques

Note to early readers Outline Return-oriented programming (ROP) This is the section of the slides most likely to change Announcements in the final version If class has already happened, make sure you have BCECHO the latest slides for announcements Control-flow integrity (CFI) In particular, the BCMTA vulnerability announcement is embargoed More modern exploit techniques BCECHO code Attack planning ✈♦✐❞ ♣r✐♥t❴❛r❣✭❝❤❛r ✯str✮ ④ ❝❤❛r ❜✉❢❬✷✵❪❀ ✐♥t ❧❡♥❀ ✐♥t ❜✉❢❴s③ ❂ ✭s✐③❡♦❢✭❜✉❢✮✲s✐③❡♦❢✭◆❯▲▲✮✮ Looks like candidate for classic stack-smash ✯ s✐③❡♦❢✭❝❤❛r ✯✮❀ Where to put the attack value? ❧❡♥ ❂ str❧❝♣②✭❜✉❢✱ str✱ ❜✉❢❴s③✮❀ Via disassembly inspection ✐❢ ✭❧❡♥ ❃ ❜✉❢❴s③✮ ④ Via GDB ❢♣r✐♥t❢✭st❞❡rr✱✧❚r✉❝❛t✐♦♥ ♦❝❝✉r❡❞ ✧ Via experimentation ✧✇❤❡♥ ♣r✐♥t✐♥❣ ✪s❭♥✧✱ str✮❀ ⑥ ❢✇r✐t❡✭❜✉❢✱ s✐③❡♦❢✭❝❤❛r✮✱ ❧❡♥✱ st❞♦✉t✮❀ ⑥ Overwriting the return address Shellcode concept ❢❞ ❂ ♦♣❡♥✭✧✴❡t❝✴♣❛ss✇❞✧✱ ❖❴❲❘❖◆▲❨⑤❖❴❆PP❊◆❉✮❀ ✇r✐t❡✭❢❞✱ ✧♣✇♥❡❞❭♥✧✱ ✻✮❀ Outline Some philosophy Return-oriented programming (ROP) Remember whitelist vs. blacklist? Announcements Rather than specific attacks, tighten behavior BCECHO Compare: type system; garbage collector vs. use-after-free Control-flow integrity (CFI) CFI: apply to control-flow attacks More modern exploit techniques

Basic CFI principle Approximating the call graph Each indirect jump should only go to a One set: all legal indirect targets programmer-intended (or compiler-intended) target Two sets: indirect calls and return points I.e., enforce call graph ♥ sets: needs possibly-difficult points-to analysis Often: identify disjoint target sets Target checking: classic Target checking: classic Identifier is a unique 32-bit value ❝♠♣ ❬❡❝①❪✱ ✶✷✸✹✺✻✼✽❤ Can embed in effectively-nop instruction ❥♥❡ ❡rr♦r❴❧❛❜❡❧ Check value at target before jump ❧❡❛ ❡❝①✱ ❬❡❝①✰✹❪ ❥♠♣ ❡❝① Optionally add shadow stack Challenge 1: performance Challenge 2: compatibility In CCS’05 paper: 16% avg., 45% max. Compilation information required Widely varying by program Must transform entire program together Probably too much for on-by-default Improved in later research Can’t inter-operate with untransformed code Common alternative: use tables of legal targets Recent advances: COTS COTS techniques Commercial off-the-shelf binaries CCFIR: use Windows ASLR information to find targets CCFIR (Berkeley+PKU, Oakland’13): Windows Linux paper: keep copy of original binary, build CFI for COTS Binaries (Stony Brook, USENIX’13): translation table Linux

Control-Flow Guard Coarse-grained counter-attack “Out of Control” paper, Oakland’14 CFI-style defense now in latest Windows systems Limit to gadgets allowed by coarse policy Compiler generates tables of legal targets Indirect call to function entry At runtime, table managed by kernel, read-only to Return to point after call site (“call-preceded”) user-space Use existing direct calls to ❱✐rt✉❛❧Pr♦t❡❝t Also used against kBouncer Control-flow bending counter-attack Outline Return-oriented programming (ROP) Control-flow attacks that still respect the CFG Announcements Especially easy without a shadow stack BCECHO Printf-oriented programming generalizes Control-flow integrity (CFI) format-string attacks More modern exploit techniques Target #1: web browsers Heap spraying How to take advantage of uncontrolled jump? Widely used on desktop and mobile platforms Maximize proportion of memory that is a target Easily exposed to malicious code Generalize NOP sled idea, using benign allocator JavaScript is useful for constructing fancy attacks Under W ✟ X, can’t be code directly JIT spraying JIT spray example Can we use a JIT compiler to make our sleds? ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① Exploit unaligned execution: ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① Benign but weird high-level code (bitwise ops. with ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① constants) ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① Benign but predictable JITted code Becomes sled + exploit when entered unaligned

JIT spray example Use-after-free ✾✵ ♥♦♣ ✾✵ ♥♦♣ Low-level memory error of choice in web browsers ✾✵ ♥♦♣ Not as easily audited as buffer overflows ✸❝ ✷✺ ❝♠♣ ✩✵①✷✺✱✪❛❧ Can lurk in attacker-controlled corner cases ✾✵ ♥♦♣ JavaScript and Document Object Model (DOM) ✾✵ ♥♦♣ ✾✵ ♥♦♣ ✸❝ ✷✺ ❝♠♣ ✩✵①✷✺✱✪❛❧ Sandboxes and escape Chained bugs in Pwnium 1 Google-run contest for complete Chrome exploits Chrome NaCl: run untrusted native code with SFI First edition in spring 2012 Extra instruction-level checks somewhat like CFI Winner 1: 6 vulnerabilities Each web page rendered in own, less-trusted process Winner 2: 14 bugs and “missed hardening opportunities” But not easy to make sandboxes secure While allowing functionality Each got $60k, bugs promptly fixed Next time Defensive design and programming Make your code less vulnerable the first time