Rethinking Kernel Isolation Vasileios P. Kemerlis Network Security Lab Department of Computer Science Columbia University New York, NY, USA Georgia Institute of Technology, 09/12/2014 vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 1 / 59
Outline Introduction Kernel attacks & defenses Problem statement Attack ( ret2dir ) Background Bypassing SMEP / SMAP , PXN , PaX, kGuard Defense (XPFO) Design & implementation Performance Conclusion Recap vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 4 / 59
Introduction Kernel attacks & defenses Attacking the “Core” Threats classification 1. Privilege escalation I Arbitrary code execution code-injection, ROP, ret2usr 7 Kernel stack smashing 7 User-after-free, double free, dangling pointers 7 Kernel heap overflows 7 Signedness errors, integer overflows 7 Wild writes, o ff -by- n 7 Race conditions, memory leaks 7 Poor arg. sanitization 7 Missing authorization checks 2. Persistent foothold I Kernel object hooking (KOH) control-flow hijacking 7 Kernel control data (function ptr., dispatch tbl., return addr.) 7 Kernel code ( .text ) I Direct kernel object manipulation (DKOM) cloaking 7 Kernel non-control data 3. ... vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 5 / 59
Introduction Kernel attacks & defenses Attacking the “Core” Threats classification 1. Privilege escalation I Arbitrary code execution code-injection, ROP, ret2usr 7 Kernel stack smashing 7 User-after-free, double free, dangling pointers 7 Kernel heap overflows 7 Signedness errors, integer overflows 7 Wild writes, o ff -by- n 7 Race conditions, memory leaks 7 Poor arg. sanitization 7 Missing authorization checks 2. Persistent foothold I Kernel object hooking (KOH) control-flow hijacking 7 Kernel control data (function ptr., dispatch tbl., return addr.) 7 Kernel code ( .text ) I Direct kernel object manipulation (DKOM) cloaking 7 Kernel non-control data 3. ... vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 6 / 59
Introduction Kernel attacks & defenses Attacking the “Core” Threats classification 1. Privilege escalation I Arbitrary code execution code-injection, ROP, ret2usr 7 Kernel stack smashing 7 User-after-free, double free, dangling pointers 7 Kernel heap overflows 7 Signedness errors, integer overflows 7 Wild writes, o ff -by- n 7 Race conditions, memory leaks 7 Poor arg. sanitization 7 Missing authorization checks 2. Persistent foothold I Kernel object hooking (KOH) control-flow hijacking 7 Kernel control data (function ptr., dispatch tbl., return addr.) 7 Kernel code ( .text ) I Direct kernel object manipulation (DKOM) cloaking 7 Kernel non-control data 3. ... vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 7 / 59
Introduction Kernel attacks & defenses Return-to-user ( ret2usr ) Attacks What are they? Attacks against OS kernels with shared kernel/user address space • Overwrite kernel code (or data) pointers with user space addresses 7 return addr., dispatch tbl., function ptr., 7 data ptr. I Payload ! Shellcode, ROP payload, tampered-with data structure(s) I Placed in user space 7 Executed (referenced) in kernel context I De facto kernel exploitation technique I Facilitates privilege escalation arbitrary code execution 7 http://www.exploit-db.com/exploits/34134/ (21/07/14) 7 http://www.exploit-db.com/exploits/131/ (05/12/03) vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 8 / 59
Introduction Kernel attacks & defenses ret2usr Attacks (cont’d) Why do they work? Weak address space (kernel/user) separation • Shared kernel/process model ! Performance X cost(mode switch) ⌧ cost(context switch) I The kernel is protected from userland ! Hardware-assisted isolation 7 The opposite is not true 7 Kernel ambient authority (unrestricted access to all memory and system objects) I The attacker completely controls user space memory • Contents & perms. vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 9 / 59
Introduction Kernel attacks & defenses kGuard [USENIX Sec ’12] Versatile & lightweight protection against ret2usr I Cross-platform solution that enforces (partial) address space separation between user and kernel space • x86, x86-64, ARM, ... • Linux, Android, { Free, Net, Open } BSD, ... I Builds upon inline monitoring and code diversification I Implemented as a set of modifications to the pipeline of GCC • Non-intrusive & low overhead • Back-end plugin ! ⇠ 1KLOC in C Front − ends Middle − end *.c, *.i C GIMPLE Back − end *.cc, *.c++ C++ *.cxx, *.cpp RTL High *.m, *.mi Objective − C GIMPLE SSA *.java Java GENERIC GIMPLE kGuard ... ... Low (NOP & CFA) GIMPLE Fortran *.F, *.FOR *.s vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 10 / 59
Introduction Kernel attacks & defenses kGuard Design Control-flow assertions (key technology #1) I Compact, inline guards injected at Instrumented code Original code compile time branch CFA • Two flavors ! CFA R & CFA M kernel branch I Placed before every exploitable control .text transfer branch kernel .text • call , jmp , ret in x86/x86-64 • ldm , blx , ..., in ARM CFA branch I Verify that the target address of an indirect branch is always inside kernel space I If the assertion is true, execution continues normally; otherwise, control is transfered to a runtime violation handler vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 11 / 59
Introduction Kernel attacks & defenses kGuard Design (cont’d) CFA R example cmp $0xc0000000,%ebx if (reg < 0xc0000000) jae lbl reg = &<violation_handler>; mov $0xc05af8f1,%ebx call *reg lbl: call *%ebx Indirect call in drivers/cpufreq/cpufreq.c (x86 Linux) vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 12 / 59
Introduction Kernel attacks & defenses kGuard Design (cont’d) CFA M examples (1/2) push %edi if (&mem < 0xc0000000) lea 0x50(%ebx),%edi call <violation_handler>; cmp $0xc0000000,%edi if (mem < 0xc0000000) jae lbl1 mem = &<violation_handler>; pop %edi call *mem ; call 0xc05af8f1 lbl1: pop %edi cmpl $0xc0000000,0x50(%ebx) jae lbl2 movl $0xc05af8f1,0x50(%ebx) lbl2: call *0x50(%ebx) Indirect call in net/socket.c (x86 Linux) vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 13 / 59
Introduction Kernel attacks & defenses kGuard Design (cont’d) CFA M examples (2/2) & optimizations cmpl $0xc0000000,0xc123beef if (&mem < 0xc0000000) jae lb call <violation_handler>; movl $0xc05af8f1,0xc123beef if (mem < 0xc0000000) lb: call *0xc123beef mem = &<violation_handler>; call *mem ; Optimized CFA M guard (x86 Linux) vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 14 / 59
Introduction Kernel attacks & defenses ret2usr Defenses State of the art overview X KERNEXEC / UDEREF ! PaX I 3 rd -party Linux patch(es) ! x86-64/x86/AArch32 only I HW/SW-assisted address space separation • x86 ! Seg. unit (reload %cs , %ss , %ds , %es ) • x86-64 ! Code instr. & temporary user space re-mapping • ARM (AArch32) ! ARM domains X kGuard ! Kemerlis et al. [USENIX Sec ’12] I Cross-platform solution that enforces (partial) address space separation • x86, x86-64, ARM, ... • Linux, { Free, Net, Open } BSD, ... I Builds upon inline monitoring (code intr.) & code diversification (code inflation & CFA motion) X SMEP / SMAP , PXN ! Intel, ARM I HW-assisted address space separation • Access violation if priv. code (ring 0) executes/accesses instructions/data from user pages ( U/S = 1) I Vendor and model specific (Intel x86/x86-64, ARM) vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 15 / 59
Introduction Kernel attacks & defenses ret2usr Defenses (cont’d) Summary vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 16 / 59
Introduction Problem statement Rethinking Kernel Isolation [USENIX Sec ’14] What is this talk about? Focus on ret2usr defenses ! SMEP / SMAP , PXN , PaX, kGuard vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 17 / 59
Introduction Problem statement Rethinking Kernel Isolation [USENIX Sec ’14] What is this talk about? Focus on ret2usr defenses ! SMEP / SMAP , PXN , PaX, kGuard I Can we subvert them? • Force the kernel to execute/access user-controlled code/data I Conflicting design choices or optimizations? • “Features” that weaken the (strong) separation of address spaces vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 17 / 59
Introduction Problem statement Rethinking Kernel Isolation [USENIX Sec ’14] What is this talk about? Focus on ret2usr defenses ! SMEP / SMAP , PXN , PaX, kGuard I Can we subvert them? • Force the kernel to execute/access user-controlled code/data I Conflicting design choices or optimizations? • “Features” that weaken the (strong) separation of address spaces Return-to-direct-mapped memory ( ret2dir ) I Attack against hardened (Linux) kernels X Bypasses all existing ret2usr schemes X 8 ret2usr exploit 9 ret2dir exploit vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 17 / 59
Attack ( ret2dir ) Background Kernel Space Layout Linux x86/x86-64 vpk@cs.columbia.edu (Columbia University) ret2dir GT ’14 18 / 59
Recommend
More recommend
