CSci 5271 Guest Lecture Software-based Fault Isolation Navid Emamdoost navid@cs.umn.edu Need for extensibility Problem with extensions ● Applications can incorporate independently developed ● Security and Reliability ● Extensions may be modules ○ ○ Operating System Malicious ● Add new file system ○ Vulnerable ○ D atabase Management Sys tem ○ Faulty ● User-defined data type ● Solution: ○ Browser ○ Isolate from others ● Multimedia editor 3 4 Isolation option 1 Isolation option 1 ● Hardware-based isolation ● Hardware-based isolation ○ ○ Place each module in its own address space Place each module in its own address space ○ ○ Communicate via RPC Communicate via RPC ■ Switch to kernel mode ■ Copy arguments ■ Save/Restore registers RPC RPC ■ Switch address spaces ■ Return to user mode Module A Module B Module C Module B Module C 5 6
Isolation option 2 Isolation option 2 ● Software-based isolation ● Software-based isolation ○ ○ All modules in same virtual address All modules in same virtual address ○ ○ Protect them from each other Protect them from each other ○ ○ Provide efficient communication Provide efficient communication 7 8 Goal Efficient Software-based Fault Isolation ● Protect the rest of an application from a buggy/malicious module on RISC architecture ● Separate untrusted code Robert Wahbe, Steven Lucco, Thomas E. Anderson, Susan L. Graham ○ Define a fault domain SOSP 1993 ○ Prevent the module from jumping or writing outside of it ○ While letting efficient communications 10 Fault Domain Unsafe Instructions ● Load untrusted extension into its own fault domain ● Jump or store instructions jmp 0x10001e0 ○ ○ Code Segment Change Control flow ○ ○ Data Segment Change data ● Security Policy: ● Addressing issue ○ ○ No code is executed outside of fault domain jmp 0x10001e0 ○ No data changed outside of fault domain Code ■ Some protect load, too 0x10001e0 Add 0x4,%ebx Segment Data Segment 11 12
Unsafe Instructions Unsafe Instructions ● Jump or store instructions ● Jump or store instructions jmp 0x10001e0 jmp *%ecx ○ ○ Change Control flow Change Control flow ○ ○ Change data Change data ● Addressing issue ● Addressing issue ○ jmp 0x10001e0 ○ jmp 0x10001e0 ○ jmp *%ecx ○ mov %eax,0x11020028 0x10001e0 Add 0x4,%ebx 0x10001e0 Add 0x4,%ebx ○ mov %eax,0x11020028 ○ mov $0x1b80,(%ecx) 13 14 Segment ID Segment Matching ● Within a segment ● Insert checking code before unsafe instruction ○ ○ Addresses share unique pattern of upper bits check segment ID of target address ● Use dedicated registers 0x148a0000 Target Address Code Segment dedicated-reg ⇐ target-address 0x148affff scratch-reg ⇐ (dedicated-reg >> shift-reg) 0x148d0000 if scratch-reg == segment-reg: Segment ID Data Segment jmp/mov using dedicated-reg 0x148dffff Segment Matching Address Sandboxing ● Needs 4 dedicated registers ● Ensure, do not check! ● Checking code must be atomic ● Before each unsafe instruction ● Exact location of fault can be detected ○ Set upper bit of target address to correct segment ID ● Runtime overhead dedicated-reg ⇐ target-address & and-mask ○ 4 extra instructions dedicated-reg ⇐ dedicated-reg | segment-reg jmp/mov using dedicated-reg
Address Sandboxing Optimizations ● Prevents faults ● register-plus-offset mode ● Needs 5 dedicated registers ○ store value, offset(reg) ● 2 extra instructions ○ offset is in the range of -64K to +64K ○ less overhead compared to segment matching ○ mov %esi,0x8(%edx) reg+ offset Guard Zone reg Segment Guard Zone Optimizations Cross Fault Domain Communication ● Stack pointer ● Host to an untrusted module ● Untrusted module to host ○ Just sandbox it when it is set (beginning of a function) ● Call/Return Stub ○ Ignore sandboxing for small changes (push, pop) ○ ○ Works because of guard zones For each pair of fault domains 22 Cross Fault Domain Call Implementation ● Trusted call/return stub ● Change the compiler copy parameters o ○ emit encapsulation code into distrusted code switch execution stack ● At the load time o maintain values of CPU registers o ○ check the integrity of encapsulation code no traps or address space switching o ○ Verifier ▪ faster returns via jump table o ▪ jump targets are immediates ▪ a legal address in target fault domain 24
Verifier ● Responsible for checking encapsulation instructions just What about CISC architectures?! before execution start ● Challenge: x86 ○ indirect jump ● Hint: ○ every store/jump uses dedicated registers ● Look for changes in dedicated registers ○ any change means beginning of a check region ○ verify the integrity of check region 25 26 CISC Architectures Evaluating SFI for a CISC Architecture (PittSFIeld) ● RISC Architecture ○ Fixed length instructions Stephen McCamant, Greg Morrisett ○ More CPU registers USENIX 2005 ● Intel IA-32 (aka x86-32) ○ Variable length instructions ○ Less CPU registers ● Classical SFI is not applicable here 28 CISC Architectures Alignment ● Processor can jump to any byte ● Divide memory into 16-byte chunks ● Hard to make hidden instructions safe ● No instruction is allowed to cross chunk boundary ● Solution: Instruction Alignment ● Target of jumps placed at the beginning of chunks ● Call instructions placed at the end of chunk 29 30
Alignment Jumps ● Use NOP for padding ● Chunks are atomic ● No separation of an unsafe instruction and its check ● Jump destinations are checked to be 16-byte aligned 31 32 Example Optimization: AND-only Sandboxing ● Choose code and data region addresses carefully ● Their ID just has one bit set ● Reduces sandboxing sequence to just one instruction SFI SFI Trusted Code and Reserved Code Data Data 0x00000000 0x00ffffff 0x10000000 0x10ffffff 0x20000000 0x20ffffff 0xffffffff 33 34 Verification Performance overhead ● Statically check ● Implemented prototype ○ No jump to outside of code region ○ named PittSFIeld ○ ● Average module overhead: 21% 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 faster sandboxing AND communications ● The sandboxing AND should not be the last instruction in a ○ no trap, RPC, etc chunk 35
Google Native Client Native-client: A Sandbox for Portable, Untrusted x86 Native Code ● Browser Plugin (Google Chrome) ○ Allows execution of untrusted C/C++ code in browser Bennet Yee, et al. ● Browser?! Native Code?! IEEE S&P, 2009 ○ Yes! browsers are new platform for applications ● Gives Browser plugins performance of native code ● Ships by default since Chrome 14 38 Sandboxing NaCl Architecture ● Inner Sandbox Code sandboxing ○ Alignment and address sandboxing ■ Check branch target addresses ■ Data Sandboxing ○ segmented addressing mode supported by x86_32 ■ ● Outer Sandbox Controls system calls issued by native code ○ Whitelist ○ 39 40 Source: https://media.blackhat.com/bh-us-12/Briefings/Rohlf/BH_US_12_Rohlf_Google_Native_Client_Slides.pdf Inner Sandbox Native Client Toolchain ● On x86_32 ● Modified GCC and GAS Sandboxing via segmented memory ○ To emit sandboxing instructions ○ Used to separate trusted from untrusted code/data ○ ● Final executable has ELF file structure (called NEXE) Modified when switching between trusted/untrusted ○ Can be disassembled using standard tools ○ %cs code ○ ○ objdump -d %ds data ○ %gs thread local storage ○ and $0xffffffe0,%ebx naclcall %ebx %ss %es %fs all set to %ds call *%ebx ○ ● On x86_64 and $0xffffffe0,%ecx mov/branch alignment, guard pages nacljmp %ecx ○ jmp *%ecx r15 keeps base address of an aligned 4GB range ○ 41 42
Recommend
More recommend
