Static Analysis methods and tools An industrial study. Pär Emanuelsson Ericsson AB and LiU Prof Ulf Nilsson LiU

Similar documents
Simple Overflow. #include <stdio.h> int main(void){ unsigned int num = 0xffffffff;

Static Analysis of C++ Projects with CodeSonar

Static Analysis. Systems and Internet Infrastructure Security

Static Analysis in C/C++ code with Polyspace

Simulink 모델과 C/C++ 코드에대한매스웍스의정형검증툴소개 The MathWorks, Inc. 1

Language Security. Lecture 40

C Source Code Analysis for Memory Safety

Tracking Pointers with Path and Context Sensitivity for Bug Detection in C Programs. {livshits,

A Gentle Introduction to Program Analysis

Automatic Qualification of Abstract Interpretation-based Static Analysis Tools. Christian Ferdinand, Daniel Kästner AbsInt GmbH 2013

18-642: Code Style for Compilers

One-Slide Summary. Lecture Outline. Language Security

Leveraging Formal Methods for Verifying Models and Embedded Code Prashant Mathapati Application Engineering Group

Using Static Code Analysis to Find Bugs Before They Become Failures

Today Program Analysis for finding bugs, especially security bugs problem specification motivation approaches remaining issues

Static Program Analysis Part 1 the TIP language

Software security, secure programming

Advanced Programming Methods. Introduction in program analysis

Buffer Overflow Defenses

18-642: Code Style for Compilers

Verification & Validation of Open Source

Lecture 6. Abstract Interpretation

Static Analysis in Practice

CSE Computer Security

Static Analysis in Practice

Verification and Validation

Principles of Software Construction: Objects, Design, and Concurrency (Part 2: Designing (Sub )Systems)

Program verification. Generalities about software Verification Model Checking. September 20, 2016

Analysis/Bug-finding/Verification for Security

Static Analysis by A. I. of Embedded Critical Software

Automated Assessment Tools

WHITE PAPER. 10 Reasons to Use Static Analysis for Embedded Software Development

CSE 307: Principles of Programming Languages

Intro to Proving Absence of Errors in C/C++ Code

Pierce Ch. 3, 8, 11, 15. Type Systems

Static Analysis Basics II

Detecting and exploiting integer overflows

Outline. Analyse et Conception Formelle. Lesson 7. Program verification methods. Disclaimer. The basics. Definition 2 (Specification)

Goal. Overflow Checking in Firefox. Sixgill. Sixgill (cont) Verifier Design Questions. Sixgill: Properties 4/8/2010

StackAnalyzer Proving the Absence of Stack Overflows

Oracle Developer Studio Code Analyzer

CSE Computer Security (Fall 2006)

Verifying source code

Undefined Behaviour in C

Dynamic Allocation in C

Automated Assessment Tools

Program Static Analysis. Overview

Stanford University Computer Science Department CS 295 midterm. May 14, (45 points) (30 points) total

CSE 403: Software Engineering, Fall courses.cs.washington.edu/courses/cse403/16au/ Static Analysis. Emina Torlak

Checking Program Properties with ESC/Java

Module: Programming Language Security. Professor Patrick McDaniel Spring CMPSC443 - Introduction to Computer and Network Security

[0569] p 0318 garbage

Verification and Test with Model-Based Design

Towards an industrial use of FLUCTUAT on safety-critical avionics software

Secure Software Development: Theory and Practice

Hacking in C. Pointers. Radboud University, Nijmegen, The Netherlands. Spring 2019

Lessons Learned in Static Analysis Tool Evaluation. Providing World-Class Services for World-Class Competitiveness

CMPSC 497: Static Analysis

Lecture 10. Pointless Tainting? Evaluating the Practicality of Pointer Tainting. Asia Slowinska, Herbert Bos. Advanced Operating Systems

Gaps in Static Analysis Tool Capabilities. Providing World-Class Services for World-Class Competitiveness

Software Security: Vulnerability Analysis

Security Analyses For The Lazy Superhero

Static Analysis: Overview, Syntactic Analysis and Abstract Interpretation TDDC90: Software Security

Testing. ECE/CS 5780/6780: Embedded System Design. Why is testing so hard? Why do testing?

A classic tool: slicing. CSE503: Software Engineering. Slicing, dicing, chopping. Basic ideas. Weiser s approach. Example

Splint Pre-History. Security Flaws. (A Somewhat Self-Indulgent) Splint Retrospective. (Almost) Everyone Hates Specifications.

CS2141 Software Development using C/C++ Debugging

Principles of Program Analysis. Lecture 1 Harry Xu Spring 2013

Checking System Rules Using System-Specific, Programmer- Written Compiler Extensions

Software Security Buffer Overflows more countermeasures. Erik Poll. Digital Security Radboud University Nijmegen

System Administration and Network Security

SoK: Eternal War in Memory

Sendmail crackaddr - Static Analysis strikes back

Learning from Executions

Important From Last Time

Algebraic Program Analysis

Limitations of the stack

Static Vulnerability Analysis

Motivation & examples Threads, shared memory, & synchronization

Structuring an Abstract Interpreter through Value and State Abstractions: EVA, an Evolved Value Analysis for Frama C


Key-value store with eventual consistency without trusting individual nodes

Lightweight Verification of Array Indexing

CS-XXX: Graduate Programming Languages. Lecture 9 Simply Typed Lambda Calculus. Dan Grossman 2012

EECS 481 Software Engineering Exam #1. You have 1 hour and 20 minutes to work on the exam.

Modular and Verified Automatic Program Repairs

C and C++ Secure Coding 4-day course. Syllabus

Generating String Attack Inputs Using Constrained Symbolic Execution. presented by Kinga Dobolyi

Static Program Analysis CS701

Lecture Notes on Memory Layout

Outline. Java Models for variables Types and type checking, type safety Interpretation vs. compilation. Reasoning about code. CSCI 2600 Spring

Program Analysis for Security

More Lambda Calculus and Intro to Type Systems

Combined Static and Dynamic Mutability Analysis 1/31

CCured. One-Slide Summary. Lecture Outline. Type-Safe Retrofitting of C Programs

Outline. Classic races: files in /tmp. Race conditions. TOCTTOU example. TOCTTOU gaps. Vulnerabilities in OS interaction

Wanted: Students to participate in a user study

Dynamic Allocation in C

Announcements. assign0 due tonight. Labs start this week. No late submissions. Very helpful for assign1

Leveraging Formal Methods Based Software Verification to Prove Code Quality & Achieve MISRA compliance

Transcription:

Static Analysis methods and tools An industrial study Pär Emanuelsson Ericsson AB and LiU Prof Ulf Nilsson LiU Outline Why static analysis What is it Underlying technology Some tools (Coverity, KlocWork, PolySpace, ) Some case studies from Ericsson Conclusions 2 1

Method used Tool comparision based on White papers Research reports from research groups behind tools Interviews with Ericsson staff Interviews with technical staff from tool vendors 3 What is SA and what can it be used for Definition: Analysis that does not actually run the code Our interest is: Finding defects (preventing run-time errors) Finding security vulnerabilities Other uses Code optimization (e.g. removing run-time checks in safe languages) Metrics Impact analysis 4 2

Pros and cons of static analysis Pros No test case design needed No test-oracle needed May detect hard-to-find bugs Analyzed program need not be complete Stub writing easier Cons Potentially large number of false positives Does not relate to functional requirements Takes programming competence to understand reports 5 Comparison to other techniques Compared to Testing No test case design needed No test-oracle needed Can find defects that no amount of testing can do Compared to Formal proofs (e.g. model checking) More lightweight SA is much easier to use SA does not need formal requirements 6 3

Software defects and errors Software defect: an anomaly in code that might manifest itself as an error at run-time Types of defects found by static analysis Abrupt termination (e.g. division by zero) Undefined behavior (e.g. array index out of bounds) Performance degradation (e.g. memory leaks, dead code) Security vulnerabilities (e.g. buffer overruns, tainted data) Defects not (easily) found by static analysis Functional incorrectness Infinite loops/non-termination 7 Examples of checkers (C-code) Null pointer dereference Uninitialized data Buffer/array overruns Dead code/unused data Bad return values Return pointers to local data Arithmetic operations with undefined result Arithmetic over-/underflow (Stack use) (Non-termination) 8 4

Security vulnerabilities Unsafe system calls Weak encryption Access problems Unsafe string operations Buffer overruns Race conditions (Time-of-check, time-of-use) Command injections Tainted (untrusted) data 9 Buffer overflow Char dst[256]; Char* s = read_string(); Strcpy(dst, s); 1 5

Imprecision of analyses Defects checked for by static analysis are undecidable Analyses are necessarily imprecise As a consequence Code complained upon may be correct (false positives) Code not complained upon may be defective (false negatives) Classic approaches to static analysis (sound analyses) report all defects checked for (no false negatives), but sometimes produce large amounts of false positives; Most industrial systems try to eliminate false positives but introduce false negatives as a consequence 11 Example fact(int n) { 1) int f = 1; 2) while( n > ) { 3) f = f * n; 4) n = n 1; } 5) return f; } n 1: f = 1 2: n > y 3: f = f * n 4: n = n - 1 5: return f Control Flow Graph (CFG) 12 6

Program states (configurations) A program state is a mapping (function) from program variables to values. For example 1 = { n 1, f } 2 = { n 3, f } 3 = { n 5, f } 13 Semantic equations We associate a set x i of states with node i of the CFG (the set of states that can be observed upon reaching the node) x 1 = {{ n 1, f }, { n 3, f }} % Example x 2 = { x 1 & (n)= (n) & (f)=1 } { x 4 & (n)= (n)-1 & (f)= (f) } x 3 = { x 2 & (n) > } x 4 = { x 3 & (n)= (n) & (f)= (f)* (n) } x 5 = { x 2 & (n) } 14 7

Example run Initially x1 = x2 = x3 = x4 = x5 = x1 = {{n=1,f=},{n=3,f=}} x2 = {{n=1,f=1},{n=3,f=1}} x3 = {{n=1,f=1},{n=3,f=1}} x4 = {{n=1,f=1},{n=3,f=3}} x2 = {{n=,f=1},{n=1,f=1},{n=2,f=3},{n=3,f=1}} x3 = {{n=1,f=1},{n=2,f=3},{n=3,f=1}} x4 = {{n=1,f=1},{n=2,f=6},{n=3,f=3}} x2 = {{n=,f=1},{n=1,f=1},{n=1,f=6},{n=2,f=3},{n=3,f=1}} x3 = {{n=1,f=1},{n=1,f=6},{n=2,f=3},{n=3,f=1}} x4 = {{n=1,f=1},{n=1,f=6},{n=2,f=6},{n=3,f=3}} x2 = {{n=,f=1},{n=,f=6},{n=1,f=1},{n=1,f=6},{n=2,f=3},{n=3,f=1}} x3 = {{n=1,f=1},{n=1,f=6},{n=2,f=3},{n=3,f=1}} x5 = {{n=,f=1},{n=,f=6}} 15 Abstract descriptions of data = the set of all integers + = the set of all positive integers = the set { } - = the set of all negative integers = the empty set (=unreachable) + - 16 8

Abstract operations Abstract multiplication Any integer + - > + + - = < - - + 17 Abstract operations Abstract subtraction Any integer + - > + + + = - + < - - - 18 9

Abstract semantic equations x 1 = { n = +,f = } x 2 = { n = lub*(x 1 (n), (x 4 (n) +)), f = lub*(+, x 4 (f)) } x 3 = { n = +, f = x 2 (f) } x 4 = { n = x 3 (n), f = x 3 (f) x 3 (n)} x 5 = { n =, f = x 2 (f) } (*) lub(a,b) is the smallest description that contain both A and B (kind of set union) 19 Example abstract run Initially x1 = x2 = x3 = x4 = x5 = { n=, f= } x1 = { n=(+),f= } x2 = { n=(+),f=(+) } x3 = { n=(+),f=(+) } x4 = { n=(+),f=(+) } x2 = { n=,f=(+) } x3 = { n=(+),f=(+) } x5 = { n=,f=(+) } 2 1

SA techniques 1. Pattern matching 2. Data flow analysis 3. Value analysis 1. Intervals 2. Aliasing analysis 3. Variable dependencies 4. Abstract interpretation 21 Examples of dataflow analysis Reaching definitions (which definitions reach a point) Liveness (variables that are read before definition) Definite assignment (variable cannot be read) Available expressions (already computed expressions) Constant propagation (replace variable with value) 22 11

Aliasing x = 5 y = 1 = x x [ i ] = 5 x [ j ] = 1 = x[i] 23 Tool comparison Tool Coverity Klocwork Polyspace Flexelint Language C/C++/Java C/C++/Java C/C++/ADA C/C++ Program size MLOC MLOC 6KLOC MLOC Soundness Unsound Unsound Sound Unsound False positives few few many many Analysis def,sec def,sec,met def def incrementality yes no no no 24 12

Coverity Prevent Company founded in 22 Originates from Dawson Engeler s research at Stanford Well documented through research papers Commonly viewed as market leading product Good results from Homeland Security s audit project Coverity Extend allows user-defined checks (Metal language) Good explanations of faults Good support for libraries Incremental 25 Klocwork K7 Company founded by development group at Nortel 21 Similar to Coverity (in checkers provided) Besides finding defects: refactoring, code metrics, architecture analysis Easy to get started and use Good explanations of faults Good support for foreign libraries 26 13

Polyspace Verifier/Desktop French company co-founded by students of Patrick Cousot 1999. Aquired by Mathworks 27. Claims to intercept 1% of the runtime errors checked for in C/C++/ADA programs. Customers in airline industry and the European space program (embedded software). Very thorough especially on arithmatic Can be slow and produces many false positives Documentation hard to read Restricted support for security vulnerabilities and management of dynamic memory 27 28 14

Largest SA project Audit of open source projects Grant by Homeland Security in 26 Coverity, Klocwork and others More than 29 open source software projects analysed: Apache, FreeBSD, GTK, Linux, Mozilla, MySQL, PostgreSQL, and many more. +7 defects fixed during first 18 months (5 up to now) See http://scan.coverity.com/ 29 Other SA tools Grammatech - Code sonar. Similar to Coverity and Klocwork. Co-founders Tom Reps and Tim Teitelbaum. Parasoft C++test performs some static analysis (checks 7 coding standard rules). Purify focuses on memory-leaks, not defects in general. It is a dynamic tool requires test cases. PREfast and PREfix Microsoft proprietory. Astree academic tool by Patric Cousot. Very thorough, works on C without recursion and dynamic memory. Plus many more... 3 15

Ericsson experiences 1 Coverity - Flexelint Mature product that had been in use for several years and well tested FlexeLint 1 2 errors and warnings, could be reduced to 1 with a great deal of filtering work Coverity found 4 defects Had expected Coverity to find more defects and more serious ones Even if many of the defects found were not bugs that could cause a crash they were certainly things that should be corrected 31 Ericsson experiences 2 - Coverity 1,2 MLoC is analyzed in 3 hours Easy to install and use and no modifications to existing development environment needed Part of code was previously analyzed with Flexelint 1464 defects found 55% no real errors but bad style 2% false positives 38% bugs 1% severe considerable number of severe defects were found although code is in PRA quality. 32 16

Ericsson experiences 3 Coverity and Klocwork (43KLoC) Klocwork False positives Found by both tools Coverity False positives Known memory leaks Null-pointer defects 15 2 2 4 Found memory leaks 12 8 1 7 Unutilized variables 2 Freeing Non-Heap Memory 3 Buffer overruns 2 3 1 Total 32 1 3 16 1 33 Ericsson experiences 4 Java. Coverity, Klocwork and CodePro A Java product with known faults was analyzed. Beta version of Coverity was used. Large difference in warnings: Coverity 92, Klocwork 658, CodePro 8. Coverity found many more faults and had far less false positives than Klocwork. Users seem to prefer Klocwork anyway (with filtering: only 19 warnings in the topmost 4 severity levels). CodePro is designed for interactive use. Interactivity of CodePro is appreciated, but possibility to save discovered defects is required. 34 17

Ericsson experiences summary Easy to get going and use - no big changes in processes needed. The tools discover many bugs that would not be found otherwise. Analysis time is acceptable and comparable to build time. Some users had expected the tools to find more defects and defects that were more severe Some users were surprised to find that several bugs were found in applications that had been in use for a long time. Many of the defects found would not cause a crash but after a small modification a serious crash could happen. Tools often discover different defects and often do not find known ones. Handling of third party libraries can make a big difference. Tools should be used throughout development Flexelint can be successful if applied from project start Coverity and Klocwork similar but also very different results in some cases 35 Conclusions Good and useful tools Find bugs with little effort Some tools are mature Can handle very large applications Surprisingly few false positives Easy to use Unclear how many defects that are not discovered 36 18

37 19