secure execution of untrusted code
DESCRIPTION
Secure Execution of Untrusted Code. Motivation. Mobile code scenarios Java applet / Javascript in web page Postscript / PDF file Email attachment BPF Active networks Agent technology. Untrusted Code. My Secure PC. Challenges. Untrusted code may - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/1.jpg)
Secure Execution ofUntrusted Code
![Page 2: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/2.jpg)
Motivation
My Secure PC
UntrustedCode
Mobile code scenarios• Java applet / Javascript in web page
• Postscript / PDF file
• Email attachment
• BPF
• Active networks
• Agent technology
![Page 3: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/3.jpg)
Challenges
Untrusted code may• Read sensitive memory regions
(password, cryptographic keys, db records)• Write memory areas, violate integrity
(overwrite public verification key)• Jump to arbitrary location (jump past password
verification)• Perform arbitrary system calls (execute arbitrary
local programs, access file system)• Waste resources, DoS (memory, computation,
network bandwidth), thrash OS (while 1 do fork())• Crash program, OS
![Page 4: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/4.jpg)
Solution 1: Separate Process
Run untrusted code in separate process Advantages
• Memory separation through VM system Disadvantages
• Inter-Process Communication (IPC) is expensive–Context switch has high overhead (TLB, cache)
• Untrusted code can do any system calls To protect file system, use chroot
![Page 5: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/5.jpg)
Solution 2: Signed Code
Only accept code digitally signed by trusted entity
Advantages• Simple security policy
• Can be secure if trusted entity creates “secure code”
Disadvantages• Security relies on secrecy of private key
• Security relies on authenticity of public key
• Coarse-grained access control
![Page 6: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/6.jpg)
Solution 3: Sandboxing
Run code in limited environment Verify each system call Verify each memory
reference Advantage
• Fine-grained control
Disadvantages• Efficiency• Expressing security policy• Sandbox may have security vulnerabilities
UntrustedCode
Sandbox
Application
![Page 7: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/7.jpg)
Solution 4: SFI
Provide memory safety efficiently• Can only r/w legitimate memory locations
Software fault isolation (SFI): transform untrusted code into safe code• Compiler: generates safe code
–Ship source code, or
–Generate code that verifier can easily check
• Loader (binary patching): rewrite untrusted code
![Page 8: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/8.jpg)
SFI Load each module into its own fault
domain• Code is in read-only part
• Module can r/w anything within fault domain
• Code can only jump within fault domain
Two parts• Efficient Software Encapsulation
• Fast Communication Across Fault Domains
UntrustedCodeApplication Untrusted
CodeUntrusted
Code
![Page 9: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/9.jpg)
Efficient Software Encapsulation
Goal• Only allow writes within data part of fault domain• Only allow jumps within code segment of fault domain
Mechanisms• Split memory space into segments, each segment has a
segment identifier (high-order bits of address), and comprises all addresses for any low-order bits
• Separate code and data segments• Dedicated registers are only used by inserted code, cannot be
modified by untrusted code• Tame unsafe instructions by segment matching or address
sandboxing– PC-relative jumps often safe, static stores are safe– Other stores and jumps are unsafe
![Page 10: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/10.jpg)
RISC Instruction Set Simplifies SFI
Memory accessed with load / store instruction (no add to memory)
All instructions have fixed size, and are aligned• Simplifies instruction verification
• Simplifies jump target verification
Usually large number of registers• Can tolerate giving up 5 dedicated registers
![Page 11: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/11.jpg)
Segment Matching
Verifies correctness of memory accesses Advantage
• Can pinpoint address of offending instruction, useful in debugging
Disadvantage• Slow
dedicated-reg target addressscratch-reg (dedicated-reg >> shift reg)compare scratch-reg and segment-regtrap if not equalstore instruction uses dedicated-reg
![Page 12: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/12.jpg)
Address Sandboxing
Set segment identifier for each memory access / jump instruction• Overwrite segment identifier with fault domain’s
segment identifier
Advantage: efficient Disadvantage: cannot pinpoint flaw, only
enforces that accesses are within domain
dedicated-reg target-reg & and-mask-regdedicated-reg dedicated-reg | segment-regstore instruction uses dedicated-reg
![Page 13: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/13.jpg)
Puzzles
What about the following transformation, not using dedicated register?
target-reg target-reg & and-mask-regtarget-reg target-reg | segment-regstore instruction uses target-reg
What about jumps into SFI verification instructions? Could we jump outside of fault domain? Could we write to code segment? Could we jump to data segment?
What if we only used 4 dedicated registers (sandboxing case, i.e., 1 dedicated-reg for code/data)?
![Page 14: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/14.jpg)
4-Register Attack
jump target-reg
dedicated-reg target-reg & and-mask-regdedicated-reg dedicated-reg | segment-reg-cjump instruction uses dedicated-reg
target-reg = r2
dedicated-reg target-reg & and-mask-regdedicated-reg dedicated-reg | segment-reg-dstore instruction uses dedicated-reg
![Page 15: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/15.jpg)
Verification of Instrumented Code
Problem: given instrumented binary, how can we verify that all rules are met?
Verify that all unsafe stores and jumps use dedicated registers to form address
Verify that all inserted code has correct pattern (identify inserted code by use of dedicated registers)
![Page 16: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/16.jpg)
Fast Communication Across Fault Domains
Use Jump Table with legal entry points outside fault domain
For each call between fault domains, a customized stub procedure is created• Stubs run unprotected outside fault domain• Trusted stub directly copies arguments to
destination domain• Switch execution stack• Set up register context and validate
dedicated registers
![Page 17: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/17.jpg)
SFI Discussion
System calls from fault domain?• Issues and solutions
Allowing arbitrary memory reads? Could we improve the granulartiy of memory
protection?• Missing read protection a problem?
Is granularity of jump protection sufficient? Flexibility for segment size? Internal fragmentation? Can SFI prevent buffer overruns? Is self-modifying code possible? SFI on CISC processors? Can we change compiler once verifier is deployed?
![Page 18: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/18.jpg)
Solution 5: PCC
Proof-carrying code (PCC) developed @ CMU by George Necula and Peter Lee
Goal: safely run code in unsafe languages Approach: create efficiently verifiable proof
that untrusted code satisfies safety policy May not need instrumentation code (no
execution overhead!) if we can prove code safety
Slides based on George Necula’s OSDI96 talk
![Page 19: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/19.jpg)
Proof-Carrying Code: An Analogy
oracle bits
Legend: code proof
![Page 20: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/20.jpg)
Proof-Carrying Code (PCC)
certification
proofvalidation
untrustedapplication code
nativecode
safetyproof
code producer
code consumer
CPU
PCC binary
formalsafety policy
![Page 21: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/21.jpg)
Benefits of PCC
Wide range of safety policiesmemory safety
• resource usage guarantees (CPU, locks, etc.)
• concurrency propertiesdata abstraction boundaries
Wide range of languagesassembly languages
• high-level languages
Simple, fast, easy-to-trust validation Tamper-proof
![Page 22: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/22.jpg)
Experimentation
Goal:• Test feasibility of PCC concept
• Measure costs (proof size and validation time)
Choose simple but practical applicationsNetwork Packet Filters
• IP Checksum
• Extensions to the TIL run-time system for Standard ML
![Page 23: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/23.jpg)
Experimentation (2)
Use DEC Alpha assembly language (hand-optimized for speed)
Network Packet Filters• BPF safety policy: “The packet is read-only
and the scratch memory is read-write. No backward branches. Only aligned memory accesses.”
![Page 24: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/24.jpg)
PCC Implementation (1)
Formalize the safety policy:• Use first-order predicate logic extended with
can_rd(addr) and can_wr(addr)
• Kernel specifies safety preconditions
–Calling convention
–Guaranteed by the kernel to hold on entry
Use tagged memory to define access
i i i i i
j j j j j
.( r mod ) can_rd(r )
.( mod ) can_wr(r )1 0
2
0 8 0
0 16 8 0
![Page 25: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/25.jpg)
PCC Implementation (2)
Compute a safety predicate for the code• Use Floyd-style verification conditions
(VCgen)
• One pass through 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)
Prove the safety predicate• Use a general purpose theorem prover
![Page 26: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/26.jpg)
PCC Implementation (3)
Formal proofs are trees:• the leaves are axiom instances
• the internal nodes are inference rule instances
• at the root is the proved predicate
• Example:
![Page 27: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/27.jpg)
PCC Implementation (4)
Proof Representation: Edinburgh Logical Framework (LF)
Proofs encoded as LF expressions Proof Checking is LF type checking
• simple, fast and easy-to-trust (14 rules)
• 5 pages of C code
• independent of the safety policy or application
• based on well-established results from type-theory and logic
Large design space, not yet explored
![Page 28: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/28.jpg)
Packet Filter Experiments 4 assembly language packet filters (hand-
optimized for speed):1Accepts IP packets (8 instr.)
2Accepts IP packets for 128.2.206 (15 instr.)
3 IP or ARP between 128.2.206 and 128.2.209
4TCP/IP packets for FTP (28 instr.)
Compared with:• Run-Time Checking: Software Fault Isolation
• Safe Language: Modula-3
• Interpretation: Berkeley Packet Filter
![Page 29: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/29.jpg)
Performance Comparison
Off-line packet trace on a DEC Alpha 175MHz PCC packet filters: fastest possible on the architecture The point: Safety without sacrificing performance!
0
0.5
1
1.5
2
2.5
1 2 3 4Filter
Lat
ency
(u
s)
PCC
SFIM3
BPF
![Page 30: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/30.jpg)
Cost of PCC for Packet Filters
Proofs are approx. 3 times larger than the code Validation time: 0.3-1.8ms
Packet Filter 1 2 3 4Instructions 8 15 47 28Proof Size(bytes) 160 225 532 420Validation Time(us) 362 872 1769 1354
![Page 31: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/31.jpg)
Validation Cost (Filter 3)
Conclusion: One-time validation cost amortized quickly
0
3
6
9
12
15
0 10 20 30 40 50
Thousands of packets
ms
PCCSFIM3BPF
![Page 32: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/32.jpg)
PCC for Memory Safety Continuum of choices between static checking and run-time checking:
PCC can be also used where run-time checking cannot (e.g., concurrency)
Run-TimeChecking
StaticChecking
Performance Penalty
Proof ComplexitySFI
![Page 33: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/33.jpg)
What Can We Check With PCC?
Any property with a sound formalization • if you can prove it, PCC can check it!
One proof-checker for many such policies!• Small commitment for open-ended extensibility
Example: policies defined by safe interpreters • E.g, security monitors, memory safety, resource
usage limits, …
… can be enforced statically with PCC• Prove that all run-time checks would succeed• No run-time penalty
![Page 34: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/34.jpg)
PCC Beyond Memory SafetyExample: database with access control
access item price
agent
pricing server
Safety policy:
• host invokes the agent with:
–security clearance level• item and price fields readable
only if access level–parent
• communication permitted only back to parent
• must terminate within MAX instructions
• wait BNDW * SIZE instructions before sending SIZE bytes
• level• parent
PCC is not limited to memory safety!
![Page 35: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/35.jpg)
Practical Difficulties
Proof generation• Similar to program verification
• But:
–done off-line
–can use run-time checks to simplify the proofs
• In restricted cases it is feasible (even automatable)
Proof-size explosion• It is exponential in the worst case
• Not a problem in our experiments
![Page 36: Secure Execution of Untrusted Code](https://reader036.vdocuments.net/reader036/viewer/2022062322/56815164550346895dbf8f82/html5/thumbnails/36.jpg)
PCC Discussion
A very promising framework for ensuring safety of untrusted code
Limitations? What about generating proof on the fly?
• Could verify safety property based on specific arguments
Related problem: how to secure mobile code from malicious host?