proof-carrying code: a language-based security approach thao doan wei hu liqian luo jinlin yang...
DESCRIPTION
11/16/2004CS851 Malware3 Part 1 Introduction to Language-Based SecurityTRANSCRIPT
Proof-Carrying Code: A Language-Based Security Approach
Thao DoanWei Hu
Liqian LuoJinlin Yang
CS851 Malware11/16/2004
11/16/2004 CS851 Malware 2
Outline
1. Introduction To Language-based Security2. Proof-carrying Code (PCC)3. Example 1: Network Packet Filters4. Example 2: A Certifying Compiler For Java5. Issues With PCC6. Discussion
11/16/2004 CS851 Malware 3
Part 1Introduction to Language-Based
Security
11/16/2004 CS851 Malware 4
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
11/16/2004 CS851 Malware 5
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
11/16/2004 CS851 Malware 6
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
11/16/2004 CS851 Malware 7
Disadvantages of traditional approaches
• Miss unseen cases• Trust entities required• Performance• Burden on consumers
11/16/2004 CS851 Malware 8
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
11/16/2004 CS851 Malware 9
Part 2Proof-Carrying Code:
Concept and Implementation
11/16/2004 CS851 Malware 10
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/16/2004 CS851 Malware 11
Cons of type-safe languages• Have large trusted computing base
– many exploits of JVM itself has been reportedhttp://www.cs.princeton.edu/sip/history/index.php3
• Require many run-time tests– casts, arrays, pointers, etc.
• Incur inflexibility
11/16/2004 CS851 Malware 12
Proof-carrying code (PCC)
Code Consumer
Publicizes safety policy
Provides Proof
Code producer
Validates Proof
CPU
Native Proofcode
[Necula, POPL’97]
11/16/2004 CS851 Malware 13
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
11/16/2004 CS851 Malware 14
• 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
11/16/2004 CS851 Malware 15
Code Producer
CodeConsumersafety
Policy
native code
ProofGenerator
annotatedassembly code
PCC system architecture
validator
verification condition (VC)generator
code in high levelprogramming language
safetypredicate
theoremprover
proof
compiler
1. safety rules2. module interface
11/16/2004 CS851 Malware 16
An example function on a DEC Alpha
11/16/2004 CS851 Malware 17
Part 3Example 1 - Network Packet Filters
[Necula et. al. OSDI'96]
11/16/2004 CS851 Malware 18
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!
11/16/2004 CS851 Malware 19
The solution - PCC
11/16/2004 CS851 Malware 20
A PCC example
• Goal– Test feasibility of PCC concept– Measure costs (proof size and validation
time)– Choose simple but practical applications
• Network Packet Filters
11/16/2004 CS851 Malware 21
Network packet filters
OS kernel
user process space
network monitoring application
network
packet
filter
11/16/2004 CS851 Malware 22
Safety policy
11/16/2004 CS851 Malware 23
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.
11/16/2004 CS851 Malware 24
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))
11/16/2004 CS851 Malware 25
Code certification
11/16/2004 CS851 Malware 26
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
11/16/2004 CS851 Malware 27
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
11/16/2004 CS851 Malware 28
Per-packet delay
•PCC packet filters: fastest possible on the architecture
•The point: Safety without sacrificing performance!
11/16/2004 CS851 Malware 29
Cost
• Proofs are approx. 3 times larger than the code• Validation time: 0.3-1.8ms
11/16/2004 CS851 Malware 30
0369
1215
0 10 20 30 40 50Thousands of packets
ms
PCCSFIM3BPF
Startup cost amortization
• Conclusion: One-time validation cost amortized quickly
11/16/2004 CS851 Malware 31
Conclusion
• A very promising framework for ensuring safety of untrusted code
• Achieves safety without sacrificing performance
• Serious difficulties exist• Needs more experiments
11/16/2004 CS851 Malware 32
Part 4Example 2 - A certifying compiler
for Java
11/16/2004 CS851 Malware 33
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]
11/16/2004 CS851 Malware 34
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
11/16/2004 CS851 Malware 35
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
Register Valueedx ieax coefficientsecx coefficients.lengthf6 termf7 result
for(int i=0; i<coefficients.length; i++){ result += coefficients[i] * term; term *= x;}
Loop Annotations
11/16/2004 CS851 Malware 36
VC generationflds 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))))
11/16/2004 CS851 Malware 37
CC for modern OO languages
Key Challenges:• Handle advanced language features
– Dynamic creation of objects– Exception handling– Floating point arithmetic
• Optimization• Cost (time & space)
11/16/2004 CS851 Malware 38
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]
11/16/2004 CS851 Malware 39
Demo
http://raw.cs.berkeley.edu/Ginseng/Images/pccdemo.html
11/16/2004 CS851 Malware 40
Part 5Issues with PCC
11/16/2004 CS851 Malware 41
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
11/16/2004 CS851 Malware 42
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
11/16/2004 CS851 Malware 43
ComparisonsType-specializedPCC Foundational 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)
11/16/2004 CS851 Malware 44
Foundational PCC
• More secure
• More flexible
[Appel, LICS ’01]
11/16/2004 CS851 Malware 45
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?