Download
improving security using extensible lightweight static analysis n.
Skip this Video
Loading SlideShow in 5 Seconds..
Improving Security Using Extensible Lightweight Static Analysis PowerPoint Presentation
Download Presentation
Improving Security Using Extensible Lightweight Static Analysis

Improving Security Using Extensible Lightweight Static Analysis

94 Vues Download Presentation
Télécharger la présentation

Improving Security Using Extensible Lightweight Static Analysis

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