Shimin Chen (LBA Reading Group Presentation)

1. 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)

2. 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

3. 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  Cannothandle 3rd-party library  Require manual annotations for library routines

4. 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

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

6. 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.)

7. 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

8. Outline • Introduction • Basic Implementation • Optimizations • Evaluation • Summary

9. 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

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

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

12. 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

13. 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

14. 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

15. 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

16. Outline • Introduction • Basic Implementation • Optimizations • Evaluation • Summary

17. 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

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

19. Overhead with Apache Results Overhead Results Overhead

20. Overhead with SPEC INT

21. How frequent is fast path used?

22. How effective is merged check optimization?

23. 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

24. Thank You!

25. Backup Slides

26. 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

27. 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

28. 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!!!

29. 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

30. 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.

31. 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

32. 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

34. Extra bits

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

36. 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.

37. 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)