1 / 20

Static Analysis for Security

Static Analysis for Security. POSTECH Laboratory for UNIX Security (PLUS) Kwang Yul Seo skyul@postech.ac.kr. Static Analysis for Security. Detecting security problems through source code (or binary) Identifying many common coding problems automatically. Dynamic vs Static.

morton
Download Presentation

Static Analysis for Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related