Dynamic Program Security

Aaron RothAli Sinop

Gunhee KimHyeontaek Lim

Security Attacks

• Software that deals with input is potentially vulnerable to attacks:

• Low-level Attacks:– Buffer Overflows: Writing data without bounds

checking can corrupt adjacent memory locations.

• Can overwrite return pointer and hijack control flow…

Security Attacks

• Semantic Attacks:– Everything looks ok at the low-level, but…

SELECT Userlist.UsernameFROM UserlistWHERE Userlist.Username = ‘Username’AND Userlist.Password = ‘Password’

SELECT Userlist.UsernameFROM UserlistWHERE Userlist.Username = ‘Username’AND Userlist.Password = ‘Password’ OR ‘1’=‘1’

Solution?

• Tracking untrusted information– Assign a ‘taint bit’ to every word of memory.

Set to 1 if it came from an untrusted source, or if it was derived from an untrusted register.

– Throw a security exception if something dangerous is done with a tainted word:

• Instruction Execution• Pointer Dereferencing• …

DONE!

Problems?

• A Naïve software implementation of this is slow… (up to 37x slowdown)– Remember PIN?

• A hardware-only implementation risks lots of false negatives/false positives– Doesn’t know about program semantics, or

when data has been verified to be safe

Solution?

Raksha: A Flexible Information Flow Architecture for Software Security

Michael Dalton, Hari Kannan and Christos Kozyrakis

Computer Systems Laboratory, Stanford UniversityISCA 2007

Prior Work

• Software-based methods:+ Flexible– Either require access to source code [Xu et al’06]

or,– Binary instrumentations lead to slowdowns from

3x to 37x [Qin et al’06, Newsome & Song’05]– Not safe with multi-threading [Qin et al’06]

• Hardware-based methods:+ Fast– Hardcoded security policies– Can’t prevent high-level attacks [Dalton et al’06]

Basic Approach• Taint propagation mechanism as mentioned earlier (dynamic

information flow):– Extend all storage by 4-bit tag bits at 32-bit word level.

– One bit for each policy– Each instruction is given one or more classes:

– Floating Point– Move– Integer Arithmetic– Comparisons– Logical

– TPR: Tag Propagation Registers for each active security policy (=4)

– Designates how to compute the result tag from source tag(s) – for each instruction class

– Certain instructions can untaint data:• Example:

– Buffer overwrite: Bounds checking by comparison [Chen et al’05]

Basic Approach (2)

– Checking for security violations:– TCR: Tag Check Registers for each active

security policy (=4)– Specifies which operands should be checked for

tag exception.– Also handles corner cases (false positives):

– Should XOR r1, r1, r1 make r1 untainted?

Even more Raksha

• Trusted processor mode– Access to security policy

• TPR and TCR registers

• User-defined security handler– Raised when an unsafe operation is executed

on a tainted operand– Should distinguish false-positives– Efficient because no kernel/user mode switch

Results

Program Language Attack Detected Vulnerability

gzip C Directory traversal Open file with tainted absolute path

Scry PHP Cross-site scripting Tainted HTML output includes < script >

ProFTPD C SQL injection Unescaped tainted SQL query

polymorph C Buffer overflow Tainted code pointer dereference (return address)

Program Raksha Slowdown

bzip2 1.33x

crafty 1.00x

gap 1.12x

Flexible Hardware Acceleration for Instruction-Grain Lifeguards

Shimin Chen1, Michael Kozuch1, Theodoros Strigkos2, Babak Falsafi3,

Phillip B. Gibbons1, Todd C. Mowry1,2, Vijaya Ramachandran4,Olatunji Ruwase2, Michael Ryan1, Evangelos Vlachos21Intel Research Pittsburgh 2CMU 3EPFL 4UT Austin

ISCA 2008

Flexible Hardware Acceleration for Instruction-Grain Lifeguards

Dynamic Monitoring Tool(during application execution)

Ex. Memory access, Data Flow

Flexible Hardware Acceleration for Instruction-Grain Lifeguards

Dynamic Monitoring Tool(during application execution)

Ex. DBI: 10~100 times Slowdown

Ex. Memory access, Data Flow

Flexible Hardware Acceleration for Instruction-Grain Lifeguards

Ex. DBI: 10~100 times Slowdown

Applications/bugs, attacksare always changed

Ex. Memory access, Data Flow

Dynamic Monitoring Tool(during application execution)

Summary

• Fast and Flexible Lifeguard

Specific Lifeguard General Purpose: Wide Range of Lifeguards

Dynamic binary instrumentation (DBI)10-100X slowdowns

General-Purpose HW improving DBI3-8X slowdowns

Lifeguard-specific hardware

This paper

Pe

rfo

rman

ce

Go

od

Po

or

[Bruening’04] [Luk et al’05]

[Nethercote’04]

[Crandall & Chong’04], [Dalton et al’07], [Shetty et al’06], [Shi et al’06], [Suh et al’04], [Venkataramani’07], [Venkataramani’08], [Zhou et al’07]

[Chen et al’06] [Corliss’03]

[Sou

rce]

htt

p://

ww

w.e

ce.c

mu.

edu

/~ts

trig

ko/p

ape

rs/L

BA

-isca

08-f

inal

.pp

t

Approach

• Identify three main sources of lifeguard overhead– Propagation-style metadata updates

– Metadata checks

– Matadata mapping

• Propose three hardware acceleration techniques– Inheritance tracking (IT)

– Idempotent filters (IF)

– Metadata-TLBs (M-TLB)

• Log-based architecture (LBA)

Results

AddrCheck TaintCheckTaintCheck w/ detailed tracking

LockSetMemCheck

3.23

1.901.02

7.80

6.05

3.813.27 3.36

2.291.36

4.21

2.71

1.51

4.253.20

1.40

0.01.02.03.04.05.06.07.08.09.0

10.0

BA

SE

MT

LB

MT

LB+

IF

BA

SE

MT

LB

MT

LB+

IT

MT

LB+

IT+

IF

BA

SE

MT

LB

MT

LB+

IT

BA

SE

MT

LB

MT

LB+

IT

BA

SE

MT

LB

MT

LB+

IF

ave

rage

slo

wd

owns

[Source] http://www.ece.cmu.edu/~tstrigko/papers/LBA-isca08-final.ppt

Discussion

• Dynamic checking seems to be good…

• Let’s check dynamic checking!

Who Checks?

• Software only– Adaptable to new types of checking– Very slow

• Mostly hardware– Low overheads– Specialized & needs more complex hardware

• HW checks, but SW analyzes ([Dalton et al’07])• SW checks, but HW accelerates ([Chen et al’08])• Other hybrid methods?

What Does It Check?

• Hand-written invariants– Time consuming to write– Error-prone– Can be another source of bug & security

problems!

• Automatically finding invariants?

When Does It Check?

• Immediately checking– Blocks main execution when handling security

exception ([Dalton et al’07])– Stops any error propagation if found– Makes unnecessary latency for false-positives

• Not immediately checking– Records execution log & check it ([Chen et

al’06,’08])– Can hide latency & utilize idle/multiple cores– May be too late to stop error propagation

• Some hybrid methods?

Conclusion

• Dynamic checking– Promising solution to detect security attacks– Abundant research opportunities