Secure Certifying Compilation

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