Native Client: A Sandbox for Portable, Untrusted x86 Native Code - - PowerPoint PPT Presentation

Native Client: A Sandbox for Portable, Untrusted x86 Native Code

Bennet Yee, David Sehr, Gregory Dardyk, J. Bradley Chen, Robert Muth, Tavis Ormandy, Shiki Okasaka, Neha Narula, and Nicholas Fullagar Google Inc. Presented by: Gilmore R. Lundquist April 4, 2012

Overview and Goals Architecture Implementation Extras

Outline

1

Overview and Goals

2

Architecture Organization NaCl Modules Communication Service Runtime Trusted NaCl Services Attack Surface

3

Implementation Sandboxing SFI / Inner Sandbox Validator Validator Performance Memory Layout Trampolines Springboard

4

Extras

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Outline

1

Overview and Goals

2

Architecture Organization NaCl Modules Communication Service Runtime Trusted NaCl Services Attack Surface

3

Implementation Sandboxing SFI / Inner Sandbox Validator Validator Performance Memory Layout Trampolines Springboard

4

Extras

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Overview

Native Client (”NaCl”) is: A sandbox for untrusted x86 native code A browser-based framework Designed to:

Give browser-based applications the computational performance of native applications Provide operating system portability Provide performance-oriented features

Threading Instruction set extensions (e.g., SSE) Compiler intrinsics Hand-coded assembly

An open architecture

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Computation!

Running native code allows previously infeasible computations to run with your browser: Simulation of Newtonian physics Computational fluid-dynamics High-resolution scene rendering Use of languages other than JavaScript

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Previous Problems

Native code allowed previously (e.g., ActiveX, NPAPI)

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Previous Problems

Native code allowed previously (e.g., ActiveX, NPAPI) Problem: Native code must be trusted

Browser security mechanisms are circumvented

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Previous Problems

Native code allowed previously (e.g., ActiveX, NPAPI) Problem: Native code must be trusted

Browser security mechanisms are circumvented

Problem: Trust must be established manually (pop-up boxes)

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Previous Problems

Native code allowed previously (e.g., ActiveX, NPAPI) Problem: Native code must be trusted

Browser security mechanisms are circumvented

Problem: Trust must be established manually (pop-up boxes) Ineffective for preventing security problems

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Threat Model

Modules can contain arbitrary code Runtime confirms that the code conforms to validity rules Code which doesn’t conform is rejected Once accepted, module must be constrained to prevent unintended side effects

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Threat Model

The NaCl module may: Arbitrarily combine the entire variety of behaviors permitted by the NaCl execution environment in attempting to compromise the system Execute any reachable instruction block in the validated text segment Exercise the NaCl application binary interface to access runtime services in any way: passing invalid arguments, etc. Send arbitrary data via our intermodule communication interface, with the communicating peer responsible for validating input Allocate memory and spawn threads up to resource limits Attempt to exploit race conditions in subverting the system

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Outline

1

Overview and Goals

2

Architecture Organization NaCl Modules Communication Service Runtime Trusted NaCl Services Attack Surface

3

Implementation Sandboxing SFI / Inner Sandbox Validator Validator Performance Memory Layout Trampolines Springboard

4

Extras

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Organization

Figure: Hypothetical NaCl-based application with a trusted storage service.

Untrusted modules have a grey background.

Native Client is organized in two parts: A constrained execution environment for native code to prevent unintended side effects A runtime for hosting these native code extensions through which allowable side effects may occur safely

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Organization

Figure: Hypothetical NaCl-based application with a trusted storage service.

Untrusted modules have a grey background.

Application components (untrusted):

Browser component: User Interface written in HTML / JavaScript Constrained by browser Native component: NaCl module Constrained by NaCl container (inner and outer sandboxes) 32-bit executables (currently no 64-bit support) Both parts portable across OS / browser

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Organization

Figure: Hypothetical NaCl-based application with a trusted storage service.

Untrusted modules have a grey background.

NaCl system components (trusted):

NaCl browser plugin (OS and browser specific) Inter-component communication IMC (Inter-Module Communications) Simple Remote Procedure Call (SRPC) Netscape Plugin Application Programming Interface (NPAPI) Service runtime Trusted NaCl services (e.g., storage service)

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

NaCl Modules

NaCl modules consist of untrusted x86 code NaCl module load is requested by JavaScript

Might load one or more modules

Loaded silently (no pop-ups involved) Ideally used for pure computation Uses SFI to sandbox and secure

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Communication

Browser to NaCl module communication subsystems IMC (Inter-Module Communications)

Reliable datagram service Can be used by trusted and untrusted clients

2 protocols available, built on IMC

(SRPC) Simple Remote Procedure Call

Used for JavaScript calls to native code

(NPAPI) Netscape Plugin Application Programming Interface

Used to access browser state, open URLs, access the DOM Provides facilities normally available in JavaScript Allows: Browser content modifications, handling mouse/keyboard activity, fetching additional site content

Shared memory and shared synchronization objects also available from IMC

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Service Runtime

The service runtime provides system services common to application programming: sysbrk() mmap() malloc() / free() (or similar) POSIX threads subset with NaCl extensions

Robust enough to port Intel’s Thread Building Blocks to NaCl

POSIX file IO

Used for communications channels Used for fetching web-based read-only content Cannot affect the local file system connect() and accept() NOT provided – can create sockets in JavaScript

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Trusted NaCl Services

Trusted NaCl service (e.g., storage service) Installed as a browser plugin Use of syscalls prevents implementation as NaCl module Communication to and from trusted services is available through any IMC services NaCl module can use static linking to a library to encapsulate communication details Service is trusted, and therefore must assume clients are untrusted!

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Attack Surface

Components an attacker might exploit: Inner sandbox: Binary validation Outer sandbox: OS system-call interception Service runtime binary module loader Service runtime trampoline interfaces IMC communications interface NPAPI interface

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Outline

1

Overview and Goals

2

Architecture Organization NaCl Modules Communication Service Runtime Trusted NaCl Services Attack Surface

3

Implementation Sandboxing SFI / Inner Sandbox Validator Validator Performance Memory Layout Trampolines Springboard

4

Extras

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Sandboxing

NaCl provides inner and outer sandboxes The outer sandbox is very similar to systrace or Janus (not described in paper) The inner sandbox:

Is x86-specific Uses static analysis (taken from proof-carrying code techniques) Disallows

Self-modifying code Arbitrary instructions

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Inner Sandbox

The inner sandbox is implemented via Software Fault Isolation (SFI) Provides reliable disassembly Disallows unsafe machine instructions Constrains data and instruction memory references This is done by enforcing alignment and structural rules

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

SFI Overview

The goal is to isolate untrusted code from trusted code. This is done by limiting the memory areas where untrusted code can run, and the data it can access. The trusted service runtime runs in the same process as the untrusted module. A secure trampoline/springboard mechanism allows control to transfer between trusted and untrusted areas.

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

SFI Implementation

SFI is implemented via: Rules for reliable disassembly A modified compilation toolchain (gcc) which follows these rules A static analyzer (validator) which verifies the rules have been followed This allows for a small trusted code base (TCB) Only the validator is trusted, not the entire compiler Validator is small and easy to analyze: 600 C statements (semicolons)

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

SFI Implementation

Rules for disassembly (Constraints for NaCl binaries): C1 Once loaded into the memory, the binary is not writable, en- forced by OS-level protection mechanisms during execution. C2 The binary is statically linked at a start address of zero, with the first byte of text at 64K. C3 All indirect control transfers use a nacljmp pseudo-instruction (defined below). C4 The binary is padded up to the nearest page with at least one hlt instruction (0xf4). C5 The binary contains no instructions or pseudo-instructions over- lapping a 32-byte boundary. C6 All valid instruction addresses are reachable by a fall-through disassembly that starts at the load (base) address. C7 All direct control transfers target valid instructions.

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Validator Requirements

To eliminate side effects the validator must address four sub-problems: Data integrity: no loads or stores outside of data sandbox Reliable disassembly No unsafe instructions Control flow integrity

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Data Integrity

Data integrity: no loads or stores outside of data sandbox Uses 80386 segments Constrain data references to a contiguous subrange of the virtual 32-bit address space. (simplifying, performance enhancing)

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

No Unsafe Instructions

No unsafe instructions Using reliable disassembly: detects disallowed opcodes (e.g.): syscall, int (no direct OS interaction) lds, far calls (any instruction which modifies x86 segment state) ret (replaced by sandboxing sequence)

Sequence ends with indirect jump Prevents race condition with checking return address on stack

no memory addressing on indirect jmp, call no privileged (ring-0) instructions

• nly specific x86 instruction prefixes allowed

Known useful instructions allowed (prevents DoS vulnerabilities)

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Control-Flow Integrity

All control flow transfers must target an instruction identified during disassembly Direct branches statically computed - must point to a valid instruction in our disassembly Indirect branches

Code segment constrained to zero-based address range Mask used to ensure branch target is aligned mod 32: and %eax, 0xffffffe0 jmp *%eax (”nacljmp”) More efficient than previous techniques (one ’and’ vs. ’and’ and ’or’)

Call instructions located in final bytes of 32-byte block

Properly aligns return addresses

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Validator Pseudocode (Part 1)

// TextLimit = the upper text address limit // Block(IP) = 32-byte block containing IP // StartAddr = list of inst start addresses // JumpTargets = set of valid jump targets // Part 1: Build StartAddr and JumpTargets IP = 0; icount = 0; JumpTargets = { } while IP <= TextLimit: if inst_is_disallowed(IP): error "Disallowed instruction seen" StartAddr[icount++] = IP if inst_overlaps_block_size(IP): error "Block alignment failure" if inst_is_indirect_jump_or_call(IP): if !is_2_inst_nacl_jmp_idiom(IP) or icount < 2 or Block(StartAddr[icount-2]) != Block(IP): error "Bad indirect control transfer" else // Note that indirect jmps are inside // a pseudo-inst and bad jump targets JumpTargets = JumpTargets + { IP } // Proceed to the fall-through address IP += InstLength(IP) Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Validator Pseudocode (Part 2)

// Part 2: Detect invalid direct transfers for I = 0 to length(StartAddr)-1: IP = StartAddr[I] if inst_is_direct_jump_or_call(IP): T = direct_jump_target(IP) if not(T in [0:TextLimit))

• r not(T in JumpTargets):

error "call/jmp to invalid address"

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Validator Performance

Validator can check code at approximately 30MB/second

35.7 MB in 1.2 seconds, measured on a MacBook Pro with MacOS 10.5, 2.4GHz Core 2 Duo CPU, warm file-system cache

Validation time is small compared to download time Fuzzing on instructions used to check validator and verify correctness

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Memory Layout

NaCl module constrained to 256MB segment-isolated region (First segment - begins with all 0s) First 64KB reserved

First 4KB read and write protected to detect NULL pointers Next 60KB contains trampoline and springboard code

Untrusted module loaded immediately after first 64KB Trusted code loaded in other (non-zero) segments

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Trampolines

Trampolines are used to transfer flow out of untrusted code Table of system call trampolines Entry points at beginning of every 32-byte block To transfer control:

Uses far call to reset %cs segment register Resets (restores) other segement registers for trusted code Loads %esp with location of trusted stack

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Springboard

The springboard allows control transfer from trusted code back to the untrusted area One entry in trampoline table begins with hlt and contains the springboard code

This alignment prevents use by untrusted code

To transfer control:

(Unused) trampoline return address is popped from the stack Segment registers are restored Jump to return address

Springboard is used by the trusted runtime:

to transfer control to an arbitrary untrusted address, to start a new POSIX-style thread, and to start the main thread.

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Outline

1

Overview and Goals

2

Architecture Organization NaCl Modules Communication Service Runtime Trusted NaCl Services Attack Surface

3

Implementation Sandboxing SFI / Inner Sandbox Validator Validator Performance Memory Layout Trampolines Springboard

4

Extras

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Extras

See the paper for: Proof of reliable disassembly Discussion of exception handling Performance results and case studies

SPEC2000 benchmarks Quake H.264 Decoder Bullet (physics simulation)

Related work

Presented by: Gilmore R. Lundquist Native Client

Overview and Goals Architecture Implementation Extras

Questions?

Presented by: Gilmore R. Lundquist Native Client