Dynamic Program Security
Aaron Roth
Ali Sinop
Gunhee Kim
Hyeontaek 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.Username
FROM Userlist
WHERE 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.
DONE!
– Throw a security exception if something
dangerous is done with a tainted word:
• Instruction Execution
• Pointer Dereferencing
•…
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 University
ISCA 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
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)
file with tainted absolute path
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 Vlachos2
1Intel Research Pittsburgh 2CMU 3EPFL 4UT Austin
ISCA 2008
Flexible Hardware Acceleration for
Instruction-Grain Lifeguards
Ex. Memory access,
Data Flow
Dynamic Monitoring Tool
(during application execution)
Ex. DBI: 10~100 times
Slowdown
Flexible Hardware Acceleration for
Instruction-Grain Lifeguards
Ex. Memory access,
Data Flow
Dynamic Monitoring Tool
(during application execution)
Applications/bugs, attacks
are always changed
Ex. DBI: 10~100 times
Slowdown
Flexible Hardware Acceleration for
Instruction-Grain Lifeguards
Ex. Memory access,
Data Flow
Dynamic Monitoring Tool
(during application execution)
Good
• Fast and Flexible Lifeguard
Lifeguard-specific
hardware
This paper
Performance
[Crandall & Chong’04], [Dalton et al’07],
[Shetty et al’06], [Shi et al’06], [Suh et al’04],
General-Purpose
[Venkataramani’07], [Venkataramani’08],
improving DBI
[Zhou et al’07]
Poor
[Chen et al’06]
[Corliss’03]
[Bruening’04]
[Luk et al’05]
[Nethercote’04]
Specific Lifeguard
HW
3-8X slowdowns
Dynamic binary
instrumentation (DBI)
10-100X slowdowns
General Purpose: Wide
Range of Lifeguards
[Source] http://www.ece.cmu.edu/~tstrigko/papers/LBA-isca08-final.ppt
Summary
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
MTLB+IF
MTLB
BASE
MTLB+IT
MTLB
BASE
MTLB+IT
MTLB
BASE
MTLB+IT+IF
MTLB+IT
MTLB
BASE
MTLB+IF
MTLB
BASE
average slowdowns
10.0 AddrCheck MemCheck TaintCheck TaintCheck LockSet
9.0
w/ detailed
7.80
8.0
tracking
7.0
6.05
6.0
5.0
4.25
4.21
3.81
4.0
3.27 3.36
3.23
3.20
2.71
3.0
2.29
1.90
2.0
1.51
1.40
1.36
1.02
1.0
0.0
[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