LIFT: A Low-Overhead Practical Information Flow Tracking System for Detecting Security Attacks - F. Qin, C. Wang, Z. Li, H. Kim, Y. Zhou, Y. Wu (UIUC, Intel, Ohio State) Shimin Chen (LBA Reading Group Presentation)

Motivation Many security tools target specific types of vulnerabilities: e.g. StackGuard, LibSafe both target stack smashing attacks Less effective for unknown vulnerabilities Information flow tracking can help Detect security attacks Detect information leaking  Problems with existing information flow tracking approaches

Problems with Existing Approaches(1) Compile time analysis for type-safe languages No runtime overhead  Not applicable to legacy application or C/C++  Often can only detect info leaking not security attacks Binary-code instrumentation No restrictions on programming language or library  High runtime overhead Source-code instrumentation Lower runtime overhead than binary instrumentation  Cannot handle 3 rd -party library  Require manual annotations for library routines

Problems with Existing Approaches(2) Hardware approaches: Minos [Crandall&Chong’04] h/w based taintcheck Dynamic Info Flow Tracking[Suh et al. 04] h/w based taintcheck RIFLE [Vachharajani et al. 04] h/w based infomation leaking protection

Minos [Crandall&Chong’04]Dynamic Info Flow Tracking [Suh et al. 04]

Problems with Existing Approaches(2) Hardware approaches: Minos [Crandall&Chong’04] Dynamic Info Flow Tracking[Suh et al. 04] RIFLE [Vachharajani et al. 04] Low performance overhead  Non-trivial h/w extensions (tags for registers and memory locations, tag computations, etc.)

Proposal in This Paper: LIFT Dynamic binary instrumentation with aggressive optimizations: Fast Path Merged Check Fast Switch Achieves 6.2% overhead for server apps and 3.6X overhead for SPEC INT

Outline Introduction Basic Implementation Optimizations Evaluation Summary

Basic Implementation TaintCheck using StarDBT 1 tag bit per byte for memory and general register A dedicated register for register tags How to protect the tag space? Tags for the tag space Set read-only page permission If app directly changes tag, then the taintcheck tries to modify tag for the tag, triggering a fault

Example Save context: 5 insts Get [ecx] tag: 11 insts Set ebx tag: 2 insts Restore context: 2 insts App instruction

Outline Introduction Basic Implementation Optimizations Fast Path Merged Check Fast Switch Evaluation Summary

Fast Path (FP) Optimization Safe->Safe dominates server application: Idea: at the beginning of a hot trace, if all live-in and live-out are safe, then no need to track info flow S: safe; U: unsafe

More Details on FP Live-in and Live-out for registers: Compute (once) a bit vector mask per trace At trace beginning, AND mask with current reg tags, if 0 use fast version Memory reference: Checks tag before every memory ref If 0, continue with fast version If 1, switch to the same instruction in slow version Turn off the optimization for a trace if it rarely works

Merged Check Improve fast path optimization further Idea: combine multiple tag checks into one Both temporal locality and spatial locality For each hot trace, examine memory references: Address computed by register (with version) & offset Temporal: same register & same offset Spatial: same register & slightly different offset Use one tag check before the first inst of each group

Fast Switch Optimization Reduce overhead for binary instrumentation Cost of saving and restoring condition flags (eflags) Replace pushf/popf with lahf/sahf Carefully code to only use SF, ZF, AF, PF, CF Liveness analysis of eflags bits If eflags bits are dead, do not need to save

Outline Introduction Basic Implementation Optimizations Evaluation Summary

Methodology Dual-processor Xeon, 64-bit mode, 3.0GHz, 512KB L2, 1GB memory Windows XP 64-bit version Client machine for server application: dual-processor Xeon 21.2 GHz running Linux 2.6.9, 100Mbps Implemented LIFT on StarDBT (by Intel) Security exploits: Apache, Savant, Putty, 18-exploit Attack benchmark Performance: 7 SPEC INT benchmarks & Apache

Security Attach Detection Results of the other columns are from [Wilander & Kamkar, NDSS’03]

Overhead with Apache Results Overhead

Overhead with SPEC INT

How frequent is fast path used?

How effective is merged check optimization?

Summary Propose three optimizations for TaintCheck Fast Path Merged Check Fast Switch Fast Switch is the most effective? Cannot be explained by the code example? Different from LBA results Guess: pure register operation dominates in EM64T? Techniques useful for LBA

Thank You!

Backup Slides

LibSafe Transparent Run-Time Defense against Stack Smashing Attacks – USENIX 2000 (Bell Labs) Libsafe: intercept all unsafe lib calls (gets, getwd, realpath, scanf, fscanf, strcpy, strcat, etc.), replace with safe versions that do not have buffer overflows How large is dest buffer? Up to the frame pointer!!! LD_PRELOAD or /etc/ld.so.preload LibVerify: copy a function code to heap, then execute a prelog + the copy + epilog, where epilog checks return address

StackGuard Change GCC extension (gcc function_prologue and function_epilogue functions) Push a randomized canary word next to return addr Verify the canary before return Alternatively, can use virtual page protection + trap handler to monitor overwrites to return addresses – MemGuard (high overhead) Adaptively use the two

RIFLE IFS (Information Flow System) Each data has label x, each location has label y Check if rule x->y exists for every operation Static checking: label variables then check labels, expression label is a join of labels of the variables in the expression. Cannot handle unsafe language and legacy prog Rules and labels are defined by programmers not users!!!

Dynamic IFS Track the propagation of labels, then enforce the policy at output points. Static IFS and dynamic IFS can leak the same amount of information (if program seg faults are allowed) But dynamic IFS cannot handle the potential info leak through not-taken branches Therefore, dynamic IFS must be conservative to be secure

RIFLE (1) Convert programs targeted for a conventional ISA to programs for an information-flow security ISA. IFS ISA augments all state defined in the base ISA with space to store a label; this includes augmenting both registers and memory. In addition to these base semantics, each instruction in the IFS ISA will use the augmented state to track explicit information flows. To allow translated programs to track implicit flows, the IFS ISA also defines additional security registers to hold auxiliary labels and instructions to manipulate these security registers and the labels affixed to general purpose registers.

RIFLE(2) IFS ISA: Every register and mem location is augmented with a label Additional label registers Common instruction + label compute and assign Branch instruction + put label into label register then use it to deal with implicit control-flow tracking Binary Translation OS enforcement: check the label of output data Evaluation: based on the Liberty Simulation Environment to simulate an IA64 processor

Minos Every 32-bit memory word is enhanced with 1 bit tag OS sets the tag when loading a page Instructions also compute the tag value Control transfer checks the tag and may trap

Extra bits

Minos(2) Implementation and evaluation is based on the Bochs emulator

Dynamic Info Flow Tracking 1 bit per byte Extend processor registers and memory locations Meta data for a page can be all-0, all-1, 1 bit per 4B, or 1 bit per byte. OS determine 4B or 1B meta data on first store to the page: if the store < 4B then use 1B meta data, else use 4B meta data.

More Evaluation: based on simpleScalar tool set Dealing with legitimate uses of spurious data: e.g. switch statement – jump table (compare against a bound then is safe)