david evans these slides: introduction to static analysis

29
David Evans http://www.cs.virginia.edu/evans These slides: http://www.cs.virginia.edu/evans/talks/cs340- s04.ppt Introductio Introductio n to Static n to Static Analysis Analysis

Upload: meagan-murphy

Post on 04-Jan-2016

230 views

Category:

Documents


6 download

TRANSCRIPT

Page 1: David Evans  These slides:  Introduction to Static Analysis

David Evanshttp://www.cs.virginia.edu/evans

These slides: http://www.cs.virginia.edu/evans/talks/cs340-s04.ppt

Introduction Introduction to Static to Static AnalysisAnalysis

Page 2: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 2

How do you decide if a system is dependable?

Page 3: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 3

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?

Page 4: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 4

Sun’s Java License5.  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.  …

Page 5: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 5

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. 

Page 6: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 6

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

Page 7: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 7

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

Page 8: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 8

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?

Page 9: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 9

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

Page 10: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 10

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”

Page 11: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 11

Hopelessness of Analysis

It is impossible to correctly decide if any interesting property is true for an arbitrary program!

Page 12: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 12

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}

Page 13: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 13

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) ?

Page 14: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 14

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;”)));}

Page 15: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 15

Give Up and go to the Beach?

Page 16: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 16

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)

Page 17: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 17

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

Page 18: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 18

Splint

Annotation-assisted lightweight analysis tool for C

Page 19: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 19

A Gross Oversimplification

Effort RequiredLow Unfathomable

Formal Verifiers

Bug

s D

etec

ted

none

all

Compilers

SplintSplint

Page 20: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 20

(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

Page 21: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 21

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

Page 22: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 22

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

AttributesLimitations of

Standard Types

Page 23: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 23

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

Page 24: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 24

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);

Page 25: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 25

Example

1 int 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 nulldummy.c:4:14: Fresh storage ip not released before return

dummy.c:2:43: Fresh storage ip allocated

Page 26: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 26

Security Flaws

Malformed Input16%

Resource Leaks

6%

Format Bugs6%

Buffer Overflows

19%

Access16%

Pathnames10%

Symbolic Links11%

Other16%

Reported flaws in Common Vulnerabilities and Exposures Database, Jan-Sep 2001.[Evans & Larochelle, IEEE Software, Jan 2002.]

190 VulnerabilitiesOnly 4 having to do with crypto108 of them could have been

detected with simple static analyses!

Page 27: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 27

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

Page 28: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 28

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

Page 29: David Evans  These slides:  Introduction to Static Analysis

1 March 2004 Static Analysis 29

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: www.splint.org

http://www.cs.virginia.edu/evans/talks/cs340-s04.ppt