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 3rd-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

Results

OverheadOverhead

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)