vulnerability-specific execution filtering for exploit prevention on commodity software
DESCRIPTION
Vulnerability-Specific Execution Filtering for Exploit Prevention on Commodity Software. James Newsome David Brumley, Dawn Song. Carnegie Mellon University. All vulnerable hosts attacked. First host attacked. Reaction time. Danger: Zero-day exploits. Slammer: 10 mins. - PowerPoint PPT PresentationTRANSCRIPT
1
Vulnerability-Specific Execution Filtering for Exploit Prevention on Commodity Software
James NewsomeDavid Brumley, Dawn Song
Carnegie Mellon University
2
Danger: Zero-day exploits
First host attacked
All vulnerable hosts attacked
Reaction timeSlammer: 10 mins
Future worms: < 1 minute [Staniford et. al. 2002]
Any reaction must be automatic
3
Sting: End-to-End Automatic Worm Defense
ExploitDetected!
4
Antibody Requirement: Vulnerability-Specific
⢠Signatures are typically exploit-specificâ Honeycomb [Kreibich et. al. 2003],
Earlybird [Singh et. al. 2003], Autograph [Kim et. al. 2004]
⢠Not robust against polymorphismâ Use encryption and code obfuscation to automatically
rewrite exploit code each time
⢠Antibodies should be vulnerability-specific
5
Related Work: Vulnerability-Specific Input Filters
⢠Vigilante [Costa et. al. 2005]⢠Vulnerability-Based Signatures [Brumley et. al. 2006]⢠âCorrectâ filter can be excessively large or expensive⢠Do not automatically take process state into account
â Current decryption key (needed for encrypted protocols)â Configuration (vulnerable feature enabled?)
6
Our Approach: Vulnerability Specific Execution Filtering (VSEF)
⢠Execution filtering instead of input-based filteringâ Greater accuracyâ Works with encrypted protocols
⢠Approach:â Assuming monitoring points detect new attacks â Generate execution filter specifying detection code needed to
detect attacks against that vulnerability
⢠Efficiency:â Only monitor execution for vulnerability-related segmentsâ In contrast to traditional full protection:
Âť Rewrite binary to insert checks at every potential vulnerabilityÂť Problem: Too slow to use everywhere all the time
7
VSEF Example⢠buf[j] = x⢠âŚâ˘ anotherbuf[k] = y⢠âŚâ˘ yetanother[m] = z
Vulnerable Program
⢠buf[j] = x⢠âŚâ˘ if (k>KMAX)âŚâ˘ anotherbuf[k] = y⢠âŚâ˘ yetanother[m] = z
Vulnerability-Specific Execution Filtering
Full Execution Filtering
⢠if (j>JMAX)âŚâ˘ buf[j] = x⢠âŚâ˘ if (k>KMAX)âŚâ˘ anotherbuf[k] = y⢠âŚâ˘ if (m>MMAX)âŚâ˘ yetanother[m] = z
8
VSEF
VSEF Architecture
SampleExploit
ExploitDetector
Exploit execution
trace VSEF FilterGeneration
VSEF Binary Instrumentation
Engine
VSEF Filter
HardenedBinary
Program
VulnerableBinary
Program
9
VSEF Properties
⢠Vulnerability-specific, not exploit-specificâ Robust to polymorphism
⢠Low risk of false positives⢠Low performance overhead⢠Works on encrypted protocols⢠Works on commodity software
10
Outline
⢠Overview⢠Taint-based VSEF⢠Destination-based VSEF⢠Distributed protection⢠Conclusion
11
Exploit Detection: Dynamic Taint Analysis
⢠Detects overwrite attacksâ Buffer overflowsâ Format string attacksâ Double free attacks
⢠Dynamic Taint Analysis: â Keep track of tainted data from untrusted sourcesâ Detect when tainted data is used in a sensitive way
Âť e.g., as return address or function pointer
⢠We use TaintCheck [Newsome et. al. 2005]⢠Others:
â [Suh et. al. 2004], [Costa et. al. 2004], [Crandall et. al. 2004]
12
Full Dynamic Taint Analysis
1. recv(socketfd, buf1, âŚ)NewTaint(buf1, âŚ)
2. memcpy(buf2, buf1, âŚ)PropTaint(buf2, buf1, âŚ)
3. y = xPropTaint(&y, &x, âŚ)
4. strcpy(dummy->buf, buf1)PropTaint(dummy->buf, buf1, âŚ)
5. dummy->fnptr()TaintAssert(&fnptr, âŚ)
MISUSE!
x
y
buf1
buf2
dummy->buf
dummy->fnptr
Memory Map
13
Taint-Based VSEF
⢠Full taint analysis: most instructions instrumentedâ 3 to 40x slowdown
⢠Only a few are relevant to a particular vulnerability⢠Strategy:
â Detection: Track which instructions propagate or misuse taintâ VSEF generation: Identify relevant instructionsâ VSEF instrumentation: Instrument only relevant instructions
14
Taint-Based VSEF filter generation
1. recv(socketfd, buf1, âŚ)NewTaint(buf1, âŚ)
2. memcpy(buf2, buf1, âŚ)PropTaint(buf2, buf1, âŚ)
3. y = xPropTaint(&y, &x, âŚ)
4. strcpy(dummy->buf, buf1)PropTaint(dummy->buf, buf1)
5. dummy->fnptr()TaintAssert(&fnptr)
MISUSE!
x
y
1buf1
buf2 2
dummy->buf
dummy->fnptr4
Memory Map
VSEF filterTaint misuse at:
5Taint propagation at:
41
15
Taint-Based VSEF binary hardening
1. recv(socketfd, buf1, âŚ)NewTaint(buf1, âŚ)
2. memcpy(buf2, buf1, âŚ)
3. y = x
4. strcpy(dummy->buf, buf1)PropTaint(dummy->buf, buf1)
5. dummy->fnptr()TaintAssert(&fnptr)
MISUSE!
1buf1
dummy->buf
dummy->fnptr4
Memory Map
VSEF filterTaint misuse at:
5Taint propagation at:
41
16
False positive analysis: untainting
⢠Challenge: instruction not in filter overwrites tainted data with clean data
⢠Solution 1: untaint heuristicâ Record value of tainted memoryâ Value changes untaintâ Drawback: uninstrumented instruction may overwrite tainted
memory with same value it already had
⢠Solution 2: hardware assistanceâ Use hardware assistance to detect writes to tainted memoryâ E.g., memory watch points, write-protected pagesâ Drawback: not always available, trap on write to tainted
memory
17
Path 2: 1,5,6
False negative analysis: polymorphism
⢠Immune to polymorphism (code encryption)⢠False negative if exploited via alternate execution path
â Not many such paths possibleâ Attacker has to manually find alternate execution pathsâ Can merge VSEFs when we observe another execution path
1. recv(buf, socketfd, âŚ)2. if (buf[0] == 1)3. while((dummy->buf[j] = buf[j]) != â\0â));4. else if (buf[1] == 2)5. while((dummy->buf[j] = buf[j]) != â\0â));6. dummy->fnptr();
Union: 1,3,5,6
Path 1: 1,3,6
18
Evaluation
⢠Experiment 1: Valgrind implementation (Linux)â ATPhttpd web serverâ Invalid URL buffer overflowâ Use Flood tool to fetch 1 KB pages
⢠Experiment 2: DynamoRIO implementation (Windows)â SQL Serverâ SQL Slammer exploitâ Simple SELECT query
19
Performance Evaluation
⢠ATPhttpd (Valgrind on Linux)â 186 us to generate VSEF from execution traceâ 195 ms to harden binaryâ Hardened binary
Âť 6% overhead over Valgrind Âť 140% over native
⢠SQL Server (DynamoRIO on Windows)â Hardened binary
Âť 3% over DynamoRIOÂť 14% over native
20
Accuracy Evaluation
⢠No false positives during performance analysis⢠Successfully detects original attack⢠Successfully detects polymorphic variants
â Replaced attack-code with random byte values
21
Properties of Taint-based VSEF
⢠Accurateâ Zero or low false positivesâ Low false negatives, effective for polymorphic worms
⢠Fast generationâ Negligible time from execution trace
⢠No side-effect on normal executionâ Does not change normal program execution behaviorâ No extra testing needed
⢠Efficientâ Low performance overhead (10% over Valgrind)
22
Outline
⢠Overview⢠Taint-based VSEF⢠Destination-based VSEF⢠Distributed protection⢠Conclusion
23
Destination-Based VSEF
⢠One of the propagation instructions is overwrite pointâ e.g., the instruction that overwrote the function pointer
⢠Overwrite-point wrote to unintended destination⢠Strategy:
â Filter generation: identify overwrite point, and destinationâ Binary hardening: instrument overwrite point
⢠Advantages:â Only one instruction to instrumentâ Detect attack at time-of-overwrite instead of time-of-misuse
24
Destination-Based VSEF filter generation
1. recv(socketfd, buf1, âŚ)NewTaint(buf1, âŚ)
2. memcpy(buf2, buf1, âŚ)PropTaint(buf2, buf1, âŚ)
3. y = xPropTaint(&y, &x, âŚ)
4. strcpy(dummy->buf, buf1)PropTaint(dummy->buf, buf1)
5. dummy->fnptr()TaintAssert(&fnptr)
MISUSE!
x
y
1buf1
buf2 2
dummy->buf
dummy->fnptr4
Memory Map
VSEF:Overwrite Point:
main(), vuln(), strcpy(), 0x.âŚOverwrite destination:
dummy->fnptr
25
Destination-Based VSEF binary hardening
1. recv(socketfd, buf1, âŚ)
2. memcpy(buf2, buf1, âŚ)
3. y = x
4. strcpy(dummy->buf, buf1)WriteAssert(&dummy->fnptr, âŚ)
5. dummy->fnptr()
VSEF:Overwrite Point:
main(), vuln(), strcpy(), 0x.âŚOverwrite destination:
dummy->fnptr
26
False positive analysis
⢠Wrong instruction as overwrite point⢠Overwrite instruction can legitimately write there
â Example: C union of a buffer and a function pointer
27
False negative analysis
⢠Conventional polymorphism is no problem⢠Polymorphic execution path
â Different overwrite instructionâ Different contextâ Different destination
28
Implementation
⢠VSEF generationâ Use execution trace from TaintCheckâ Overwrite point = last write to a dynamically calculated
address
⢠VSEF hardeningâ Use Dyninst to insert check at overwrite point
29
Evaluation
⢠Used ATPhttpd vulnerable web server⢠Performance
â 3% over native execution
⢠No false positives⢠No false negatives
â Including polymorphic variants
30
Comparison to Taint-Based VSEF
⢠More efficient: only 3% overhead over nativeâ (vs. Taint-Based was 6% over Valgrind, 140% over native)â Fewer instructions instrumentedâ Pseudo-static rewriting using Dyninst
⢠Detects at time-of-write instead of time-of-useâ Could be an important distinction in future work
31
Outline
⢠Overview⢠Taint-based VSEF⢠Destination-based VSEF⢠Distributed protection⢠Conclusion
32
Application: Reactive Antibody Defense
ExploitDetected!
33
Distribution & Verification
⢠Distribution speedâ Need exponential distribution to match worm speedâ Use a robust P2P architecture
⢠Verificationâ Poor \ Malicious Taint-Based VSEF only hurts performanceâ Generate hardened binary candidate using VSEFâ Replay exploit against hardened candidateâ Exploit detected: optimize and accept VSEFâ No exploit detected: reject VSEF
34
Related Work
⢠Syntax pattern-extraction signature generationâ Honeycomb [Kreibech2003]â Autograph [Kim2004]â Earlybird [Singh2004]â Polygraph [Newsome2005]
⢠Vulnerability-based signature generationâ Vigilante [Costa2005]â Vulnerability-based Signatures [Brumley2006]
⢠Host-based antibody generationâ Shadow honeypots [Anagnostakis2005]â STEM [Sidiroglou2005]â COVERS [Liang2005]â [Xu2005]
35
Conclusion
⢠We propose a new form of exploit antibody: VSEF⢠Advantages of VSEF approach:
â Only run heavy detector on some fraction of all trafficâ Only need 1 exploit sample to automatically generate VSEF filterâ VSEF filter is light-weight and accurateâ Works on commodity software (no access to source code)
⢠VSEF enables automated, fast, accurate response to zero-day exploits
36
DynInst vs. Valgrind experience
⢠DynInst is an excellent tool+ Nice, well documented API+ Good performance (for âsurgicalâ modifications)+ Works on Linux and Windows+ Good support (Thanks Drew!)
⢠Valgrind, compared to DynInst+ Easier to develop (abstraction)+ More suitable for âtotal rewriteâ applications?â Linux onlyâ Poor performance
⢠Ideas to consider âborrowingâ from Valgrindâ System call callbacks, and abstractionâ Instruction set abstraction (DynInst does this a little)â Shadow memory support