Static analysis for security
1 / 20

Static Analysis for Security - PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Static Analysis for Security. POSTECH Laboratory for UNIX Security (PLUS) Kwang Yul Seo 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

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.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

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

  • Login