David Evans These slides: Introduction to Static Analysis.

Slides:



Advertisements
Similar presentations
Static Analysis for Security
Advertisements

Advanced programming tools at Microsoft
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Challenges in increasing tool support for programming K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 23 Sep 2004 ICTAC Guiyang, Guizhou, PRC joint.
David Evans CS201j: Engineering Software? University of Virginia Computer Science Lecture 2: Java Semantics, Validation.
Testing and Quality Assurance
SPLINT STATIC CHECKING TOOL Sripriya Subramanian 10/29/2002.
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
This Time Pointers (declaration and operations) Passing Pointers to Functions Const Pointers Bubble Sort Using Pass-by-Reference Pointer Arithmetic Arrays.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
Cs2220: Engineering Software Class 5: Validation Fall 2010 University of Virginia David Evans.
Joel Winstead CS201j: Engineering Software University of Virginia Computer Science Lecture 16: Pointers and Memory Management.
1 Static Testing: defect prevention SIM objectives Able to list various type of structured group examinations (manual checking) Able to statically.
1 Homework Turn in HW2 at start of next class. Starting Chapter 2 K&R. Read ahead. HW3 is on line. –Due: class 9, but a lot to do! –You may want to get.
1 Lecture 7 Halting Problem –Fundamental program behavior problem –A specific unsolvable problem –Diagonalization technique revisited Proof more complex.
1 Lecture 7 Halting Problem –Fundamental program behavior problem –A specific unsolvable problem –Diagonalization technique revisited Proof more complex.
1CMSC 345, Version 4/04 Verification and Validation Reference: Software Engineering, Ian Sommerville, 6th edition, Chapter 19.
Statically Detecting Likely Buffer Overflow Vulnerabilities David Larochelle David Evans University of Virginia Department of Computer Science Supported.
CS527: (Advanced) Topics in Software Engineering Overview of Software Quality Assurance Tao Xie ©D. Marinov, T. Xie.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
11 Values and References Chapter Objectives You will be able to: Describe and compare value types and reference types. Write programs that use variables.
Cs205: engineering software university of virginia fall 2006 Validation David Evans
CS 501: Software Engineering Fall 1999 Lecture 16 Verification and Validation.
INTRODUCTION TO COMPUTING CHAPTER NO. 06. Compilers and Language Translation Introduction The Compilation Process Phase 1 – Lexical Analysis Phase 2 –
DIRC Workshop on Software Quality and the Legal System 13 February 2004, Gray's Inn, London LEGAL ASPECTS OF SOFTWARE PROCUREMENT Jos Dumortier University.
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
Cs3102: Theory of Computation Class 18: Proving Undecidability Spring 2010 University of Virginia David Evans.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
EECE 310: Software Engineering Testing / Validation.
Introduction Algorithms and Conventions The design and analysis of algorithms is the core subject matter of Computer Science. Given a problem, we want.
Chapter 0.2 – Pointers and Memory. Type Specifiers  const  may be initialised but not used in any subsequent assignment  common and useful  volatile.
Computer Science and Software Engineering University of Wisconsin - Platteville 2. Pointer Yan Shi CS/SE2630 Lecture Notes.
Extended Static Checking for Java  ESC/Java finds common errors in Java programs: null dereferences, array index bounds errors, type cast errors, race.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Our Global Community. Activity 1: Our Global Community LIMITED LICENSE TO MODIFY. These PowerPoint® slides may be modified only by teachers currently.
Cs2220: Engineering Software Class 6: Defensive Programming Fall 2010 University of Virginia David Evans.
David Evans CS551/651: Dependable Computing University of Virginia Computer Science Static Analysis.
Looping and Counting Lecture 3 Hartmut Kaiser
Overflow Examples 01/13/2012. ACKNOWLEDGEMENTS These slides where compiled from the Malware and Software Vulnerabilities class taught by Dr Cliff Zou.
1 Introduction to Software Testing. Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Chapter 1 2.
David Evans The Bugs and the Bees Research in Swarm Programming and Security University of Virginia.
David Evans The Bugs and the Bees Research in Programming Languages and Security University of.
Systems for Safety and Dependability David Evans University of Virginia Department of Computer Science.
1 Homework HW5 due today Review a lot of things about allocation of storage that may not have been clear when we covered them in our initial pass Introduction.
Buffer Overflow Proofing of Code Binaries By Ramya Reguramalingam Graduate Student, Computer Science Advisor: Dr. Gopal Gupta.
Chapter 3 Part II Describing Syntax and Semantics.
Life in Other Countries. Activity 2: Life in Other Countries LIMITED LICENSE TO MODIFY. These PowerPoint® slides may be modified only by teachers currently.
1 Splint: A Static Memory Leakage tool Presented By: Krishna Balasubramanian.
(A Somewhat Self-Indulgent) Splint Retrospective David Evans University of Virginia 25 October 2010.
An Undergraduate Course on Software Bug Detection Tools and Techniques Eric Larson Seattle University March 3, 2006.
POINTERS. // Chapter 3 - Program 1 - POINTERS.CPP #include int main() { int *pt_int; float *pt_float; int pig = 7, dog = 27; float x = , y = 32.14;
CSE 311 Foundations of Computing I Lecture 28 Computability: Other Undecidable Problems Autumn 2011 CSE 3111.
Introduction to Software Analysis CS Why Take This Course? Learn methods to improve software quality – reliability, security, performance, etc.
Announcements You will receive your scores back for Assignment 2 this week. You will have an opportunity to correct your code and resubmit it for partial.
David Evans The Bugs and the Bees Research in Programming Languages and Security University of.
Chapter 10 Chapter 10 Implementing Subprograms. Implementing Subprograms  The subprogram call and return operations are together called subprogram linkage.
CS 5150 Software Engineering Lecture 21 Reliability 2.
Copyright © 2016 Curt Hill Static Code Analysis What it is and does.
University of Virginia Computer Science Extensible Lightweight Static Checking David Evans On the I/O.
Language-Based Security: Overview of Types Deepak Garg Foundations of Security and Privacy October 27, 2009.
CMSC 345 Defensive Programming Practices from Software Engineering 6th Edition by Ian Sommerville.
Verification and Validation
Verification and Validation
State your reasons or how to keep proofs while optimizing code
Testing Recap Testing can find problems, but cannot prove your program works Since exhaustive testing is impossible, select test cases with maximum likelihood.
Improving software quality using Visual Studio 11 C++ Code Analysis
Improving Security Using Extensible Lightweight Static Analysis
CSE 311: Foundations of Computing
Annotation-Assisted Lightweight Static Checking
Lecture 2: Java Semantics, Validation CS201j: Engineering Software?
Presentation transcript:

David Evans These slides: Introduction to Static Analysis

1 March 2004Static Analysis2 How do you decide if a system is dependable?

1 March 2004Static Analysis3 Validation: Dictionary Definition val·i·date 1.To declare or make legally valid. 2.To mark with an indication of official sanction. 3.To establish the soundness of; corroborate. Can we do any of these with software?

1 March 2004Static Analysis4 Sun’s Java License 5. LIMITATION OF LIABILITY. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. …

1 March 2004Static Analysis5 Java’s License 2. RESTRICTIONS. … Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun disclaims any express or implied warranty of fitness for such uses.

1 March 2004Static Analysis6 Software Validation Process designed to increase our confidence that a program works as intended For complex programs, cannot often make guarantees This is why typical software licenses don’t make any claims about their program working

1 March 2004Static Analysis7 Increasing Confidence Testing –Run the program on set of inputs and check the results Verification –Argue formally or informally that the program always works as intended Analysis –Poor programmer’s verification: examine the source code to increase confidence that it works as intended

1 March 2004Static Analysis8 Testing If all the test cases produce the correct results, you know that a particular execution of the program on each of the test cases produced the correct result Concluding that this means the program is correct is like concluding there are no fish in the river because you didn’t catch one! What makes a good test case?

1 March 2004Static Analysis9 Analysis Make claims about all possible paths by examining the program code directly, not executing it Use formal semantics of programming language to know what things mean Use formal specifications of procedures to know that they do

1 March 2004Static Analysis10 Example Software Properties Does what the customer wants Does what the programmer intends Doesn’t do anything dangerous Always eventually halts Never dereferences null Always opens a file before writing to it Never prints “3”

1 March 2004Static Analysis11 Hopelessness of Analysis It is impossible to correctly decide if any interesting property is true for an arbitrary program!

1 March 2004Static Analysis12 Halting Problem Can we write a program that takes any program as input and returns true if that program always halts, and returns false if it sometimes doesn’t halt. bool alwaysHalts (Program p) { … // returns true iff p will halt }

1 March 2004Static Analysis13 Informal Proof Suppose we could write alwaysHalts. Proof by contradiction: bool contradictHalts () { if (alwaysHalts (contradictHalts)) { while (true) ; // loop forever } else { return false; } What is alwaysHalts (contradictHalts) ?

1 March 2004Static Analysis14 Hopelessness of Analysis But this means, we can’t write a program that decides any other interesting property either: bool dereferencesNull (Program p) // EFFECTS: Returns true if p ever dereferences null, // false otherwise. bool alwaysHalts (Program p) { return (derefencesNull (new Program (“p (); *NULL;”))); }

1 March 2004Static Analysis15 Give Up and go to the Beach?

1 March 2004Static Analysis16 Compromises Only work for some programs Accept unsoundness and incompleteness False positives: sometimes an analysis tool will report warnings for a program, when the program is actually okay (incompleteness – can’t prove a property that is true) False negatives: sometimes an analysis tool will report no warnings for a program, even when the program violates properties it checks (unsoundness – proves a property that is not true)

1 March 2004Static Analysis17 Properties to Analyze Generic Properties –Dangerous Code C: memory leaks, dereferencing null, type mismatches, undefined behavior, etc. Concurrency: race conditions, deadlocks –Don’t need a specification (but it may help across procedure boundaries) Application-Specific Properties –Need some way of describing the properties we want

1 March 2004Static Analysis18 Splint Annotation-assisted lightweight analysis tool for C

1 March 2004Static Analysis19 A Gross Oversimplification Effort Required Low Unfathomable Formal Verifiers Bugs Detected none all Compilers Splint

1 March 2004Static Analysis20 (Almost) Everyone Likes Types Easy to Understand Easy to Use Quickly Detect Many Programming Errors Useful Documentation …even though they are lots of work! –1/4 of text of typical C program is for types

1 March 2004Static Analysis21 Limitations of Standard Types Type of reference never changes State changes along program paths Language defines checking rules System or programmer defines checking rules One type per reference Many attributes per reference

1 March 2004Static Analysis22 Type of reference never changes State changes along program paths Language defines checking rules System or programmer defines checking rules One type per reference Many attributes per reference Attributes Limitations of Standard Types

1 March 2004Static Analysis23 Approach Programmers add annotations (formal specifications) –Simple and precise –Describe programmers intent: Types, memory management, data hiding, aliasing, modification, null-ity, buffer sizes, security, etc. Splint detects inconsistencies between annotations and code –Simple (fast!) dataflow analyses

1 March 2004Static Analysis24 Sample Annotation: only Reference (return value) owns storage No other persistent (non-local) references to it Implies obligation to transfer ownership Transfer ownership by: –Assigning it to an external only reference –Return it as an only result –Pass it as an only parameter: e.g., extern void free (only void *); extern only char *gptr; extern only out null void *malloc (int);

1 March 2004Static Analysis25 Example 1int dummy (void) { 2 int *ip= (int *) malloc (sizeof (int)); 3 *ip = 3; 4 return *ip; 5 } extern only null void *malloc (int); in library Splint output: dummy.c:3:4: Dereference of possibly null pointer ip: *ip dummy.c:2:13: Storage ip may become null dummy.c:4:14: Fresh storage ip not released before return dummy.c:2:43: Fresh storage ip allocated

1 March 2004Static Analysis26 Security Flaws Reported flaws in Common Vulnerabilities and Exposures Database, Jan-Sep [Evans & Larochelle, IEEE Software, Jan 2002.] 190 Vulnerabilities Only 4 having to do with crypto 108 of them could have been detected with simple static analyses!

1 March 2004Static Analysis27 Example: Buffer Overflows Most commonly exploited security vulnerability –1988 Internet Worm –Still the most common attack Code Red exploited buffer overflow in IIS >50% of CERT advisories, 23% of CVE entries in 2001 Attributes describe sizes of allocated buffers Heuristics for analyzing loops Found several known and unknown buffer overflow vulnerabilities in wu-ftpd

1 March 2004Static Analysis28 Other Static Analysis Tools ESC/Java (DEC/Compaq/HP SRC) –Annotations describe invariants –Detects possible RunTime execptions Coverity SWAT (Coverity, Inc., was Stanford research project) –Statistical analysis of large code bases to find anomalies –Has found thousands of flaws in Linux PREfix (Microsoft) –No user annotations, but models library functions –Used on Windows, Office, etc. code base Heuristics to prioritize thousands of warnings

1 March 2004Static Analysis29 Summary Redundancy is good for dependability Static analysis tools can check redundant information is consistent Any useful property is impossible to decide soundly and completely (but, lots of useful checking can still be done) For more on Splint: