1. Static Analysis for Security POSTECH Laboratory for UNIX Security (PLUS) Kwang Yul Seo skyul@postech.ac.kr

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 • Time cosuming • Auditor dependent • Automatic • Fast • Easy to use

5. Pitfalls • Aim for good, not perfect • 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(www.dwheeler.com/flawfinder) • RATS(www.securesoftware.com) • 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 • 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 • 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 http://www.cigital.com/papers/download/bsi5-static.pdf