Group meeting: UniSan - Proactive Kernel Memory Initialization to Eliminate Data Leakages

Paper (ACM CCS '16): http://dl.acm.org/citation.cfm?id=2978366

Transcript

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
3. Kernel Information Leaks
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
8. Troublemaker: developer
9. Troublemaker: developer leak to user space
10. Troublemaker: developer function pointer
11. Troublemaker: compiler size = 8 bytes
12. Zero initialization? • C99: padding bytes take unspecified 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
14. Design and Implementation
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. Defining Sources and Sinks • Sources • For stack: AllocaInst • For heap: kmalloc, kmem_cache_alloc, … • __GFP_ZERO flag • Sinks • copy_to_user, sock_sendmsg, vfs_write, … int a; %a = alloca i32
19. Defining 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 specific) • 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 find 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 find 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 flag
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. Efficiency • For system operation
34. Efficiency • For user space program (x86_64)
35. • For user space program (AArch64) Efficiency
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
39. Try UniSan: https://github.com/sslab-gatech/unisan