View
224
Download
0
Category
Preview:
Citation preview
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 *
314 December 1999 Safety and Dependability
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
414 December 1999 Safety and Dependability
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!
514 December 1999 Safety and Dependability
• 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
614 December 1999 Safety and Dependability
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
714 December 1999 Safety and Dependability
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
914 December 1999 Safety and Dependability
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
1014 December 1999 Safety and Dependability
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;
1114 December 1999 Safety and Dependability
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
1214 December 1999 Safety and Dependability
System architecture Defining policies• Enforcing policies
• Architecture• Results – JavaVM, Win32
OutlineProgram
Safe Program
SafetyPolicy
1314 December 1999 Safety and Dependability
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
1414 December 1999 Safety and Dependability
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)
1614 December 1999 Safety and Dependability
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
1714 December 1999 Safety and Dependability
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
1814 December 1999 Safety and Dependability
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
1914 December 1999 Safety and Dependability
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
2014 December 1999 Safety and Dependability
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
2114 December 1999 Safety and Dependability
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
2214 December 1999 Safety and Dependability
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]
2314 December 1999 Safety and Dependability
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
2414 December 1999 Safety and Dependability
Annotation-Assisted Static Checking
Effort RequiredLow Unfathomable
Formal Verifiers
Bug
s D
etec
ted
none
all
Compilers
LCLintLCLint
2514 December 1999 Safety and Dependability
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
2614 December 1999 Safety and Dependability
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);
2714 December 1999 Safety and Dependability
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
2814 December 1999 Safety and Dependability
Checking Examples
• Encapsulation – abstract types (rep exposure), global variables, documented modifications
• Memory management – leaks, dead references
• De-referencing null pointers, dangerous aliasing, undefined behavior
2914 December 1999 Safety and Dependability
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
3014 December 1999 Safety and Dependability
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
3114 December 1999 Safety and Dependability
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
3214 December 1999 Safety and Dependability
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
3314 December 1999 Safety and Dependability
Credits
• NaccioWin32 Implementation: Andrew Twyman
• LCLintLCL: Yang Meng Tan, John Guttag,
Jim Horning
• FundingDARPA, NSF, ONR
Recommended