Outline Return-oriented programming (ROP) Control-flow integrity (CFI) CSci 5271 More modern exploit techniques Introduction to Computer Security Announcements intermission Day 7: Defensive programming and design, part 1 Saltzer & Schroeder’s principles Stephen McCamant More secure design principles University of Minnesota, Computer Science & Engineering Software engineering for security Secure use of the OS 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
Counterfeit OO Prog. (S&P’15) Anti-ROP: lightweight Idea: construct fake objects with pointers to real C++ vtables Check stack sanity in critical functions Check hardware-maintained log of ❢♦r ✭✐ ❂ ✵❀ ✐ ❁ ♥❙t✉❞❡♥ts❀ ✐✰✰✮ recent indirect jumps (kBouncer) st✉❞❡♥ts❬✐❪✲❃❞r♦♣❈♦✉rs❡✭✐❞✮❀ Unfortunately, exploitable gaps Overlapping object fields facilitate data flow Gaps in lightweight anti-ROP Anti-ROP: still research Three papers presented at 2014’s Modify binary to break gadgets USENIX Security Fine-grained code randomization Hide / flush jump history Beware of adaptive attackers Very long loop ✦ context switch (“JIT-ROP”) Long “non-gadget” fragment Next up: control-flow integrity (Later: call-preceded gadgets) Outline Basic CFI principle Return-oriented programming (ROP) Control-flow integrity (CFI) Each indirect jump should only go to a More modern exploit techniques programmer-intended (or Announcements intermission compiler-intended) target Saltzer & Schroeder’s principles I.e., enforce call graph More secure design principles Often: identify disjoint target sets Software engineering for security Secure use of the OS
Approximating the call graph Target checking: classic Identifier is a unique 32-bit value One set: all legal indirect targets Can embed in effectively-nop Two sets: indirect calls and return instruction points Check value at target before jump ♥ sets: needs possibly-difficult points-to analysis Optionally add shadow stack Target checking: classic Challenge 1: performance In CCS’05 paper: 16% avg., 45% max. ❝♠♣ ❬❡❝①❪✱ ✶✷✸✹✺✻✼✽❤ Widely varying by program Probably too much for on-by-default ❥♥❡ ❡rr♦r❴❧❛❜❡❧ Improved in later research ❧❡❛ ❡❝①✱ ❬❡❝①✰✹❪ Common alternative: use tables of legal ❥♠♣ ❡❝① targets Challenge 2: compatibility Recent advances: COTS Commercial off-the-shelf binaries CCFIR (Berkeley+PKU, Oakland’13): Compilation information required Windows Must transform entire program together Use Windows ASLR information to find targets Can’t inter-operate with untransformed CFI for COTS Binaries (Stony Brook, code USENIX’13): Linux Keep copy of original binary, build translation table
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 Code-pointer Integrity (CPI, OSDI’14) Control-flow bending counter-attack Memory safety would block attacks, but expensive Control-flow attacks that still respect Spatial safety: e.g., no buffer overflows the CFG Temporal safety: e.g., no use after free Especially easy without a shadow stack Idea: apply memory safety only to objects containing code pointers Printf-oriented programming Similar benefits to good CFI generalizes format-string attacks Challenge: low-overhead memory isolation Outline Target #1: web browsers Return-oriented programming (ROP) Control-flow integrity (CFI) Widely used on desktop and mobile More modern exploit techniques platforms Announcements intermission Easily exposed to malicious code Saltzer & Schroeder’s principles JavaScript is useful for constructing More secure design principles fancy attacks Software engineering for security Secure use of the OS
Heap spraying JIT spraying How to take advantage of uncontrolled Can we use a JIT compiler to make our jump? sleds? Maximize proportion of memory that is Exploit unaligned execution: a target Benign but weird high-level code (bitwise ops. with constants) Generalize NOP sled idea, using benign Benign but predictable JITted code allocator Becomes sled + exploit when entered unaligned Under W ✟ X, can’t be code directly JIT spray example JIT spray example ✾✵ ♥♦♣ ✾✵ ♥♦♣ ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① ✾✵ ♥♦♣ ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① ✸❝ ✷✺ ❝♠♣ ✩✵①✷✺✱✪❛❧ ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① ✾✵ ♥♦♣ ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① ✾✵ ♥♦♣ ✾✵ ♥♦♣ ✸❝ ✷✺ ❝♠♣ ✩✵①✷✺✱✪❛❧ Use-after-free Sandboxes and escape Low-level memory error of choice in Chrome NaCl: run untrusted native code with SFI web browsers Extra instruction-level checks somewhat Not as easily audited as buffer like CFI overflows Each web page rendered in own, Can lurk in attacker-controlled corner less-trusted process cases But not easy to make sandboxes JavaScript and Document Object Model secure (DOM) While allowing functionality
Chained bugs in Pwnium 1 Outline Return-oriented programming (ROP) Google-run contest for complete Control-flow integrity (CFI) Chrome exploits More modern exploit techniques First edition in spring 2012 Announcements intermission Winner 1: 6 vulnerabilities Saltzer & Schroeder’s principles Winner 2: 14 bugs and “missed More secure design principles hardening opportunities” Each got $60k, bugs promptly fixed Software engineering for security Secure use of the OS Research with Prof. Kangjie Lu Supplemental office hours tomorrow Prof. Kangjie Lu is interested in security, program analysis, and Tomorrow (Thursday), 11am-noon in operating systems 4-225E Starting a project on Linux kernel bugs For more detsils see forum post Alternative Saltzer & Schroeder Deadlines reminder Not a replacement for reading the real thing, but: Exercise set 1: Thursday night ❤tt♣✿✴✴❡♠❡r❣❡♥t❝❤❛♦s✳❝♦♠✴ HA1 week 3: Friday night t❤❡✲s❡❝✉r✐t②✲♣r✐♥❝✐♣❧❡s✲♦❢✲s❛❧t③❡r✲❛♥❞✲s❝❤r♦❡❞❡r Security Principles of Saltzer and Schroeder, illustrated with scenes from Star Wars (Adam Shostack)
Outline Economy of mechanism Return-oriented programming (ROP) Control-flow integrity (CFI) More modern exploit techniques Security mechanisms should be as simple as possible Announcements intermission Good for all software, but security Saltzer & Schroeder’s principles software needs special scrutiny More secure design principles Software engineering for security Secure use of the OS Fail-safe defaults Complete mediation Every mode of access must be When in doubt, don’t give permission checked Whitelist, don’t blacklist Not just regular accesses: startup, maintenance, etc. Obvious reason: if you must fail, fail safe Checks cannot be bypassed More subtle reason: incentives E.g., web app must validate on server, not just client Open design Open design: strong version Security must not depend on the “The design should not be secret” design being secret If the design is fixed, keeping it secret If anything is secret, a minimal key can’t help attackers Design is hard to keep secret anyway But an unscrutinized design is less Key must be easily changeable if revealed likely to be secure Design cannot be easily changed
Recommend
More recommend
