1 / 10

Improving Security Using Extensible Lightweight Static Analysis

Improving Security Using Extensible Lightweight Static Analysis. David Evans and David Larochelle. Presented by Joe Combs - 12 April 2006. Topics. Static analysis concepts Splint Described Splint Limitations/Analysis Real world results. Static Analysis Concepts. Ways of eliminating flaws:

tea
Download Presentation

Improving Security Using Extensible Lightweight Static Analysis

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. Improving Security Using Extensible Lightweight Static Analysis David Evans and David Larochelle Presented by Joe Combs - 12 April 2006

  2. Topics • Static analysis concepts • Splint Described • Splint Limitations/Analysis • Real world results

  3. Static Analysis Concepts • Ways of eliminating flaws: • Human code reviews • Testing • Static Analysis • Most attacks stem from repeated exploits of well-known problems • Tools can help codify what is known about common vulnerabilities

  4. Static Analysis Concepts • Low end - standard compilers performing type checking and other simple analysis • Other extreme - formal specification with theorem prover • Lightweight analysis seeks a happy medium

  5. Splint (aka LCLint) • ANSI C static analysis tool (www.splint.org) • The halting problem comes into play when asking non-trivial questions about code so Splint makes compromises and approximations to do its work • Checking rules can be strengthened or weakened to balance False Accepts & Rejects • Relies on annotations - /*@someAnnotation*/ • applied to function parms & return values, globals variables and struct fields

  6. Splint Limitations/Analysis • Analysis limited to data flow within procedure bodies • Control flow paths considered but to limit combinatorial explosion paths are merged at break points • Loops checked for common idioms but convoluted code can throw it off (a challenge for human readers as well!)

  7. Splint Sample Annotations • /*@notnull@*/ • think of it as a type qualifier • /*@only@*/ • implies ownership of a memory location and obligation to release storage • /*@warn bufferoverflowhigh@*/ • can be used to trigger a warning when unsafe functions like gets() are used

  8. Splint Sample Annotations • /*@nullterminated@*/ • /*@requires maxSet(s1)>=maxRead(s2)@*/ • useful for ensuring things like strcpy don’t result in a buffer overflow • Extensibility! • /*@tainted@*/

  9. Splint Metrics • A real world example: the Washington University FTP daemon (8000 Lines of code) • first pass - 166 warnings • 66 annotations added • final pass - 101 warnings • 25 legitimate errors • 76 false positives

  10. Conclusions • Lightweight static analysis is important but no replacement for runtime controls, systematic testing and security assessments • Splint only catches code inconsistencies, language conventions, and assumptions documented in annotations • Building up annotations and checking rules will take time • Can’t detect design flaws

More Related