1 / 51

Secure Certifying Compilation

Explore the concept of certifying compilation to improve the security and reliability of extensible systems. Learn about the benefits, challenges, and implementation of this approach.

tinaf
Download Presentation

Secure Certifying Compilation

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. Secure Certifying Compilation What do you want to type check today? David Walker Cornell University

  2. Extensible Systems Many systems have programmable interfaces. • printers and editors (postscript printers, emacs, Word) • browsers and servers (applets, plugins, CGI-scripts) • operating systems (virus scanners) • networks (active networks, JINI) System Interface Code Download, Link & Execute David Walker, Cornell University

  3. Extensible Systems: Pros • Client-side customization • plug in your own devices, 3rd-party utilities • Preservation of market-share • vendors can add features, improve functionality easily • System maintenance and evolution • software subscriptions David Walker, Cornell University

  4. Extensible Systems: Cons • Security • extensibility opens system to malicious attacks • how do we prevent misuse of resources? • Reliability • flexibility makes it hard to reason about system evolution • how do we limit damage done by erroneous extensions? David Walker, Cornell University

  5. Extensible Systems: Reality • Strong economic and engineering pros • Mobile code, systems with programmable interfaces will proliferate • A necessity: practical technology for increasing the security and reliabilityof extensible systems David Walker, Cornell University

  6. Outline • Framework for improved reliability and security • Idea I: certifying compilation • Idea II: security via code instrumentation • An instance [popl '00] • Security automaton specifications • A dependently-typed target language (TAL) • Related work & research directions David Walker, Cornell University

  7. Certified Code Untrusted Code Secure Code System Interface • Attach annotations/certificate (types, proofs, ...) to untrusted object code extensions • Certificates make verification feasible • Move away from trust-based security & reliability Download & Check Link & Execute Certificate David Walker, Cornell University

  8. Certifying Compilation High-level Program • Low-level certificate generation must be automated • Necessary components: 1) a source-level programming language 2) a compiler to compile and optimize source programs while preserving the certificate 3) a certifying target language Compile certificate Annotated IR Optimize Transmit David Walker, Cornell University

  9. Question How should we obtain the initial certificate? David Walker, Cornell University

  10. Answer • Use a type-safe language • Type inference relieves the tedium of proof construction • Programmers will rewrite programs so they type check David Walker, Cornell University

  11. Certifying Compilation So Far Type Safe High-level Program 1) a strongly typed source-level programming language 2) a type-preserving compiler to compile and optimize source programs 3) a certificate language for type-safety properties types Compile Typed Program Optimize Transmit David Walker, Cornell University

  12. Certifying Compilers • Proof-Carrying Code[Necula & Lee] • an expressive base logic that can encode many security policies • in practice, logic is extended with a type system • compilers producetype safetyproofs • Typed Assembly Language[Morrisett, Walker, et al] • flexible type constructor language that can encode high-level abstractions • guarantees type safety properties David Walker, Cornell University

  13. Conventional Type Safety • Conventional types ensure basic safety: • basic operations performed correctly • abstraction/interfaces hide data representations and system code • Conventional types don't describe complex security policies • eg: policies that depend upon history • Melissa virus reads Outlook contacts list and then sends 50 emails David Walker, Cornell University

  14. Outline • Framework for improved reliability and security • Idea I: certifying compilation • Idea II: security via code instrumentation • An instance [popl '00] • Security automaton specifications • A dependently-typed target language (TAL) • Related work & research directions David Walker, Cornell University

  15. Flexible Security Policies High-level Extension • Specify policies independently of extensible system • Compiler instruments extensions • Easier to understand, debug, evolve policies Compiler Security Policy Instrument Analyze & Optimize David Walker, Cornell University

  16. Security Policy Specifications • Requirement: a language for specifying security policies • Features: • Notation for specifying events of interest • "network send" and "file read" are security-sensitive • Notation for specifying illegal behaviour • a privacy policy: "no send after read" • A feasible compilation strategy • must be able to prevent programs from violating the policy David Walker, Cornell University

  17. Examples • SFI [Wahbe et al] • events are read, write, jump • enforce memory safety properties • SASI[Erlingsson & Schneider],Naccio[Evans & Twyman] • flexible policy languages • not certifying compilers David Walker, Cornell University

  18. Putting it Together • define policies in a high-level, flexible and system-independent specification language • instrument system extensions both with dynamic security checks and static information • preserve proof of security policy during compilation and optimization • verify certified compiler output to reduce TCB David Walker, Cornell University

  19. Outline • Framework for improved reliability and security • Idea I: certifying compilation • Idea II: security via code instrumentation • An instance [popl '00] • Security automaton specifications • A dependently-typed target language (TAL) • Related work & research directions David Walker, Cornell University

  20. Secure Certified Code • Overview of Architecture • Security Automata [Erlingsson & Schneider] • How to specify security properties • A simple compilation strategy • A dependently-typed target language (TAL) • A brief introduction to TAL • Extensions for certifying security properties • theoretical core language proven sound • can express any security automaton policy David Walker, Cornell University

  21. Security Architecture Security Automaton Specification High-level Extension System Interface Instrument Annotate Secure Typed Extension Secure Typed Interface Type Check Optimize Secure Executable Transmit David Walker, Cornell University

  22. Security Automata • A general mechanism for specifying security policies • Specify any safety property • access control policies: • “cannot access file foo” • resource bound policies: • “allocate no more than 1M of memory” • the Melissa policy: • “no network send after file read” David Walker, Cornell University

  23. Example read(f) • Policy: No send operation after a read operation • States: start, has read, bad • Inputs (program operations): send, read • Transitions (state x input -> state): • start x read(f) -> has read start has read send read(f) bad send David Walker, Cornell University

  24. Example Cont’d read(f) • S.A. monitor program execution • Entering the bad state = security violation start has read send read(f) bad send % untrusted program % s.a.: start state send(); % ok -> start read(f); % ok -> has read send(); % bad, security violation David Walker, Cornell University

  25. Bounding Resource Use malloc (i) • Policy: "allocate fewer than n bytes" 0 i n - 1 ... ... malloc (i) bad David Walker, Cornell University

  26. Every security-relevant operation has an associated function: checkop Trusted, provided by policy writer checkop implements the s. a. transition function Enforcing S.A. Specs checksend (state) = if state = start then start else halt % terminates execution David Walker, Cornell University

  27. Enforcing S.A. Specs • Easy, wrap all function calls in checks: • Improve performance using program analysis send() let next_state = checksend(current_state) in send() David Walker, Cornell University

  28. Outline • Technology for improved reliability and security • Idea I: certifying compilation • Idea II: security via code instrumentation • Secure certifying compilation [popl '00] • Security automaton specifications • A dependently-typed target language (TAL) • Related work & research directions David Walker, Cornell University

  29. Brief TAL Overview • Assembly or machine code with typing annotations • Object files checked separately and linked together • Ensures basic safety without run-time checks • Memory safety: can't read/write arbitrary memory • Control-flow safety: can't execute arbitrary data • Type abstraction: TAL can encode and enforce high-level abstract data types Typecheck Link David Walker, Cornell University

  30. A TAL Compiler • TAL is practical • We compile "safe C" (aka Popcorn) • No pointer arithmetic, unsafe casts • ML-style data types, polymorphism, exceptions • Some simple optimizations • null-check elimination, inlining, register allocation • The compiler bootstraps • most compiler hacking by Grossman, Morrisett, Smith David Walker, Cornell University

  31. Other TAL Features • Memory management features • Stack types • Aliasing • Region-based MM • See Dave’s thesis • Other features • Dynamic linking • Run-time code generation • http://www.cs.cornell/talc David Walker, Cornell University

  32. Typing Assembly Code • Programs divided into labeled code blocks • Each block has a code type: {eax:,ebx:,...} • Code types specify expected register contents • Assume code type to check the block • Prove control transfers (jumps) meet the assumptions Foo : {eax: int, ecx: {eax: int}} mov ebx, 3; % {eax: int, ebx: int, ecx: {eax: int}} add eax, ebx; % OK jmp ecx % OK David Walker, Cornell University

  33. Increasing Expressiveness • Basic types ensure standard type safety • functions and data used as intended and cannot be confused • security checks can’t be circumvented • Introduce a logic into the type system to express security invariants • Use the logic to encode the s.a. policy • Use the logic to prove checks unnecessary David Walker, Cornell University

  34. Target Language Predicates • States (for compile-time reasoning) • constants: start, has read, bad, ... • variables: 1, 2, ... • Predicates: • describe security states • instate() • describe relationships between states • transsend(1,2) • describe dependencies between values • (see the paper) David Walker, Cornell University

  35. Preconditions • Code types can specify preconditions: • A typical use: foo: [, instate(),   bad].{eax:1, ecx:2} - instantiate polymorphic variable  - prove residual preconditions - eg: instate(start), start  bad - hope proofs are easy (syntactic matching) - otherwise place explicit proof at call site - eg: jmp foo [start, Proof, Proof] bar: {...} ... % Known: instate(start) ... jmp foo [start] David Walker, Cornell University

  36. Postconditions • Expressed as a precondition on the return address type: bar: { eax: 1, ecx: [instate(has read)].{eax: 2} } • Before returning, bar proves instate(has read) • After return, assume instate(has read) David Walker, Cornell University

  37. Each security-relevant function has a type specifying 3 preconditions, 1 postcondition the send function: P1: instate(curr) P2: transsend(curr,next) P3: next bad Pre: P1, P2, P3 Encoding Security Automata • P4: instate(next) • Post: P4 send: [curr,next,P1,P2,P3].{ ecx: [P4].{ } } David Walker, Cornell University

  38. Technical Note • State predicates behave linearly • as in linear logic, each state predicate is used once • instate(curr) is "consumed" at send call site • can't be used in future proofs • can't fool type system into thinking code continues to be in state curr • instate(next) is "produced" on return • will be used when next calling a security-sensitive function David Walker, Cornell University

  39. Compile-time reasoning depends on run-time values Compile-time & Run-time foo: mov eax, state % should represent the current state mov ecx, ret1 jmp checksend % state argument, state result in eax ret1: push eax % save next state on the stack mov ecx, ret2 jmp send % must establishprecondition for send checksend: % postcond. == precond. for ret1, send David Walker, Cornell University

  40. A type for checksend(first try) Checksend • checksend: • [curr,P1].{eax:state, ecx:[next,P1,P2,P3].{eax:state} } • where • P1 = instate(curr), P2 = transsend(curr,next), P3 = next  bad David Walker, Cornell University

  41. A type for checksend(first try) No correspondence between run-time argument and static information Checksend • checksend: • [curr,P1].{eax:state, ecx:[next,P1,P2,P3].{eax:state} } • where • P1 = instate(curr), P2 = transsend(curr,next), P3 = next  bad mov eax, wrong_state; mov ecx, next; jmp checksend David Walker, Cornell University

  42. Checksend • Solution: provide very precise types • Singleton types • A type containing one value • eax : state(start) • means eax contains a data structure that represents exactly the start state and no other state • eax : state() • eax contains data representing the unknown state  • useful in many contexts • Similar to Dependent ML [Xi & Pfenning] David Walker, Cornell University

  43. Using Singletons • checksend • implements the automaton transition function • intuitively has type state -> state • singletons help relate run-time values to compile-time predicates • [curr,P1].{eax:state(curr),ecx:[next,P1,P2,P3].{eax:state(next)}} • P1 = instate(curr), P2 = transsend(curr,next), P3 = next  bad David Walker, Cornell University

  44. Using Checksend foo: { … } ... % Assume: instate(curr), eax : state(curr) mov ecx, ret1 jmp check_send[curr] ret1: [next, instate(curr), transsend(curr,next), next bad]. {eax:state(next)}. push eax; mov ecx, ret2; jmp send [curr,next] % P1 & P2 & P3 ==> ok ret2: ... David Walker, Cornell University

  45. Optimization • Analysis of s.a. structure makes redundant check elimination possible • eg: • identify transsend(start,start) as valid read(f) start has read send read(f) bad send David Walker, Cornell University

  46. Optimization Low-level Interface send: ' read: ' checksend: ' checkread: ' Axiom A = transsend(start,start) Policy High-level Interface David Walker, Cornell University

  47. Optimization loop :[instate(start)].{ } mov ecx, loop jmp send [start,start,By A]; send: [curr,next,instate(curr),transsend(curr,next), next bad].{ecx: [P4].{ }} • Type-checker is simple but general • Typical optimizations • redundant check removal • loop invariant removal David Walker, Cornell University

  48. Implementation • TALx86 implementation is sufficient for these encodings • includes polymorphism, higher-order type constructors, logical connectives (,,), singleton types, .... • Lots more work to be done • axioms in module interfaces • policy compiler David Walker, Cornell University

  49. Outline • Technology for improved reliability and security • Idea I: certifying compilation • Idea II: security via code instrumentation • Secure certifying compilation [popl '00] • Security automaton specifications • A certifying target language • Related work & research directions David Walker, Cornell University

  50. Research Directions • Design of policy languages • What kinds of logics can we compile & certify? • Mawl [Sandholm & Schwartzbach] • TALres [Crary & Weirich] • Design of safety architecture • How do we "clean up" after halting a program? • Support for mutually distrustful agents • Policy-directed optimizations David Walker, Cornell University

More Related