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 -
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
think of it as a type qualifier
implies ownership of a memory location and obligation to release storage
can be used to trigger a warning when unsafe functions like gets() are used

8. Splint Sample Annotations
useful for ensuring things like strcpy don’t result in a buffer overflow
Extensibility!

9. Splint Metrics
A real world example: the Washington University FTP daemon (8000 Lines of code)
first pass warnings
66 annotations added
final pass 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