Download ppt - Secure Certifying Compilation

Secure Certifying Compilation

David Walker

Cornell University

What do you want to type check today?

April 12, 2000

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)Code

SystemInterface

Download, Link & Execute

April 12, 2000


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

April 12, 2000


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?

April 12, 2000


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 reliability of extensible systems

April 12, 2000


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

April 12, 2000


Certified Code

• Attach annotations/certificate (types, proofs, ...) to untrusted object code extensions

• Certificates make verification feasible• Move away from trust-based security & reliability

UntrustedCode

SystemInterface

Download &CheckCertificate

Link & Execute

SecureCode

April 12, 2000


Certifying Compilation

High-level Program

Compile

Optimize

AnnotatedIR

Transmit

• 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

certificate

April 12, 2000


Question

How should we obtain the initial certificate?

April 12, 2000


Answer

• Use a type-safe language

• Type inference relieves the tedium of proof construction

• Programmers will rewrite programs so they type check

April 12, 2000


Certifying Compilation So FarType SafeHigh-level Program

Compile

Optimize

TypedProgram

Transmit

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

April 12, 2000


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 produce type safety proofs

• Typed Assembly Language [Morrisett, Walker, et al]

– flexible type constructor language that can encode high-level abstractions

– guarantees type safety properties

April 12, 2000


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

April 12, 2000


Outline





April 12, 2000


Flexible Security Policies

• Specify policies independently of extensible system

• Compiler instruments extensions

• Easier to understand, debug, evolve policies

High-levelExtension

Compiler

Analyze &Optimize

SecurityPolicy Instrument

April 12, 2000


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

April 12, 2000


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

April 12, 2000


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

April 12, 2000


Outline





April 12, 2000


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

April 12, 2000


Security Architecture

High-level Extension

Instrument

Optimize

SecureTypedExtension

Transmit

SecurityAutomaton

Specification

SecureTypedInterface

Type Check

System Interface

Annotate

SecureExecutable

April 12, 2000


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”

April 12, 2000


Example

• 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

starthasread

read(f)

send read(f)

badsend

April 12, 2000


Example Cont’d

starthasread

read(f)

send read(f)

badsend

% untrusted program % s.a.: start statesend(); % ok -> startread(f); % ok -> has read send(); % bad, security violation

• S.A. monitor program execution

• Entering the bad state = security violation

April 12, 2000


Bounding Resource Use

0

malloc (i)

i n - 1

• Policy: "allocate fewer than n bytes"

...

bad

malloc (i)

...

April 12, 2000


Enforcing S.A. Specs• Every security-relevant operation has

an associated function: checkop

• Trusted, provided by policy writer

• checkop implements the s. a. transition function

checksend (state) = if state = start then start else halt % terminates execution

April 12, 2000


Enforcing S.A. Specs

• Easy, wrap all function calls in checks:

• Improve performance using program analysis

let next_state = checksend(current_state) insend()

send()

April 12, 2000


Outline

• Technology for improved reliability and security– Idea I: certifying compilation– Idea II: security via code instrumentation

• Secure certifying compilation [popl '00]



April 12, 2000


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

April 12, 2000


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

April 12, 2000


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

April 12, 2000


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

April 12, 2000


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

April 12, 2000


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)

April 12, 2000


bar: {...} ... % Known: instate(start) ... jmp foo [start]

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]

April 12, 2000


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)

April 12, 2000


Encoding Security Automata• 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

send: [curr,next,P1,P2,P3].{ ecx: [P4].{ } }

– P4: instate(next)

Post: P4

April 12, 2000


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

April 12, 2000


Compile-time & Run-time• Compile-time reasoning depends on run-

time valuesfoo: 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 establish precondition for send

checksend: % postcond. == precond. for ret1, send

April 12, 2000


Checksend

• A type for checksend (first try)

checksend:

[curr,P1].{eax:state, ecx:[next,P1,P2,P3].{eax:state} }

where

P1 = instate(curr), P2 = transsend(curr,next), P3 = next bad

April 12, 2000


Checksend

• A type for checksend (first try)

• No correspondence between run-time argument and static information

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

April 12, 2000


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]

April 12, 2000


[curr,P1].{eax:state(curr),ecx:[next,P1,P2,P3].{eax:state(next)}}

– P1 = instate(curr), P2 = transsend(curr,next), P3 = next bad

• checksend

– implements the automaton transition function• intuitively has type state -> state• singletons help relate run-time values to compile-time predicates

Using Singletons

April 12, 2000


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

April 12, 2000


Optimization• Analysis of s.a. structure makes redundant

check elimination possible– eg:

– identify transsend(start,start) as valid

starthasread

read(f)

send read(f)

badsend

April 12, 2000


Optimization

Low-level Interface

send: 'read: 'checksend: 'checkread: '

Axiom A = transsend(start,start)

Policy

High-level Interface

April 12, 2000


Optimization

• Type-checker is simple but general

• Typical optimizations– redundant check removal– loop invariant removal

loop : [instate(start)].{ } mov ecx, loop jmp send [start,start,By A];

send: [curr,next,instate(curr),transsend(curr,next), next bad].{ecx: [P4].{ }}

April 12, 2000


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

April 12, 2000


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


April 12, 2000


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

April 12, 2000


Summary

• A recipe for secure certified code:– types

• ensure basic safety without run-time overhead• add a logic to encode complex invariants

– policy-directed code instrumentation• specify security policies independently of the rest of

the system• use dynamic checking to enforce policies when

they can’t be proven statically