Research in Programming Languages and Security

1. Research in Programming Languages and Security David Evans Office 236A, 982-2218 evans@cs.virginia.edu http://www.cs.virginia.edu/~evans University of Virginia Computer Science

2. Menu Naccio: Policy-Directed Code Safety How do you prevent bad programs from doing bad things? naccio.cs.virginia.edu LCLint: Annotation-Assisted Static Checking How do you help good people not write bad programs? lclint.cs.virginia.edu

3. Naccio Motivation Problems with existing code safety systems: • Don’t let you express many useful policies e.g., can restrict what network connections are opened, but not what is done with them after • Define policies in ad hoc, platform-dependent ways • Can’t reuse policies on programs for different platforms • Hard to write, understand and reason about policies

4. Naccio Overview Program • General method for defining policies • Abstract resources • Platform independent • System architecture for enforcing policies • Prototypes for JavaVM classes, Win32 executables Naccio Safety Policy Safe Program

5. Naccio Architecture Per policy Per application Safety policy definition Program Program transformer Policy compiler Policy description file • Version of program that: • Uses policy-enforcing system library • Satisfies low-level code safety Policy-enforcing system library

6. Problem User’s View System View Program tar cf * WriteFile (fHandle, …) System Library Policy Platform Interface OS Kernel Resources Files Disk

7. Safety Policy Definition • Resource descriptions: abstract operational descriptions of resources (files, network, …) • Platform interface: mapping between system API and abstract resources • Resource use policy: constraints on manipulating those resources

8. Example Resource Use Policy • stateblockTrackBytesWritten • addfieldRFileSystem.bytes_written: int = 0; • precodeRFileSystem.write (file: RFile, nbytes: int) • bytes_written += nbytes; • propertyLimitBytesWritten (n: int) • requires TrackBytesWritten; • checkRFileSystem.write (file: RFile, nbytes: int) • if (bytes_written > n) violation (“Writing more than …”);

9. Policy Compiler Resource use policy Platform independent analyses Resource descriptions 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 Platform interface Describes Java API Policy description file Platform dependent analyses and code generation System library Java library classes

10. Program Collection of Java classes Program Transformer Policy description file • Version of program that: • Uses policy-enforcing library • • Replace class names in constant pool • • Wrappers for dynamic class loading methods • Satisfies low-level code safety • • Use Java byte code verifier • • Wrappers on reflection methods

11. Status • Naccio/JavaVM – policies on Java classes • Complete implementation, works • Performance better than JDK • Naccio/Win32 – Win32 executables • Done by Andrew Twyman (MIT MEng thesis) • Works for non-adversarial programs • Doesn’t implement necessary low-level code safety • More information: • naccio.cs.virginia.edu IEEE Security & Privacy ‘99 paper, my thesis

12. Some Naccio-related Projects • Low-level code safety for Naccio/Win32 • Prevent malicious programs from tampering with or circumventing checking code and data • Validate a Platform Interface • Develop techniques for verifying a platform interface and API implementation are consistent according to some model • Others at www.cs.virginia.edu/~evans/projects.html and breakout session

13. LCLint: Annotation-Assisted Static Checking all Formal Verifiers LCLint Bugs Detected Compilers none Low Unfathomable Effort Required

14. 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

15. Example • extern only null void *malloc (int); in library 1 int dummy (void) { 2 int *ip= (int *) malloc (sizeof (int)); 3 *ip = 3; 4 return *ip; 5 } LCLint 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

16. Philosophy (Why it works) • Don’t try to be perfect: • 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 • Performance matters – must be fast as compiler

17. LCLint Status Date: Tue, 2 Nov 1999 10:28:29 From: milpuz@phoenix.psc.ac.yu … One more question – Why did you stop developing LCLint? I find some mistakes that is very easy to fix. Milos (16 year old in Yugoslavia) • Public distribution since 1993 • Widely distributed (mostly linux) • About 1000 active users (but lots not writing annotations) • Checks ANSI C programs • Large, unwieldy code base • More information: • lclint.cs.virginia.edu PLDI ’96, FSE’94

18. Some LCLint Projects • Detecting buffer overflows • Check CERT reports • Meta-annotations • Allow users to define new annotations and associated checking • Generalize framework • Support static checking for multiple source languages in a principled way

19. Programming Device Networks • New project – not well defined yet • Assume everything you own is networked • Different programming problem: • Computation simple, interactions complex • Must work the first time • Must behave reasonably despite unpredictable events • Performance hardly matters

20. For more information… Breakout session: Thursday, 5:30-7 in 236D Email me by noon Thursday if you are coming Office hours: Mondays 1:30-2:30 evans@cs.virginia.edu http://www.cs.virginia.edu/~evans