Untitled

Abstract

The abundance of memory corruption and disclosure vulnerabilities in kernel code necessitates the deployment of hardening techniques to prevent privilege escalation attacks. As stricter memory isolation mechanisms between the kernel and user space become commonplace, attackers increasingly rely on code reuse techniques to exploit kernel vulnerabilities. Contrary to similar attacks in more restrictive settings, as in web browsers, in kernel exploitation, non-privileged local adversaries have great flexibility in abusing memory disclosure vulnerabilities to dynamically discover, or infer, the location of code snippets in order to construct code-reuse payloads. Recent studies have shown that the coupling of code diversification with the enforcement of a "read XOR execute" (R ∧ X) memory safety policy is an effective defense against the exploitation of userland software, but so far this approach has not been applied for the protection of the kernel itself.In this article, we fill this gap by presenting kR ∧ X: a kernel-hardening scheme based on execute-only memory and code diversification. We study a previously unexplored point in the design space, where a hypervisor or a super-privileged component is not required. Implemented mostly as a set of GCC plugins, kR ∧ X is readily applicable to x86 Linux kernels (both 32b and 64b) and can benefit from hardware support (segmentation on x86, MPX on x86-64) to optimize performance. In full protection mode, kR ∧ X incurs a low runtime overhead of 4.04%, which drops to 2.32% when MPX is available, and 1.32% when memory segmentation is in use. 5:2M. Pomonis et al. INTRODUCTIONThe deployment of standard kernel-hardening schemes, such as address space layout randomization (KASLR) [50] and non-executable memory [91], has prompted a shift from legacy code injection (in kernel space) to return-to-user (ret2usr) attacks [80]. Due to the weak separation between kernel and user space-as a result of the kernel being mapped inside the (upper part of the) address space of every user process for performance reasons-in ret2usr attacks, the kernel control/dataflow is hijacked and redirected to code/data residing in user space, effectively bypassing KASLR and (kernel-space) W ∧ X. Fortunately, however, recent software [38,69,80,116] and hardware [35,77] kernel protection mechanisms mitigate ret2usr threats by enforcing a more stringent address space separation. Alas, mirroring the co-evolution of attacks and defenses in user space, kernel exploits have started to rely on code-reuse techniques, such as return-oriented programming (ROP) [134,144]; old ret2usr exploits [14] are converted to use ROP payloads instead of shellcode [18], while modern jailbreak and privilege escalation exploits rely solely on code reuse [2,129,152].At the same time, the security community started developing protections against code-reuse attacks: control-flow integrity (CFI) [7] and code-diversification [44,72,87,112,149] schemes have been applied both in the user and kernel settings [42,58,64,94]. Unfortunately, the...