CSci 5271 Software-based Fault Isolation Navid Emamdoost - PDF document

CSci 5271 Software-based Fault Isolation Navid Emamdoost navid@cs.umn.edu Oct-16-2014 Need for extensibility Problem with extensions ● UNIX vnode interface ● Security! ● Extensions may be o Add new file system ● Postgres database o Malicious o User-defined data type o Vulnerable ● Browser plugins o Faulty ● Solution: o Incorporate plugins (possibly from untrusted sources) o Isolate from other codes Isolation options Isolation options (cont’d) ● Hardware-based isolation ● Software-based isolation o Different virtual address space All modules in same virtual address Protect them from each other o Communicate via RPC Provide an efficient communication RPC Module A Module B Module C Goal Efficient Software-based Fault Isolation ● Protect the rest of an application from a buggy/malicious module on RISC architecture ● Separate distrusted code Robert Wahbe, Steven Lucco, Thomas E. Anderson, Susan L. Graham o Define a fault domain SOSP 1993 o Prevent the module from jumping or writing outside of it o While letting efficient communications ● Security Policy: o No code is executed outside of fault domain o No data changed outside of fault domain

Fault Domain Segment ID ● Load untrusted extension into its own fault domain ● Within a segment o Code Segment o Addresses share unique pattern of upper bits o Data Segment 0x148a0000 Code Segment Target Address Code Segment 0x148affff Data Segment 0x148d0000 Segment ID Data Segment 0x148dffff Unsafe Instruction Unsafe Instruction ● Jump or store instructions ● Jump or store instructions ● Addressing issue ● Addressing issue o jmp 10001e0 o jmp 10001e0 ● or o jmp *%ecx ● or o mov %eax,0x11020028 o mov %eax,0x11020028 o mov $0x11018b80,%ecx Segment Matching Segment Matching ● Insert checking code before unsafe insn ● Needs 4 dedicated registers ● Checking code must be atomic o check segment ID of target address ● Use dedicated registers ● Exact location of fault can be detected ● Runtime overhead dedicated-reg ⇐ target-address o 4 extra instructions scratch-reg ⇐ (dedicated-reg >> shift-reg) if scratch-reg == segment-reg: jmp/mov using dedicated-reg Address Sandboxing Address Sandboxing ● Ensure, do not check! ● Prevents faults ● Before each unsafe instruction ● Needs 5 dedicated registers ● 2 extra instructions o Set upper bit of target address to correct segment ID o less overhead compared to segment matching dedicated-reg ⇐ target-address & and-mask dedicated-reg ⇐ dedicated-reg | segment-reg jmp/mov using dedicated-reg

Process Resources Optimizations ● No direct syscall ● register-plus-offset mode ● A trusted fault domain receives the syscall o store value, offset(reg)  ● Determine if it is safe offset is in the range of -64K to +64K o mov %esi,0x8(%edx) ● If so, make the syscall and return the result to distrusted code reg+ offset Guard Zone reg Segment Guard Zone Optimizations Cross Fault Domain Call ● Stack pointer ● How to call from another fault domain o just sandbox it when it is set o ignore sandboxing for small changes  push, pop Works because of guard zones o Cross Fault Domain Call Implementation ● Trusted call/return stub ● Change the compiler o copy parameters o emit encapsulation code into distrusted code ● At the load time o switch execution stack o maintain values of CPU registers o check the integrity of encapsulation code o no traps or address space switching o Verifier faster  o returns via jump table  jump targets are immediates  a legal address in target fault domain Verifier Verifier ● Responsible for checking encapsulation instructions just ● Divide program into unsafe regions before execution start o any modification to store dedicated register ● Challenge:  start of store unsafe region o indirect jump o the store unsafe region ends when: ● Hint:  next instruction be a store (uses dedicated register) o every store/jump uses dedicated registers  next instruction be control flow change ● Look for changes in dedicated registers  next instruction is not guaranteed to be executed o any change means beginning of a check region  no more instructions be in the code o verify the integrity of check region o at the end if dedicated register is not sandboxed correctly, reject the code

Performance Overhead ● 4.3% on average ● 21.8% when sandboxing read instructions as well What about CISC architectures?! x86 CISC Architectures Evaluating SFI for a CISC Architecture (PittSFIeld) ● RISC Architecture o Fixed length instructions Stephen McCamant, Greg Morrisett o More CPU registers USENIX 2005 ● Intel IA-32 (aka x86-32) o Variable length instructions o Less CPU registers ● Classical SFI is not applicable here CISC Architectures Solution ● Processor can jump to any byte ● Alignment ● Hard to make hidden instructions safe o Divide memory into 16-byte chunks o No instruction is allowed to cross chunk boundary o Target of jumps placed at the beginning of chunks o Call instructions placed at the end of chunk Alignment Jumps ● Use NOP ● Chunks are atomic ● Jump destinations o for padding ● No separation of are checked to be an unsafe instruction 16-byte aligned and its check

Example Optimization: AND-only Sandboxing ● Reduces sandboxing sequence to just one instruction o choose code and data region addresses carefully o Their ID just has one bit set SFI SFI Trusted Code and Reserved Code Data Data 0x00000000 0x00ffffff 0x10000000 0x10ffffff 0x20000000 0x20ffffff 0xffffffff Verification Performance overhead ● Statically check ● Implemented prototype o No jump to outside of code region o named PittSFIeld ● Average module overhead: 21% o No store to outside of data region ● Before each unsafe jump or store there should be a ● But the overall execution can be improved because of sandboxing AND faster communications ● The sandboxing AND should not be the last instruction o no trap, RPC, etc in a chunk Google Native Client Native-client: A Sandbox for Portable, Untrusted x86 Native Code ● Browser Plugin (Google Chrome) o Allows execution of untrusted native code in browser ● Browser?! Native Code?! Bennet Yee, et al. IEEE S&P, 2009 o Yes! browsers are new platform for applications ● Gives Browser plugins performance of native code ● Ships by default with Chrome 14 ● Very complex architecture o Focus on sandboxing technique Sandboxing Inner Sandbox ● Inner Sandbox ● On x86-32 bit architecture ● Use segmented memory to guaranty data sandboxing o Like PittSFIeld o Alignment and address sandboxing ● Use 32-byte alignment to sandbox jumps  No cross boundary instructions o jump jump target must be aligned  o call ● Outer Sandbox o retturn o Controls system calls issued by native code o Whitelist and $0xffffffe0,%ecx jmp *%ecx

Outer Sandbox Native Client Toolchain ● Second layer of defense for native code ● Modified GCC and GAS ● Filters system calls o To emit sandboxing instructions ● Final executable has .nexe extension ● On linux uses ptrace ● Block any sys call not in whitelist o compiled and linked as ELF file ● Can be disassembled using standard tools ● For some, perform special argument checking o objdump -d o SYS_OPEN: can access to a whitelisted set of files ● Any violation from outer sandbox policy will terminate and $0xffffffe0,%ebx naclcall %ebx call *%ebx native code execution and $0xffffffe0,%ecx nacljmp %ecx jmp *%ecx Performance Evaluation Recap ● Imposes in average %5 overhead ● Sandboxing ● Sources of overhead o Execute untrusted code in a fault domain ● RISC o Inner sandbox  alignment and padding o Simple instructions o Outer sandbox o Address Sandboxing  syscall capturing and whitelisting ● CISC o Complex instructions o Address alignment ● Browser plugin o Benefit native performance in browser Thank you Questions?