1. Proof-Carrying Code: A Language-Based Security Approach Thao Doan Wei Hu Liqian Luo Jinlin Yang CS851 Malware 11/16/2004

2. 11/16/2004CS851 Malware2 Outline 1.Introduction To Language-based Security 2.Proof-carrying Code (PCC) 3.Example 1: Network Packet Filters 4.Example 2: A Certifying Compiler For Java 5.Issues With PCC 6.Discussion

3. 11/16/2004CS851 Malware3 Part 1 Introduction to Language-Based Security

4. 11/16/2004CS851 Malware4 Malicious code - A growing problem What is malicious code? –“any code added, changed, removed from a software system in order to intentionally cause harm or subvert the intended function of the system.” What makes it a growing problem? –Growing connectivity (the Internet) –Growing complexity of systems –Support for extensibility

5. 11/16/2004CS851 Malware5 Two well-known security design principles Principle of Least Privilege –a component should be given the minimum privilege necessary to accomplish its task –Ex: file access Principle of Minimum Trusted Computing Base –keep the TCB as small and simple as possible (~ the KISS principle) –Ex: JVM, Proof Checker of PCC

6. 11/16/2004CS851 Malware6 Approaches against malicious code Analyze the code : before execution [reject] –Ex: scanning, compiler’s dataflow analysis Rewrite the code : before execution [modify] –Ex: BEQZ R4, BadCode  BEQZ R4, GoodCode Monitor the code : during execution [stop before harm] –Ex: OS’ page translation hardware Audit the code : during execution [police on harm] –Ex: audit trail to assess and address the problem

7. 11/16/2004CS851 Malware7 Disadvantages of traditional approaches Miss unseen cases Trust entities required Performance Burden on consumers

8. 11/16/2004CS851 Malware8 Motivation of language based security Is it possible to enforce security on the semantics or behavior of the code? Types, logics, & proofs come into play Examples Type-Safe Languages Proof-Carrying Code

9. 11/16/2004CS851 Malware9 Part 2 Proof-Carrying Code : Concept and Implementation

10. 11/16/2004CS851 Malware10 Type-safe languages Type –gives semantic meaning to ultimately mere bits –associated either with values in memory or with objects Type-safe languages: –have complete type systems –e.g., Java, C#, ML Code producer writes code in a type-safe language Code consumer ensures code is safe: –static checks (e.g., type checks) –dynamic checks (e.g., array-bound checks)

11. 11/16/2004CS851 Malware11 Cons of type-safe languages Have large trusted computing base –many exploits of JVM itself has been reported http://www.cs.princeton.edu/sip/history/index.php3 Require many run-time tests –casts, arrays, pointers, etc. Incur inflexibility

12. 11/16/2004CS851 Malware12 Proof-carrying code (PCC) Code Consumer Publicizes safety policy Provides Proof Code producer Validates Proof CPU Native Proof code [Necula, POPL’97]

13. 11/16/2004CS851 Malware13 Benefits of PCC Shifts the burden of ensuring the safety from code consumer to code producer Can verify code in low-level languages Fewer run-time checks  Tamperproof  Simpler, smaller, and faster TCB  No cryptography or external authentication required

14. 11/16/2004CS851 Malware14 Proof generation theorem proving –extend first-order predicate logic to formalize the safety policy Proof validation type checking –Edinburgh Logical Framework (LF) –map proof rules into types in LF Implementation of PCC

15. 11/16/2004CS851 Malware15 Code Producer Code Consumer safety Policy native code Proof Generator annotated assembly code PCC system architecture validator verification condition (VC) generator code in high level programming language safety predicate theorem prover proof compiler 1. safety rules 2. module interface

16. 11/16/2004CS851 Malware16 An example function on a DEC Alpha

17. 11/16/2004CS851 Malware17 Part 3 Example 1 - Network Packet Filters [Necula et. al. OSDI'96]

18. 11/16/2004CS851 Malware18 The problem Examples –OS Extensions, Safe Mobile Code, Programming Language Interoperation Previous Approaches –Hardware memory protection, Runtime checking, Interpretation We want both safety and performance!

19. 11/16/2004CS851 Malware19 The solution - PCC

20. 11/16/2004CS851 Malware20 A PCC example Goal –Test feasibility of PCC concept –Measure costs (proof size and validation time) –Choose simple but practical applications Network Packet Filters

21. 11/16/2004CS851 Malware21 Network packet filters OS kernel user process space network monitoring application network packet filter

22. 11/16/2004CS851 Malware22 Safety policy

23. 11/16/2004CS851 Malware23 Safety policy Follow the BSD Packet Filter (BPF) model of safety –The packet is read-only. –The scratch memory is read-write. –No backward branches. –Only aligned memory accesses.

24. 11/16/2004CS851 Malware24 Safety policy Use first-order predicate logic extended with can_rd(addr) and can_wr(addr) The precondition is: –aligned memory addresses on an 8-byte boundary –r0 (address of packet) –r1 (length of packet) –r2 (address of scratch memory (16 bytes))

25. 11/16/2004CS851 Malware25 Code certification

26. 11/16/2004CS851 Malware26 Code certification Step 1 - Compute a safety predicate for the code –for example: For each LD r,n[rb] add can_rd(rb+n) For each ST r,n[rb] add can_wr(rb+n) Step 2 – Generate a proof (checkable) of the safety predicate

27. 11/16/2004CS851 Malware27 Performance – experiment setup 4 packet filters: –1 Accepts IP packets (8 instr.) –2 Accepts IP packets for 128.2.206 (15 instr.) –3 IP or ARP between 128.2.206 and 128.2.209 (47 instr.) –4 TCP/IP packets for FTP (28 instr.) Compared with: –Interpretation: BSD Packet Filter –Runtime Checking: Software Fault Isolation –Type-safe Language: Modula-3

28. 11/16/2004CS851 Malware28 Per-packet delay PCC packet filters: fastest possible on the architecture The point: Safety without sacrificing performance!

29. 11/16/2004CS851 Malware29 Cost Proofs are approx. 3 times larger than the code Validation time: 0.3-1.8ms

30. 11/16/2004CS851 Malware30 Startup cost amortization Conclusion: One-time validation cost amortized quickly

31. 11/16/2004CS851 Malware31 Conclusion A very promising framework for ensuring safety of untrusted code Achieves safety without sacrificing performance Serious difficulties exist Needs more experiments

32. 11/16/2004CS851 Malware32 Part 4 Example 2 - A certifying compiler for Java

33. 11/16/2004CS851 Malware33 Certifying compiler (recap) Source Certifying Compiler VC Generator VC Native Code Annotations Proof VC Axioms & Rules Proof Generator Axioms & Rules Proof Checker VC Generator Code Producer Code Consumer [Colby et. al. PLDI ‘00]

34. 11/16/2004CS851 Malware34 Class Poly{ Poly(float[] coefficients){…} float eval(float x){ float term = 1.0f; float result = 0.0f; for(int i=0; i<coefficients.length; i++){ result += coefficients[i] * term; term *= x; } return result; } private float[] coefficients; } An example

35. 11/16/2004CS851 Malware35 LOOP_ENTRY: fxch %st(1)// result on top of FPU LOOP_INV = {(lt edx (sel4 rm (add eax 4))), (ge edx, 0), (type f7 jfloat), (type f6 jfloat)} flds 8(%eax, %edx, 4)// load coefficients[i] fmul %st(2), %st(0)// *term faddp// +result fxch %st(1)// term on top of FPU fmuls 12(%ebp)// *x incl %edx// i++ cmpl %ecx, %edx// i<coefficients.length? jl LOOP_ENTRY// loop back if yes RegisterValue edxi eaxcoefficients ecxcoefficients.length f6term f7result for(int i=0; i<coefficients.length; i++){ result += coefficients[i] * term; term *= x; } Loop Annotations

36. 11/16/2004CS851 Malware36 VC generation flds 8(%eax, %edx, 4)// load coefficients[i] prove: (saferd4 (add (sel4 rm_1 (add loc2_1 4)) (add (imul edx_3 4) 8))) It is safe to read coefficients[i] (rdArray4 (tyField (instFld A10 A32 A31) A30) A30 (sub0chk A34) szfloat (aidxi 4 (below1 (lt_b (geswap A38) A37))))

37. 11/16/2004CS851 Malware37 CC for modern OO languages Key Challenges: Handle advanced language features –Dynamic creation of objects –Exception handling –Floating point arithmetic Optimization Cost (time & space)

38. 11/16/2004CS851 Malware38 CC for Java Handle dynamic object creation, exception handling, and float point arithmetic Apply many standard optimizations Proof size: 85% of the code size on average Negligible checking time [Colby et. al. PLDI ‘00]

39. 11/16/2004CS851 Malware39 Demo http://raw.cs.berkeley.edu/Ginseng/Images/p ccdemo.html

40. 11/16/2004CS851 Malware40 Part 5 Issues with PCC

41. 11/16/2004CS851 Malware41 Issues with PCC –Assuming: Trusted VCgen Trusted proof checker No bug in logical axioms No bug in typing rules –Type-specialized built-in understanding of a particular type system

42. 11/16/2004CS851 Malware42 Foundational PCC Code provider provides: - executable code - proof in foundational logic Eliminate implicit built-in logic  Explicitly prove relevant concepts and their properties down to the foundation of mathematics

43. 11/16/2004CS851 Malware43 Comparisons Type-specializedPCCFoundational PCC - Relies on VCgen - First-order logic - Built-in understanding of systems - Large (~23000 LOC in Cedilla Systems) - No VCgen - Higher-order logic - Allows novel type system or safety arguments - Minimal proof checker (2700 LOC)

44. 11/16/2004CS851 Malware44 Foundational PCC More secure More flexible [Appel, LICS ’01]

45. 11/16/2004CS851 Malware45 Discussion What do you think is the hardest part in PCC implementation? Which security problems doesn’t PCC address? To what extent can it be applied? Is it easy for legacy systems to adopt PCC?