Systems for Safety and Dependability David Evans evans/ University of Virginia Department of...

Systems for Safety and Dependability

David Evans

http://www.cs.virginia.edu/~evans/

University of VirginiaDepartment of Computer Science

214 December 1999 Safety and Dependability

What Are You Afraid Of?• Malicious attacks

– Russian New Year, Melissa, Chernobyl, Java thread attack, etc.

• Buggy programs– Can cause harm accidentally– Can be exploited by attackers

• User mistakes/bad interfaces– tar –cf *


MenuNaccio: Policy-Directed Code Safety

How do you prevent bad programs from doing bad things?

naccio.cs.virginia.edu

LCLint: Annotation-Assisted Static CheckingHow do you help good people not write bad programs?

lclint.cs.virginia.edu


Naccio Motivation

• Weaknesses in existing code safety systems:– Limited range of policies– Policy definition is ad hoc and platform

dependent• Enforcement is tied to a particular architecture

• Can we solve them without sacrificing efficiency or convenience?

Yes!


• General method for defining policies– Abstract resources– Platform independent

• System architecture for enforcing policies– Prototypes for

JavaVM classes, Win32 executables

Program

Safe Program

SafetyPolicy

Naccio Overview


ProblemUser’s View

Files

Resources

PolicyPolicy

System View

WriteFile (fHandle, …)

Disk

ProgramProgram

System LibrarySystem Library

OS KernelOS Kernel

tar cf *

Pla

tform

Inte

rfa

ce


Safety Policy Definition

• Resource descriptions: abstract operational descriptions of resources (files, network, …)

• Platform interface: mapping between system events (Java API calls) and abstract resources

• Resource use policy: constraints on manipulating those resources

8Safety and Dependability14 December 1999

global resource RFileSystem

openRead (file: RFile)

Called before file is opened for reading

openWrite (file: RFile)

Called before existing file is opened for writing write (file: RFile, nbytes: int)

Called before nbytes are written to file … // other operations for observing properties of files, deleting, etc.

resource RFile

RFile (pathname: String)

Constructs object corresponding to pathname

Resource Description


Java PFI Excerptwrapper java.io.FileOutputStream requires RFileMap; state RFile rfile;

wrapper void write (byte b[]) if (rfile != null) RFileSystem.write (rfile, b.length); %%% // original method call

… // wrappers needed for constructors, other write

// methods, close and getFD


Resource Use Policypolicy LimitWrite LimitBytesWritten (1000000), NoOverwrite

property LimitBytesWritten (n: int) requires TrackBytesWritten; check RFileSystem.write (file: RFile, nbytes: int) if (bytes_written > n) violation (“Writing more than …”);

stateblock TrackBytesWritten addfield RFileSystem.bytes_written: int = 0; precode RFileSystem.write (file: RFile, nbytes: int) bytes_written += nbytes;


Enforceable Policies

• Can enforce any policy that can be defined

• What can be defined depends on resource operations

• Resource operations depend on platform interface– Any manipulation done through API calls– Cannot constrain CPU usage

• Solutions possible: insert calls

• Portable policies use standard resources


System architecture Defining policies• Enforcing policies

• Architecture• Results – JavaVM, Win32

OutlineProgram

Safe Program

SafetyPolicy


Policy description fileApplicationApplication transformertransformer

Program

Version of program that:• Uses policy-enforcing system library• Satisfies low-level code safety

Naccio Architecture

Platforms in development: JavaVM – program is collection of Java classesWin32 – program is Win32 executable and DLLs

Per application

Policy Policy compilercompiler

Safety policy definition

Policy-enforcing system library

Per policy


Policy description file

Resource descriptions

System libraryJava library classes

Platform interfaceDescribes Java API

Platform Platform independent independent

analysesanalyses

Platform dependent Platform dependent analyses and code analyses and code

generationgeneration

Resource use policy

Policy Compiler

Policy-enforcing system library• Implementations of resource operations

– Perform checking described by resource use policy• Modifies Java byte codes

– Call abstract resource operations as directed by platform interface

package naccio.p253.resource;

class RFileSystem { static int bytes_written = 0; static void write (RFile file, int nbytes) { bytes_written += nbytes; if (bytes_written > 1000000) Check.violation (“LimitWrite”, “Attempt to write …); } …

Policy compilerPolicy compiler

Resource implementations

Resource use policy

stateblock TrackBytesWritten

addfield RFileSystem.bytes_written: int;

precode RFileSystem.write (file: RFile, nbytes: int)

bytes_written += nbytes;

property LimitBytesWritten (n: int)

check RFileSystem.write (file: RFile, nbytes: int) if (bytes_written > n) violation (“Attempt …);

Implementing Resources

RFileSystemRFile

Resource descriptions

policy LimitWrite NoOverwrite, LimitBytesWritten (1000000)


class FileOutputStream { … public void write (byte b[]) { writeBytes (b, 0, b.length); }}

class FileOutputStream { naccio.p253.resource.RFile rfile; … // orig_write – same implementation as old write method void write (byte b[]) { if (rfile != null) naccio.p253.resource.RFileSystem.write (rfile, b.length); orig_write (b);}

Policy compilerPolicy compiler

Wrapped library classes

System library classes Platform interface

wrapper java.io.FileOutputStreamstate RFile rfile; wrapper void write (byte b[]) if (rfile != null) RFileSystem.write (rfile, b.length); %%% // original method call

Rewriting Classes


Optimizations• Only implement resource operation if it:

– May produce a violation– Modifies state used elsewhere

• Only wrap library method if it:– Calls implemented resource operation – Modifies state used meaningfully– Alters behavior

• Simple dataflow dependency analysis• Not done yet: inline methods and state to

remove resource overhead


Program Program TransformerTransformer

Policy description file

ProgramCollection of Java classes

Version of program that:1. Uses policy-enforcing library

• Replace class names in constant pool• Wrappers for dynamic class loading methods

2. Satisfies low-level code safety• Use Java byte code verifier• Wrappers on reflection methods


What’s different for Win32?• Program is Win32 executable and DLLs• Platform interface describes Win32 API• Policy compiler

– Generate DLLs instead of Java classes

• Application transformer – Replace DLL names in import table– Low-level code safety is platform-specific

• SFI for jumps, PFI wrappers to protect memory• Scan for kernel traps

• Policies can be reused


Results - JavaVM• Preparation time

minimal• Overhead depends on

policy and application• Substantially faster

than JDK – Policy decisions made

at transform time– Can optimize out

unnecessary checking

• Details in [Evans99]

Naccio

tar from www.ice.com

1

1.5

2

2.5

LimitW

rite

TarC

ustom

JavaApplet

JavaApplet

using JDK

Nor

mal

ized

Run

Tim

e


Results – Win32• Can enforce policies on

Microsoft Word• Caveats:

– Subset of Win32 API– Doesn’t deal with low-

level code safety yet(need to implement SFI)

• Details in [Twyman99]pkzip

1

1.05

1.1

1.15

Null

LimitP

ath

ReadO

nlyDir

LimitW

rite

Nor

mal

ized

Run

Tim

e


Related Work

• Software fault isolation [Wahbe et al, 93]• Similar enforcement mechanisms

– Execution monitoring [Schneider]– Ariel Project [Pandey, Hashii]

• Alternative: verify properties– Proof-carrying code [Necula, Lee]– Typed Assembly Language [Morrisett]


Naccio Summary• Method for defining large class of policies

– Using abstract resources• General architecture for code safety • Encouraging results so far

– Win32: need to implement low-level safety– JavaVM: needs to be attacked

For more information:

IEEE Security & Privacy 99 (Oakland)

http://naccio.cs.virginia.edu


Annotation-Assisted Static Checking

Effort RequiredLow Unfathomable

Formal Verifiers

Bug

s D

etec

ted

none

all

Compilers

LCLintLCLint


Approach• Programmers add annotations (formal

specifications)– Simple and precise– Describe programmers intent:

• Types, memory management, data hiding, aliasing, modification, nullness, etc.

• LCLint detects inconsistencies between annotations and code– Simple (fast!) dataflow analyses


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


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

LCLint 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


Checking Examples

• Encapsulation – abstract types (rep exposure), global variables, documented modifications

• Memory management – leaks, dead references

• De-referencing null pointers, dangerous aliasing, undefined behavior


Unsoundness & Incompleteness are Good!

• Okay to miss errors– Report as many as possible

• Okay to issue false warnings– But don’t annoy the user to too many– Make it easy to configure checking and

override warnings

• Design tradeoff – do more ambitious checking the best you can


LCLint Status• Public distribution since 1993• Effective checking >100K line programs

(checks about 1K lines per second) – Detects lots of real bugs in real programs

(including itself, of course)

• More information: lclint.cs.virginia.edu

PLDI ’96, FSE’94


Where do we go from here?• Motivating Example:

Take an e-commerce site and prove that credit card information is never stored or transmitted unencrypted

• Meta-annotations [David LaRochelle]– Allow users to define new annotations and associated

checking

• Generalize framework– Support static checking for multiple source languages

in a principled way– Integrate static and run-time checking to enable

completeness guarantees


Summary

• A little redundancy goes a long way• Naccio:

– Describe high-level behavioral constraints in an abstract way

– Check them automatically at run-time

• LCLint:– Describe programmer intent in a precise way– Check them statically at compile-time


Credits

• NaccioWin32 Implementation: Andrew Twyman

• LCLintLCL: Yang Meng Tan, John Guttag,

Jim Horning

• FundingDARPA, NSF, ONR

Systems for Safety and Dependability David Evans evans/ University of Virginia Department of...

Documents

Transcript of Systems for Safety and Dependability David Evans evans/ University of Virginia Department of...