Group meeting: UniSan - Proactive Kernel Memory Initialization to Eliminate Data Leakages
1 like175 views
UniSan is a compiler-based approach that uses static program analysis to identify unsafe kernel memory allocations that have potential to leak sensitive data. It instruments the code to initialize only the unsafe allocations with memset to zero. The evaluation found it effectively prevented 43 recent Linux kernel uninitialized data leaks while having low overhead for both system operations and user space programs. Future work could focus on custom heap allocators, analyzing more kernel modules, and applying the technique beyond kernels.
Group meeting: UniSan - Proactive Kernel Memory Initialization to Eliminate Data Leakages
- 1. UniSan: Proactive Kernel Memory Initialization to Eliminate Data Leakages Kangjie Lu, Chengyu Song, Taesoo Kim, and Wenke Lee SSlab, Georgia Institute of Technology ACM CCS â16
- 2. Outline âą Kernel Information Leaks âą Related Work âą Design and Implementation âą Evaluation âą Discussion and Future Work
- 4. Security mechanisms in OS kernels âą kASLR âą Randomizing the address of code/data âą Preventing code-reuse and privilege escalation attacks âą StackGuard âą Inserting random canary in stack âą Preventing stack corruption-based attacks
- 5. Main causes of information leaks âą Uninitialized data read: Reading data before initialization, which may contain uncleared sensitive data âą Out-of-bound read: Reading across object boundaries âą Use-after-free: Using freed pointer/size that can be attacker controlled âą Others: Missing permission check, race condition
- 6. About 60% kernel information leaks are caused by uninitialized data read
- 7. From uninitialized data read to leak
- 9. Troublemaker: developer leak to user space
- 11. Troublemaker: compiler size = 8 bytes
- 12. Zero initialization? âą C99: padding bytes take unspeciïŹed values âą C11: yes or no
- 13. Related Work âą Kernel leak detection and prevention âą check if there is no assignment or memset between the allocation and copy_to_user âą STACKLEAK: clears the used kernel stack when the control is transferred back to the user space âą Detecting uninitialized memory accesses âą -Wuninitialized: intra-procedural analysis âą dynamic tracking: >10x overhead âą MemorySanitizer: 3-4x overhead âą Protections using zero-initialization
- 15. UniSan approach âą Compiler-based approach (LLVM) âą Conservatively identify unsafe allocations (i.e., with potential leaks) via static program analysis âą Instrument the code to initialize only unsafe allocations
- 16. LLVM Google âLLVM for Grad Studentsâ for more!
- 18. DeïŹning Sources and Sinks âą Sources âą For stack: AllocaInst âą For heap: kmalloc, kmem_cache_alloc, ⊠⹠__GFP_ZERO ïŹag âą Sinks âą copy_to_user, sock_sendmsg, vfs_write, ⊠int a; %a = alloca i32
- 19. DeïŹning Sources and Sinks âą for any data to leave kernel space, it will always be stored to a non-kernel-stack location (or non- AllocaInst to be speciïŹc) âą Rule 1: A StoreInst is a sink if the destination is not allocated by an AllocaInst in kernel âą Rule 2: A CallInst is a sink if the called value is inline assembly that is not in the whitelist âą Rule 3: A CallInst is a sink if the called functionâs body is empty
- 20. Building Global Call-Graph âą inter-procedural analysis âą For address-taken functions (function pointer) âą type-analysis-based approach to ïŹnd the targets of indirect calls
- 21. Recursive Detection Algorithm âą Given an allocation âą build its user-graph âą recursively keep track the initialization status and whether reaching sink functions X
- 22. Tracking Different Users âą LoadInst âą StoreInst âą CallInst âą GEPOperator âą ReturnInst âą CastInst
- 23. Tracking Different Users âą LoadInst âą %b = load i32, i32* %a âą StoreInst âą store i32* %a, i32** %b âą store i32 0, i32* %a â independently track, then merge â âalias analysis, independently track, then merge âinitialization
- 24. Tracking Different Users âą CallInst âą recursively track the arguments in callees âą inline assembly âą sink functions
- 25. Tracking Different Users âą GEPOperator âą %b = getelementptr inbounds %struct.foo, %struct.foo* %a, i32 0, i32 2 âą creates an alias of the tracked value âą non-constant indices
- 26. Tracking Different Users âą ReturnInst âą use the global call-graph to ïŹnd all CallInsts that call the current function containing the ReturnInst âą independently tracked -> merged
- 27. Instrumenting Unsafe Allocations âą For stack âą StoreInst âą memset() âą For heap âą __GFP_ZERO ïŹag
- 28. Instrumenting Unsafe Allocations âą For dynamic allocation âą record size value during initialization analysis âą check whether initialized by memset using the same size âą if yes, instrument to compute the size then pass to memset to initialize
- 29. Evaluation
- 30. Platform âą Latest mainline Linux kernel for x86_64 âą with patches from LLVMLinux âą Latest Android kernel for AArch64
- 31. Accuracy 9% 14%
- 32. Effectiveness âą Known leaks: 43 recent kernel uninitialized data leaks reported after 2013 âą Unknown leaks
- 33. EfïŹciency âą For system operation
- 34. EfïŹciency âą For user space program (x86_64)
- 35. âą For user space program (AArch64) EfïŹciency
- 36. Miscellaneous âą Analyses took less 3 minutes âą Binary size increased < 0.5%
- 37. Discussion and Future Work âą Custom heap allocator âą Source code requirement âą Security impacts of zero-initialization âą False positives âą More kernel modules âą Beyond kernels
- 38. Contribution âą Survey of kernel information leaks âą Development of new protection mechanism âą Discoveries of new vulnerabilities