1 / 20

Research in Programming Languages and Security

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. Menu. Naccio: Policy-Directed Code Safety How do you prevent bad programs from doing bad things?

ccody
Download Presentation

Research in Programming Languages and Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related