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

Outline Return-oriented programming (ROP) CSci 5271 Announcements Introduction to Computer Security Day 6: Low-level defenses and BCECHO counterattacks, part 2 Control-flow integrity (CFI) Stephen McCamant University of Minnesota, Computer Science & Engineering More modern exploit techniques Basic new idea ret2pop (M¨ uller) Treat the stack like a new instruction Take advantage of shellcode pointer set already present on stack “Opcodes” are pointers to existing Rewrite intervening stack to treat the code shellcode pointer like a return address Generalizes return-to-libc with more A long sequence of chained returns, one pop programmability 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 Possibilities: manageable units of 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, Unconditional jumps 0xc3 Must work around limitations of available gadgets Hardest case: conditional branch Further advances in ROP Can also use other indirect jumps, Existing jCC instructions not useful overlapping not required But carry flag CF is Automation in gadget finding and Three steps: compilers 1. Do operation that sets CF 2. Transfer CF to general-purpose register In practice: minimal ROP code to allow 3. Add variable amount to ✪❡s♣ transfer to other shellcode

Anti-ROP: lightweight Gaps in lightweight anti-ROP Three papers presented at 2014’s Check stack sanity in critical functions USENIX Security Check hardware-maintained log of Hide / flush jump history recent indirect jumps (kBouncer) Very long loop ✦ context switch Unfortunately, exploitable gaps Long “non-gadget” fragment (Later: call-preceded gadgets) Anti-ROP: still research Outline Return-oriented programming (ROP) Modify binary to break gadgets Announcements Fine-grained code randomization Beware of adaptive attackers BCECHO (“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 in the final version Announcements If class has already happened, make BCECHO sure you have the latest slides for announcements Control-flow integrity (CFI) In particular, the BCVI vulnerability More modern exploit techniques announcement is embargoed

BCECHO code Attack planning ✈♦✐❞ ♣r✐♥t❴❛r❣✭❝❤❛r ✯str✮ ④ ❝❤❛r ❜✉❢❬✷✵❪❀ ✐♥t ❧❡♥❀ Looks like candidate for classic ✐♥t ❜✉❢❴s③ ❂ ✭s✐③❡♦❢✭❜✉❢✮✲s✐③❡♦❢✭◆❯▲▲✮✮ stack-smash ✯ s✐③❡♦❢✭❝❤❛r ✯✮❀ Last time: where to put the attack ❧❡♥ ❂ str❧❝♣②✭❜✉❢✱ str✱ ❜✉❢❴s③✮❀ ✐❢ ✭❧❡♥ ❃ ❜✉❢❴s③✮ ④ value ❢♣r✐♥t❢✭st❞❡rr✱✧❚r✉❝❛t✐♦♥ ♦❝❝✉r❡❞ ✧ Via disassembly inspection ✧✇❤❡♥ ♣r✐♥t✐♥❣ ✪s❭♥✧✱ str✮❀ Via GDB ⑥ Via experimentation ❢✇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 Two sets: indirect calls and return compiler-intended) target points I.e., enforce call graph ♥ sets: needs possibly-difficult Often: identify disjoint target sets points-to analysis Target checking: classic Target checking: classic Identifier is a unique 32-bit value ❝♠♣ ❬❡❝①❪✱ ✶✷✸✹✺✻✼✽❤ Can embed in effectively-nop ❥♥❡ ❡rr♦r❴❧❛❜❡❧ instruction ❧❡❛ ❡❝①✱ ❬❡❝①✰✹❪ 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 Probably too much for on-by-default Must transform entire program together Improved in later research Can’t inter-operate with untransformed Common alternative: use tables of legal code targets

Recent advances: COTS COTS techniques Commercial off-the-shelf binaries CCFIR: use Windows ASLR information CCFIR (Berkeley+PKU, Oakland’13): to find targets Windows Linux paper: keep copy of original CFI for COTS Binaries (Stony Brook, binary, build translation table USENIX’13): Linux Control-Flow Guard Coarse-grained counter-attack “Out of Control” paper, Oakland’14 CFI-style defense now in latest Limit to gadgets allowed by coarse Windows systems policy Indirect call to function entry Compiler generates tables of legal Return to point after call site targets (“call-preceded”) At runtime, table managed by kernel, Use existing direct calls to read-only to user-space ❱✐rt✉❛❧Pr♦t❡❝t Also used against kBouncer Control-flow bending counter-attack Outline Return-oriented programming (ROP) Control-flow attacks that still respect Announcements the CFG BCECHO Especially easy without a shadow stack Printf-oriented programming Control-flow integrity (CFI) generalizes format-string attacks More modern exploit techniques

Target #1: web browsers Heap spraying How to take advantage of uncontrolled Widely used on desktop and mobile jump? platforms Maximize proportion of memory that is Easily exposed to malicious code a target JavaScript is useful for constructing Generalize NOP sled idea, using benign fancy attacks allocator 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 Chrome NaCl: run untrusted native Google-run contest for complete code with SFI Chrome exploits Extra instruction-level checks somewhat First edition in spring 2012 like CFI Winner 1: 6 vulnerabilities Each web page rendered in own, Winner 2: 14 bugs and “missed less-trusted process hardening opportunities” But not easy to make sandboxes secure Each got $60k, bugs promptly fixed While allowing functionality Next time Defensive design and programming Make your code less vulnerable the first time