1. Static Analysis for Security
POSTECH Laboratory for UNIX Security (PLUS)
Kwang Yul Seo

2. Static Analysis for Security
Detecting security problems through source code (or binary)
Identifying many common coding problems automatically

3. Dynamic vs Static
Static tools examine the text of a program statically, without attempting to execute it
Source code
Binary
E.g., Java Bytecode
Dynamic
Poor testability: due to hard-to-reach states, unusual circumstances

4. Manual vs Automatic Manual Automatic Time cosuming Auditor dependent
Fast
Easy to use

5. Pitfalls Aim for good, not perfect Require human evaluation
Check a fixed set of patterns, or rules in the code
Require human evaluation
Priority, supression
Undecideable
Rice’s theorem: every non-trivial problem-> halting problem
False negatives <-> False positives

6. Example of Static Analysis: grep
Grep can be a static analysis tool for security
$ grep gets *
Cannot differntiate comments, declarations, defintions…
(1) gets(&buf);
(2) /* never ever call gets */
(3) int begetsNextChild = 0;
Lexical analysis is required!

7. Lexical Analysis Tools
ITS4
FlawFinder(
RATS(
Matt Bishop & Mike Dilger’s TOCTOU(time-of-check time-of-use) check tool
Preprocess and tokenize the source files, and then match the result token stream against a library of vulnerable constructs

8. Lexical Analysis Tool: Pitfalls
No semantic checks!
Many false positives
Must borrow compiler technologies
E.g., AST (Abstract Syntax Tree)
Data-flow analysis

9. Analysis Scopes Local analysis Module-level analysis
One function at a time
Module-level analysis
One class/or compilation unit
Global(interprocedural) analysis
Entire program
More context is better, but computation grows so fast!

10. Tool Tradeoffs Sound vs unsound Flexible(General) vs special-purpose
General tools are able to read definitions of bugs and apply them

11. Example: Boon Integer range analysis However, Bool is imprcise
Catch bugs indexing an array outside its bounds in C
However, Bool is imprcise
Ignores statement order
Can’t model interprocedural dependencies
Ignores pointer aliasing

12. Example: CQual Inspired by Perl’s taint mode
Detects format string vulnerabilities in C programs
Use type qualifiers to perform a taint analysis
Annotate a few variables as tainted/untainted
Use type inference rules to propagate the qualifiers
The system can check format string bugs by type checking

13. Example: xg++
Use template-driven compiler extension to find kernel vulnerabilities in Linux/OpenBSD
Looks for locations where kernel uses data from untrusted source without checking it first
E.g., A user can cause the kernel to allocate memory and not free it
A user can cause the kernel to deadlock

14. Example: Eau Claire
Use a theorem-prover to create a general specification-checking framework for C programs
Find common security bugs
Buffer overflows
File access race conditions
Format string bugs
Developers can use specifications to verify that a function implementations behave as expected

15. Example: MOPS
Model-checking approach to look for violations of temporal safety properties
Developer can model their own safety properties
Privilege management errors
Incorrect construction of chroot jails
File access race conditions
Ill-conceived temporary file schemes

16. Example: Splint Extends lint concept into security realm
By adding annotations, find
Abstraction violations
Unannounced modifications to global variables
Possible use-before-initialization
Reason about minimum and maximum array bounds accesses if it is provided with function pre and post conditions

17. Example: Other tools ESP, a large-scale property verification approach
Model checkers such as SLAM and BLAST
Use predicate abstraction to examine program safety properties
FindBugs, a lightweight checker with a good reputation for unearthing common errors in Java programs

18. Further Requirements Easy to use even for non-security people
Easy to apply regularly

19. Revised Software Development Life Cycle

20. References Static Analysis for Security by Gary McGraw