1 Marple: A Demand-Driven Path- Sensitive Buffer Overflow Detector Wei Le and Mary Lou Soffa University of Virginia

22 Motivation: Buffer Overflow 20 years since exploited by Morris worm Always a popular attack vector – E.g., 482 new exploitable vulnerabilities 204 buffer overflows reported by SecuriTeam in 2007 Remain due to legacy code and the fact that many companies still heavily depend on C and C++

33 Challenge ： Reduce attacks Detect and report where vulnerabilities occur Determine cause and remove it Be automatic and usable with manageable manual effort Scale to large software

4 A framework, Marple, for detecting buffer overflow: As precise as possible Helpful for understanding and removing overflow Scalable Key idea: Identify paths that lead to buffer overflow Approach: – Interprocedual path-sensitive for precision and help diagnosis – Demand-driven for scalability 4 Our Goals and Overall Approach

5 Value of paths and paths classification Demand-driven analysis Vulnerability model Framework summary Experiments Conclusions 5 Outline of the talk

6 i = strlen (a→q_user) i ≥ sizeof (buf0) buf = xalloc (i+1) buf = buf0 strcpy(buf, a→q_user) yesno Paths-Insensitive: Detecting an Overflow buf = xalloc (i+1) V buf0 i ≥ sizeof (buf0) i < sizeof (buf0)

7 i = strlen (a→q_user) i ≥ sizeof (buf0) buf = xalloc (i+1) buf = buf0 strcpy(buf, a→q_user) yesno Paths-Sensitive: Detecting an Overflow i ≥ sizeof (buf0) buf = xalloc (i+1) i < sizeof (buf0) buf = buf0

8 n rootd = 1rootd = 0 strlen(wbuf)+rootd+1+ strlen(resolved) > LEN rootd == 0 strcat(resolved, “/”) strcat(resolved, wbuf) exit y n y yn wu-ftpd realpath.c Paths-Insensitive: Reporting an Overflow

9 n rootd = 1rootd = 0 strlen(wbuf)+rootd+1+ strlen(resolved) > LEN rootd == 0 strcat(resolved, “/”) strcat(resolved, wbuf) exit y n y yn Safe Overflow Infeasible wu-ftpd realpath.c Paths-Sensitive: Reporting an Overflow

10 Infeasible: no input can exercise the path Safe: no input can overflow the buffer Vulnerable: users can write any content to the buffer Overflow-user-independent: the buffer content is statically determinable Don’t-know: the buffer status cannot be judged statically 10 Five Types of Paths

11 Demand-Driven Analysis for Buffer Overflow Two Steps: – Find all potentially overflow statements in the program – Examine paths from a potentially overflow statement to the entry to see if an overflow can occur - backwards Benefits: scalability and natural parallelism

12 Vulnerability Model 5-tuple (POS, δ, UPS, γ, r), where POS and UPS are finite sets, and POS: set of potentially overflow statements δ: mapping POS->Q, and Q is set of buffer queries UPS: set of statements where queries are updated r : mapping UPS->E, where E is set of equations R: general security policy to judge the termination of the search

13 Partial Vulnerability Model for Buffer Overflow POS/PUSQueryEquations strcpy(a,b)Size(a) > Len(b)Len’(a) = Len(b) strcat(a,b)Size(a) > Len(a) + Len(b)Len’(a) = Len(b) + Len(a) strncpy(a,b,n)Size(a) > Min(Len(b), n)(Len’(a) = ∞ && Len(b) >= n) || (Len’(a) = Len(b) &&Len(b) < n) a[i] = ’t’Size(a) > iLen’(a) = ∞ Security policy - after a write to the buffer, the declared buffer size must be no less than the length of the string stored in the buffer Answers - infeasible, safe, vulnerable, overflow-input-independent, and don’t-know

14 n rootd = 1rootd = 0 strlen(wbuf)+rootd+1+ strlen(resolved) > LEN rootd == 0 strcat(resolved, “/”) strcat(resolved, wbuf) exit y n y yn Demand-Driven Analysis: An Example …… char resolved [LEN ] Q (s+1<l, f) Q (LEN-rootd<l, f) Solved Q (s+1<l, f) Infeasible Q (s<l, f) s: strlen(resolved)+strlen(wbuf) l: sizeof(resolved) f: wbuf Q (LEN<l, f)

15 POS Queries Equations Policy Detect Infeasible Paths Program The Vulnerability Model no yes Source Raise Queries Propagate Queries Update Queries Evaluate Queries Propagate Answers Assist Diagnosis The Demand-Driven Path-Sensitive Analyzer Path Classification Root Cause Information Marple Framework

16 Entry POS User Scenario A

17 Entry POS Vulnerable Overflow User Independent User Scenario

18 Entry POS Vulnerable Overflow User Independent User Scenario

19 Entry POS Root Cause Vulnerable Overflow User Independent User Scenario

20 Goals – More precisely find vulnerabilities – False positives in vulnerable set – Scalable – Help in diagnosis – Comparison with other tools Experimental Setup – Microsoft Phoenix, Disolver – BugBench, Buffer Overflow Benchmark, MechCommander2(570.9K) 20 Experiments

21 Results: Detection BenchmarkPOSDetected Bugs ReportedNew polymorph1534 ncompress38111 gzip3819 bc24533 wu-ftp1340 sendmail2122 BIND481/00 MechComm ander /028/1 Detect 14 out of 16 documented overflow -1 don’t-know : library call - 1 missing: function pointers Report 57 new overflows same path of different buffers Generate 1 false positive due to integer range analysis

22 Results: Path-Sensitivity BenchmarkPOSPath Prioritization VOU polymorph15612 ncompress gzip bc wu-ftp13314 sendmail21316 BIND MechComm ander All types of paths occur 108 don’t knows from bc 43 complex pointers 28 recursive procedures 15 loops 12 non-linear operations 8 library calls

23 Results: Root Cause BenchmarkPOS Root Cause Info StmtAve. No Polymorph ncompress gzip bc wu-ftp sendmail BIND48N/A MechComm ander Highlight statements that update query during analysis as r oot cause information Average highlighted less than 10 Path-sensitive root cause exists

24 Marple with static tools Used Buffer Overflow Benchmark – 14 programs “Bad” version – several overflows marked “Good” version – overflows fixed Static Tools: Archer, Boon, UNO, Splint and Polyspace (commercial tool) Criteria: probability of detection and probability of false alarms

25 P(f) – probability of false alarms P(d) – Prob of detection BOON Splint (0.43,0.57) PolySpace (0.5,0.87) ARCHER, UNO ROC Curve Marple-B (0.42, 0.88) Marple-A (0.04, 0.49) Ideal Tool (0,1) Marple A - using only Vulnerable/overflow Marple B – Marple A + Don’t know Zitser, Lippmann And Leek, FSE Marple with static tools

26 Performance Visited: 43% of nodes; 52% of procedures Memory – 2.5GB Time – MechComander2 (575K lines) – 35.4 minutes – Archer – 121 lines/sec – IPSSA – 155 lines/sec – Marple – 254 lines/sec

27 Static Detection for Buffer Overflow ARCHER [03xie] BOON [00wagner] ESPx [06hackett] Prefast [ms] Prefix [00bush] Splint [96evans] Path-Sensitive Analysis for Defects ARCHER [03xie] ESPx [06hackett] ESP [02das] IPSSA [03livshits] MOPS [02check] Prefix [00bush] Demand-Driven Approach − A general framework [96Duesterwald] − Application for dataflow computation [96Duesterwald], infeasible detection [97bodik], memory leak [06Orlovich], postmortem analysis [04Manevich] Related Work

28 An interprocedual demand-driven path-sensitive buffer overflow detection for large software A categorization of paths to assist diagnosis The identification of vulnerable path segments and the statements relevant to the root cause Our results demonstrate that Marple is scalable and can report buffer overflow with low false positive rates and rich diagnosis information 28 Conclusions

29 Thank you and Questions?