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

Similar documents
CS 161 Computer Security

Modular and Verified Automatic Program Repairs

Scalable Program Analysis Using Boolean Satisfiability: The Saturn Project

Checking Program Properties with ESC/Java

Lecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning

Language Security. Lecture 40

Software Security: Vulnerability Analysis

BOOGIE. Presentation by Itsik Hefez A MODULAR REUSABLE VERIFIER FOR OBJECT-ORIENTED PROGRAMS MICROSOFT RESEARCH

One-Slide Summary. Lecture Outline. Language Security

Lecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning

Bounded Model Checking Of C Programs: CBMC Tool Overview

Bug Finding with Under-approximating Static Analyses. Daniel Kroening, Matt Lewis, Georg Weissenbacher

Runtime Checking and Test Case Generation for Python

(Early) Memory Corruption Attacks

Lecture 18 Restoring Invariants

Secure Software Development: Theory and Practice

Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?

Automatic Software Verification

CS107 Handout 08 Spring 2007 April 9, 2007 The Ins and Outs of C Arrays

Lecture Notes on Memory Layout

CSSV: Towards a Realistic Tool for Statically Detecting All Buffer Overflows in C

An Annotated Language

Memory Safety (cont d) Software Security

STUDENT LESSON A12 Iterations

Program Verification. Aarti Gupta

Static Analysis in Practice

Static Analysis in Practice

Static program checking and verification

Lecture 9 Assertions and Error Handling CS240

Formal Verification Techniques for GPU Kernels Lecture 1

Static Analysis and Bugfinding

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

Software Engineering Testing and Debugging Testing

Software Engineering

Testing, Debugging, and Verification

Lecture 10 Design by Contract

Statically Detecting Likely Buffer Overflow Vulnerabilities

Lectures 20, 21: Axiomatic Semantics

Code verification. CSE 331 University of Washington. Michael Ernst

Hoare Logic. COMP2600 Formal Methods for Software Engineering. Rajeev Goré

Dynamic Allocation in C

Semantic Analysis. CSE 307 Principles of Programming Languages Stony Brook University

Global Optimization. Lecture Outline. Global flow analysis. Global constant propagation. Liveness analysis. Local Optimization. Global Optimization

Program Verification using Templates over Predicate Abstraction. Saurabh Srivastava and Sumit Gulwani

COS 320. Compiling Techniques

Lecture 4 September Required reading materials for this class

Computer Security Course. Midterm Review

CIS 890: Safety Critical Systems

Software Model Checking. Xiangyu Zhang

Lecture Notes on Linear Search

Introduction to CBMC. Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Arie Gurfinkel December 5, 2011

Type Checking. Outline. General properties of type systems. Types in programming languages. Notation for type rules.

VS 3 : SMT Solvers for Program Verification

Outline. General properties of type systems. Types in programming languages. Notation for type rules. Common type rules. Logical rules of inference

Control Flow Hijacking Attacks. Prof. Dr. Michael Backes

Spark verification features

Softwaretechnik. Program verification. Albert-Ludwigs-Universität Freiburg. June 28, Softwaretechnik June 28, / 24

Softwaretechnik. Program verification. Software Engineering Albert-Ludwigs-University Freiburg. June 30, 2011

Testing. Prof. Clarkson Fall Today s music: Wrecking Ball by Miley Cyrus

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

A short manual for the tool Accumulator

Advanced Programming Methods. Introduction in program analysis

Security Analyses For The Lazy Superhero

Induction and Semantics in Dafny

Code Contracts. Pavel Parízek. CHARLES UNIVERSITY IN PRAGUE faculty of mathematics and physics

Outline. Introduction. 2 Proof of Correctness. 3 Final Notes. Precondition P 1 : Inputs include

Formal Methods. CITS5501 Software Testing and Quality Assurance

ESC/Java2 vs. JMLForge. Juan Pablo Galeotti, Alessandra Gorla, Andreas Rau Saarland University, Germany

Handling Loops in Bounded Model Checking of C Programs via k-induction

Software Security: Buffer Overflow Attacks

Memory Corruption 101 From Primitives to Exploit

Separation Logic 2: project: Annotation Assistant for Partially Specified Programs plus some high-level observations. Hengle Jiang & John-Paul Ore

Satisfiability Modulo Theories: ABsolver

Programming Languages and Compilers Qualifying Examination. Answer 4 of 6 questions.1

CSE 565 Computer Security Fall 2018

CS61C Machine Structures. Lecture 5 C Structs & Memory Mangement. 1/27/2006 John Wawrzynek. www-inst.eecs.berkeley.edu/~cs61c/

PROGRAM ANALYSIS & SYNTHESIS

Operational Semantics. One-Slide Summary. Lecture Outline

Lecture Notes on Contracts

Differential program verification

Lecture 8 Data Structures

Analysis of Software Artifacts

Hybrid Verification in SPARK 2014: Combining Formal Methods with Testing

CITS5501 Software Testing and Quality Assurance Formal methods

Introduction to Programming in C Department of Computer Science and Engineering. Lecture No. #44. Multidimensional Array and pointers

"Secure" Coding Practices Nicholas Weaver

Lecture Notes on Types in C

CSolve: Verifying C With Liquid Types

Verifying the Safety of Security-Critical Applications

15-122: Principles of Imperative Computation (Section G)

Principles of Program Analysis. Lecture 1 Harry Xu Spring 2013

Static Analysis of C++ Projects with CodeSonar

Software Security II: Memory Errors - Attacks & Defenses

Putting Static Analysis to Work for Verification

Combining Static and Dynamic Contract Checking for Curry

Violations of the contract are exceptions, and are usually handled by special language constructs. Design by contract

Programming Languages Third Edition

Unit Testing as Hypothesis Testing

Program Correctness and Efficiency. Chapter 2

Today. Instance Method Dispatch. Instance Method Dispatch. Instance Method Dispatch 11/29/11. today. last time

Transcription:

Goal Overflow Checking in Firefox Brian Hackett Can we clean a code base of buffer overflows? Keep it clean? Must prove buffer accesses are in bounds Verification: prove a code base has a property Sixgill Verifier for buffer accesses in large code bases Note: not quite full verification Mostly automatic Can be supplemented with ihannotations Linux: 89% of accesses checked automatically Firefox: ditto for 82% Firefox javascript engine: 92% checked using annotations Sixgill (cont) Early stages of deployment on Firefox Open source More (not much more) at sixgill.org Rest of this lecture Design questions addressed in building Sixgill Sixgill design and architecture Demo! Verifier Design Questions What properties can be checked? What level of precision? What degree of scalability? How areannotationsannotations used? Can the tool make assumptions? Design for clear reports Great majority will be false positives Sixgill: Properties Check properties expressible as assertions Buffer overflows Hand written assert() failures NULL dereferences NULL dereferences Integer overflows... Most properties need customization assert(i < ubound(buf)); 1

Sixgill: Precision Understand any quantifier free assertion No loops, no recursion Quantifiers are very hard to reason about Understand dloop free pieces of code exactly Use abstractions at function/loop boundaries Some technical limitations to these More later Sixgill: Scalability Analyze systems of any size Should parallelize, avoid memory constraints Linux, Firefox: 2 7 MLOC Verifiers with comparable power: 5 10 KLOC Sixgill: Annotations Infer information without user input Be robust, deterministic against code changes Use annotations when inference breaks down Target: one annotation per 1 3 KLOC Must be clear where to add annotations Sixgill: Assumptions Make some basic assumptions Compiler, hardware behave correctly Program is memory safe, type safe Theseare madeby almost all verifiers Make some additional assumptions No integer overflow, heap stability properties,... More later Eventual target is full verification Why is code correct? Buffer accesses are correct for a reason preconditions, postconditions, loop invariants,... Follow from each other and the code semantics Analysis goal: find these reasons Reasons follow patterns Use inference for the common patterns Use annotations for the rest Example void foo(int len) Postcondition: len <= ubound(retval) char *buf = malloc(len); bar(buf, len); Precondition: len <= ubound(buf) Assert: i < ubound(buf) 2

Another Example void foo(int len) Postcondition: len <= ubound(retval) char *buf = malloc(len); bar(buf, len); Precondition: len <= ubound(buf) Loop Invariant: buf + plen == p Assert: 0 < ubound(p) Program Facts A fact is a condition which holds in the program Precondition(foo, b) Postcondition(foo, b) LoopInvariant(foo, loop, b) TypeInvariant(type, b) GlobInvariant(b) Assert(foo, point, b) b values are quantifier free boolean formulas Following Facts A goal fact f can follow from zero or more dependent facts f 0, f 1, f 2,... If the dependents hold, the goal holds Show this using a memory model Exact model of a loop free piece of code Note: not quite exact Inject assumes for f 0, f 1, f 2,... Inject asserts for f Memory Example loop: if (plen++ < len) Memory Example (cont) Memory Example (cont) Loop Invariant: buf + plen == p assert(buf + plen == p) loop: assume(buf + plen == p) if (plen++ < len) assert(buf + plen == p) loop: assume(buf + plen == p) assume(len <= ub(buf)) if (plen++ < len) Loop Invariant: buf + plen == p assert(0 < ub(p)) Assert: 0 < ubound(p) 3

Memory Model details Memory model built on an SMT solver Solves boolean formulas over linear equations We use Yices (from SRI International) Solver can t handle nonlinear arithmetic ti Memory model introduces unsoundness Nonlinear Arithmetic Major gap in analysis precision Mostly fixable using approximations... (a & b) (a & b <= a) && (a & b <= b)... but not always int *buf = calloc(width, height * sizeof(int)); int *pos = buf; for (int row = 0; row < height; row++) for (int col = 0; col < width; col++) *pos++ = 0; Memory Model unsoundness Does not consider integer overflow int *buf = malloc(len * sizeof(int)); Assumes null terminators t not overwritten char buf[100]; strcpy(buf, str); clobber(buf); int len = strlen(buf); These can be handled with separate analyses Analysis Start with a goal fact f A buffer access or an intermediate fact Generate candidate sets F 0, F 1, F 2,... Test if each candidate F is sufficient f follows from the dependent facts in F Pick a sufficient set and recurse on each dependent Candidates Target: Assert: i < ubound(buf) See compare i < len Guess: Also guess: Loop Invariant: ubound(buf) <= len Candidates (cont) Target: Assert: 0 < ubound(p) See increments of plen and p Initial values of plen and p are 0 and buf Guess: Loop Invariant: buf + plen == p See compare plen < len Add to guess: 4

Sufficient Choices void Precondition: foo(char a <= *buf, ubound(buf) int a) int b = bar(buf); Postcondition: retval < ubound(buf) if (b < a) buf[b] = 0; Assert: b < ubound(buf) No way to tell which is better Pick one arbitrarily What if we pick wrong? Annotations Annotations are facts which have been specified as holding by a user Assume all annotations when testing candidates Untrusted annotations: separatelytryto try to prove the annotation holds Same procedure as for buffer accesses Buffer Write Categories Verified proved automatically Annotatable provable using untrusted annotations Inexpressible Unprovable, but dependent facts can be annotated Limitations of tool Unverifiable Dependent facts cannot be annotated Includes all bugs Results Linux 2.6.17.1 55676 buffer writes total All but 6088 verified (89%) Firefox 191 1.9.1 16511 buffer writes total All but 2936 verified (82%) More trivially verifiable writes in Linux int buf[10]; buf[9] = 3; Results (cont) Detailed results for Firefox javascript engine 2801 buffer writes (17% of all of Firefox) All but 566 verified (80%) 344 annotatable Requiring 64 annotations 98 inexpressible 124 unverifiable 9 look buggy (not confirmed yet) Demo Tool UI can be used to: Browse and inspect reports Add annotations Reanalyze accesses using added annotations Reanalyze accesses using added annotations Reports are chains of dependents from a buffer access Tool gave up on trying to prove the dependents Firefox reports online at sixgill.org 5