Outline Background 8271 discussion of: “Transparent LBR-based approach ROP Exploit Mitigation Using Indirect Branch Tracing” Administrative break Stephen McCamant (Original paper: Vasilis Pappas, Michalis Polychronakis, and Angelos D. Keromytis) kBouncer implementation University of Minnesota (Original paper: Columbia University) Limitations and counterattacks Tradeoffs in binary-level protection Microsoft BlueHat contest Contest for new ideas in CFI (Monday): strong policy, easy to memory-safety defenses state and reason about Supply Windows prototype with license But, challenging to make fast and practical to Microsoft Today: easier to deploy, fast mechanism No more than 5% overhead, no Challenge is to maximize defensive “application compatibility regressions” coverage Due date was April 1st 2012 BlueHat results Review: ROP 1st This paper’s project, won $200k Create attacks by reusing small pieces of existing code 2nd ROPGuard [34], $50k, used in next version of EMET Connected by returns or other indirect jumps 3rd $10k + MSDN subscription, also anti-ROP Evolved from return-to-libc, Shacham coined name and demonstrated Turing (No prize: CFI project led by Lenx Tao completeness Wei ✦ ASIACCS and Oakland papers)
ROP in the arms race Outline Background W ✟ X (e.g. DEP) and ASLR widespread LBR-based approach but incomplete Most attacks use ROP to circumvent Administrative break W ✟ X kBouncer implementation Defensive next step: do something about ROP Limitations and counterattacks Last Branch Recording Sensitive operations Too expensive to check for attack Feature in recent Intel CPUs to record constantly last few branches To and from addresses, in privileged Intuition: attacks involve effect outside registers subverted process Small fixed size (16) circular “stack” So, attack must add or change a Key feature added in Nehalem: filter by system call type Some particularly useful for attacks System calls and library calls In-process hooking System calls: exported from privileged Add extra code to run at start of library code function More OS-specific, especially for Windows Offensive and defensive technique Library / API calls: higher-level interface for use of applications Typical approach: overwrite first few Includes C standard functions like ♣r✐♥t❢ , code bytes other specific to Windows Problem: in-process security checks Problem: at system calls, often LBR can be bypassed filled by library code
Checkpointing approach Detection: returns not to call sites Calls and returns don’t always match correctly Use hook to check for ROP on library E.g. ❧♦♥❣❥♠♣ , user-space threads, etc. entry point But, the target of a return is an If no ROP detected, store “checkpoint” instruction directly after a call record Approach: check if each return address On system call, verify appropriate is preceded by a call checkpoint, then clear Any return without call ✦ detect attack Kinds of gadgets Detection: chaining of gadgets Most convenient gadgets are short and Hypothesis: ROP has longer chains of end in return shorter code segments than benign Gadgets ending in non-return jumps code (JOP) demonstrated in theory Detect attack if at least 8 consecutive But not common in current attacks LBR entries are all gadget-sized Long gadgets harder to program with Maximum observed in benign code: 5 This paper’s definition: up to 20 before sensitive calls, 9 anywhere instructions, need not be contiguous Outline Upcoming topics Background 2/17 Smartphone security LBR-based approach 2/24 Web application security 3/3 (Anti-)censorship Administrative break 3/10 Tor kBouncer implementation After spring break: rough ideas, will finalize after finding more papers Limitations and counterattacks
Project meetings Outline Background LBR-based approach Purpose: discuss project topics Email me to set up Administrative break This Friday is the last day kBouncer implementation Limitations and counterattacks Windows 7 implementation Pin-based simulator Simulate LBR in software using Gadget analysis performed in advance dynamic translation Implemented with Pin, a commonly-used online framework Hooking layer for Windows API calls Collect statistics on benign software, Kernel module for LBR checks used in design System call checking prevented by Not fast enough to use as a practical PatchGuard defense Performance measurements Off-the-shelf attacks Adapted previously-published ROP Microbenchmarks: slowest is reading attacks process code, worst-case 4.7 ✖ s From blogs, Metasploit, etc. API-heavy workload: Wine API test To work: rolled back IE version, fixed one suite out-of-date offset Average overhead 1% (5 ✖ s/call), Without kBouncer, all attacks succeed worst-case 4% Argue: would be unnoticeable for normal With kBouncer, all attacks blocked apps
Outline API selection Background Paper gives 52 currently protected LBR-based approach functions Empirically, a blacklist this long is Administrative break usually found later to be missing entries kBouncer implementation Protect all API calls? Paper argues would be excessive Limitations and counterattacks LBR size Is ROP still possible? LBR size is fixed in hardware Thorough analysis: “part of future work” Might get bigger in subsequent chips 6.4% of gadgets are call-preceded, (3% However, even in LBR size were of shorter 5-byte ones) unlimited, might still want to limit One automated system fails when checks for performance limited to 20% of gadgets Problem: attackers don’t care about performance; if limit is ❦ , adversary uses But human attackers can be more ❦ ✰ ✶ creative Gadget size Attacks against host IDSes C.f. “Automating Mimicry Attacks Using To stop chaining detection, find a few Static Binary Analysis”, USENIX’05 large gadgets Attacker has taken over binary, but Increasing detection length beyond 20 must conceal attack system calls might bring false positives Key challenge: how to regain control Think about reusing larger chunks of after system call with legitimate-looking code, not just gadgets call stack E.g., subvert code that calls a sensitive Short answer: overwrite indirect jump function pointers
Recommend
More recommend
