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

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

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

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

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

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

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

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