Static analysis for security
1 / 20

Static Analysis for Security - PowerPoint PPT Presentation

  • Uploaded on

Static Analysis for Security. POSTECH Laboratory for UNIX Security (PLUS) Kwang Yul Seo [email protected] Static Analysis for Security. Detecting security problems through source code (or binary) Identifying many common coding problems automatically. Dynamic vs Static.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Static Analysis for Security' - morton

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Static analysis for security

Static Analysis for Security

POSTECH Laboratory for UNIX Security (PLUS)

Kwang Yul Seo

[email protected]

Static analysis for security1
Static Analysis for Security

  • Detecting security problems through source code (or binary)

  • Identifying many common coding problems automatically

Dynamic vs static
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

Manual vs automatic
Manual vs Automatic

  • Manual

    • Time cosuming

    • Auditor dependent

  • Automatic

    • Fast

    • Easy to use


  • 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

Example of static analysis grep
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!

Lexical analysis tools
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

Lexical analysis tool pitfalls
Lexical Analysis Tool: Pitfalls

  • No semantic checks!

  • Many false positives

  • Must borrow compiler technologies

    • E.g., AST (Abstract Syntax Tree)

    • Data-flow analysis

Analysis scopes
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!

Tool tradeoffs
Tool Tradeoffs

  • Sound vs unsound

  • Flexible(General) vs special-purpose

  • General tools are able to read definitions of bugs and apply them

Example boon
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

Example cqual
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

Example xg
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

Example eau claire
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

Example mops
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

Example splint
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

Example other tools
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

Further requirements
Further Requirements

  • Easy to use even for non-security people

  • Easy to apply regularly


  • Static Analysis for Security by Gary McGraw