1. Analyzing and Improving Linux Kernel Memory Protection A Model Checking Approach ACSAC 2010 Siarhei Liakh, North Carolina State University Michael Grace, North Carolina State University Xuxian Jiang, North Carolina State University

2. Agenda 2  About Code Injection  Murphi  Linux Kernel Memory Model  Analysis  Improvement and Prototype  Evaluation  Discussion and Related Work

3. About Code Injection 3  A method whereby an attacker inserts malicious code into a running process and transfers execution to the malicious code.  W ⊕ X

4. Agenda 4  About Code Injection  Murphi  Linux Kernel Memory Model  Analysis  Improvement and Prototype  Evaluation  Discussion and Related Work

5. What’s Murphi 5  Both a language and a tool for model verification with explicit state enumeration.  Steps Write a finite state machine (FSM) description. (*.m) Compile with Murphi to produce an executable. Run it ▪ A DFS or BFS enumeration. ▪ Anything that can go wrong, will go wrong. ── Murphy’s law

6. Terminology in Murphi 6  State The set of states is implicitly defined through the declaration of global variables. Each combination of values of each variable naturally produces a unique state of the system.  Transition rule The transitions between the states of FSM are defined through a set of transition rules ▪ Guard ▪ Action

7. Terminology in Murphi (2) 7  Initial state A state defined by a special rule with an action which is executed only once.  Invariant A set of logic expressions which define a set of safe states of FSM.

8. Agenda 8  About Code Injection  Murphi  Modeling Linux Kernel Memory Model  Analysis  Improvement and Prototype  Evaluation  Discussion and Related Work

9. Memory Layout 9 Fig. 1: Typical Linux memory mapping

10. How High Memory is Mapped 10  There are two basic mechanisms through which high memory is mapped vmalloc() ▪ Long-term allocation of non-contiguous physical memory into contiguous virtual address space. ▪ May allocate pages from either high or low memory. ▪ An “alias” is created when allocating pages from low memory. That is, the same physical page will be mapped into the kernel virtual address space twice. kmap() ▪ Strictly short-term allocation. ▪ Strictly used for high memory only.

11. Modeling Memory Model 11  In this work, vmalloc() and kmap() are treated as the same (that mapping non-contiguous physical pages into the kernel address space).  Since fixmap doesn’t represent an unique type of mapping, we don’t include it in the model.

12. Modeling Memory Model (2) 12 Fig. 2: Global definition of page table array and physical memory array

13. Initial State 13 

14. Transition Rules 14  Base on source code and domain knowledge, we extract kernel function or API affecting kernel memory mapping cpa_process_alias() __change_page_attr_set_clr() __change_page_att() static_protections() map_vm_area()

15. Transition Rules (2) 15 Fig. 3: Transition rules

16. Invariant 16  P1: Kernel code should always be executable and read-only.  P2: Kernel data should always be non-executable, the read-only kernel data should remain read- only, and read-write kernel data should always be writable.  P3: No page will be writable and executable at the same time in order to not violate W ⊕ X.  P4: All virtual aliases of each physical page should have consistent access permissions.

17. Agenda 17  About Code Injection  Murphi  Linux Kernel Memory Model  Analysis  Improvement and Prototype  Evaluation  Discussion and Related Work

18. After Model Verification 18  There is no P1 violation in current Linux.  However, it reports violations for other three invariants. Fig. 4: Property violations

19. P2 Violation 19  The violation of P2 arises when kernel read- write data region is set as read-only.  static_protections() doesn’t check for the correctness of new access flags set for the kernel read-write data region.  Could cause a denial of service attack that immediately follows the call of set_pages_ro() for read-write data region.

20. P3 Violation 20  The first occurs when BIOS32 is mapped into the kernel space during the initialization directly. While BIOS is typically stored in ROM and should not be overwritten, Linux map it as writable and executable.

21. P3 Violation (2) 21 Fig. 5: Original 2.6.33 kernel page tables

22. P3 Violation (3) 22  The second scenario is related to the original memory management interface that allows for pages to be mapped as writable and executable at the same time.  The source of problem is the absence of any access permission verification system for memory pages outside the static kernel image in the default memory management interface, such as when a kernel module is being loaded.

23. P4 Violation 23  Violation of P4 happens when a page from low memory region is being mapped into vmalloc() area as executable.  A module loader could use vmalloc() to load all modules sections, including code with execute permissions while linear mapping space with RW+NX permission.

24. Agenda 24  About Code Injection  Murphi  Linux Kernel Memory Model  Analysis  Improvement and Prototype  Evaluation  Discussion and Related Work

25. Authors’ Work 25  Revise the memory management subsystem in Linux and admit five kernel patches. 4 of them are in the process of being integrated into mainline Linux kernel. 1 still being assessed.  There are two distinct levels of abstraction interfaces to manage Linux kernel memory. They choose high-level interface for performance consideration.

26. Fix P2 Violation 26  Preserving the “write” access on kernel read- write data.  Fix static_protections() to preserve the write access to read-write data (including BSS).  Fix try_preserve_large_pages() that incorrectly processes access permission change requests for area that start on a boundary of a large page, but area smaller than the page itself.

27. Fix P3 Violation 27  Removing mixed pages in kernel space.  For BIOS32 Implement a patch that dynamically maps BIOS32 services into the kernel space.  For Linux Kernel Module (LKM) The linker choose minimal amount space necessary between each module’s section. CONFIG_DEBUG_SET_MODULE_RONX

28. Fix P3 Violation (2) 28  For static kernel image Similar to LKM. Modify alignment in kernel/vmlinux.lds.S Assign proper access permissions to the pages of each group at the end of kernel initialization (mm/init.c).

29. Fix P4 Violation 29  Disallowing memory aliasing with permission conflicts.  Fix cpa_process_alias() to check alias when _X bit is set.  Implement a helper routine process_WxorX_violation() in mm/pageattr.c to enfore W ⊕ X property.

30. Agenda 30  About Code Injection  Murphi  Linux Kernel Memory Model  Analysis  Improvement and Prototype  Evaluation  Discussion and Related Work

31. Simple Modeling 31  A system that contains One virtual page of each type ▪ Kernel text ▪ Kernel read-only data ▪ Kernel read-write data ▪ Linear mapping Two pages in non-contiguous mapping  Model the physical memory with one more page frame than the total size of the virtual address space.  Model checker examined 27,942 states and 7,823,760 rules without detecting any violations.

32. Ubuntu Server 8.04.4 32 Fig. 6: Comparison of original and patched kernel

33. Ubuntu Server 8.04.4 33 Fig. 7: Comparison of original and patched kernel (2)

34. Performance 34  The first four patches don’t introduce any performance overhead as all works are mainly performed at compile time.  Only run time penalty is checking for alias. (In the helper routine process_WxorX_violation()) Fig. 8: Run time W ⊕ X enforcement overhead

35. Memory Overhead 35  Size of static kernel image increased from 6793KB to 6796KB, overhead = 0.04%. Fig. 7: Comparison of original and patched kernel (2)

36. Memory Overhead (2) 36  We also load 44 kernel modules of varying sizes and check the total size by lsmod command. Size increased from 1,265,502 B to 1,493,138 B. (22.01%)  If we can take the whole-page allocation into account, the memory overhead is increased from 322 pages (size of 4K) to 382 pages (an increase of 22.17%) CONFIG_DEBUG_SET_MODULE_RONX

37. Agenda 37  About Code Injection  Murphi  Linux Kernel Memory Model  Analysis  Improvement and Prototype  Evaluation  Discussion and Related Work

38. Discussion 38  We assumes that the static kernel image and LKMs are trusted, and follow the transition rules to manage the kernel memory. Kernel / driver signing  While providing W ⊕ X is helpful to block code injection attacks, W ⊕ X itself doesn’t prevent other types of attacks.  Our modeling is based on the correctness of the internal kernel APIs, any code inside the function that modifies page tables directly will not be prevented from doing so.  Few exceptions need to consider, e.g. ftrace.ftrace

39. Related Work 39  Model checking for improved security.  W ⊕ X enforcement Use custom hypervisor that needs special authentication mechanisms. ▪ Lead to significant performance degradation. We analyze the protection in the Linux kernel memory space while others mainly concentrate on userspace application protection.  ASLR, ISR

40. The End