1 / 29

Marple: A Demand-Driven Path-Sensitive Buffer Overflow Detector

Marple: A Demand-Driven Path-Sensitive Buffer Overflow Detector. Wei Le and Mary Lou Soffa University of Virginia. Motivation: Buffer Overflow. 20 years since exploited by Morris worm Always a popular attack vector

shae
Download Presentation

Marple: A Demand-Driven Path-Sensitive Buffer Overflow Detector

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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++ 2

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

  4. Our Goals and Overall Approach 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

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

  6. Paths-Insensitive: Detecting an Overflow i = strlen (a→q_user) 1 i ≥ sizeof (buf0) 2 yes no i ≥ sizeof (buf0) i < sizeof (buf0) 3 buf = xalloc (i+1) buf = buf0 4 buf = xalloc (i+1) V buf0 5 strcpy(buf, a→q_user)

  7. Paths-Sensitive: Detecting an Overflow i = strlen (a→q_user) 1 i ≥ sizeof (buf0) 2 yes no 3 buf = xalloc (i+1) buf = buf0 4 i ≥ sizeof (buf0) buf = xalloc (i+1) i < sizeof (buf0) buf = buf0 strcpy(buf, a→q_user) 5

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

  9. Paths-Sensitive: Reporting an Overflow Safe Infeasible Overflow 1 y n 2 3 rootd = 1 rootd = 0 4 strlen(wbuf)+rootd+1+ strlen(resolved) > LEN 5 y n exit 6 rootd == 0 y wu-ftpd 2.6.2 realpath.c 7 n strcat(resolved, “/”) 8 strcat(resolved, wbuf)

  10. Five Types of Paths • 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

  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

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

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

  16. User Scenario Entry A POS

  17. User Scenario Entry Overflow User Independent Vulnerable POS

  18. User Scenario Entry Overflow User Independent Vulnerable POS

  19. User Scenario Entry Overflow User Independent Vulnerable Root Cause POS

  20. Experiments • 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

  21. Results: Detection • Detect 14 out of 16 documented overflow • 1 don’t-know : library call • 1 missing: function pointers • Generate1false positivedue tointeger range analysis • Report57new overflows • same path of different buffers

  22. Results: Path-Sensitivity • 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 • Highlight statements that update • query during analysis as root 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. Marple with static tools Ideal Tool (0,1) Marple-B (0.42, 0.88) PolySpace (0.5,0.87) Marple A - using only Vulnerable/overflow Marple-A (0.04, 0.49) P(d) – Prob of detection Marple B – Marple A + Don’t know Splint (0.43,0.57) ROC Curve Zitser, Lippmann And Leek, FSE ARCHER, UNO BOON P(f) – probability of false alarms

  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. Related Work • 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] 27

  28. Conclusions • 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

  29. Thank you and Questions? 29

More Related