Return-Oriented Rootkits: Bypassing Kernel Code Integrity Protection Mechanisms Ralf Hund Thorsten Holz Felix C. Freiling Laboratory for Dependable Distributed Systems University of Mannheim, Germany [email protected], fholz,[email protected] Abstract In recent years, several mechanism to protect the in- tegrity of the kernel were introduced [6, 9, 15, 19, 22], Protecting the kernel of an operating system against at- as we now explain. The main idea behind all of these tacks, especially injection of malicious code, is an impor- approaches is that the memory of the kernel should be tant factor for implementing secure operating systems. protected against unauthorized injection of code, such as Several kernel integrity protection mechanism were pro- rootkits. Note that we focus in this work on kernel in- posed recently that all have a particular shortcoming: tegrity protection mechanisms and not on control-flow They cannot protect against attacks in which the attacker integrity [1, 7, 14, 18] or data-flow integrity [5] mech- re-uses existing code within the kernel to perform mali- anisms, which are orthogonal to the techniques we de- cious computations. In this paper, we present the design scribe in the following. and implementation of a system that fully automates the process of constructing instruction sequences that can be 1.1 Kernel Integrity Protection Mecha- used by an attacker for malicious computations. We eval- uate the system on different commodity operating sys- nisms tems and show the portability and universality of our Kernel Module Signing. Kernel module signing is a approach. Finally, we describe the implementation of a simple approach to achieve kernel code integrity. When practical attack that can bypass existing kernel integrity kernel module signing is enabled, every kernel module protection mechanisms. should contain an embedded, valid digital signature that can be checked against a trusted root certification author- ity (CA). If this check fails, loading of the code fails, too. 1 Introduction This technique has been implemented most notably for Windows operating systems since XP [15] and is used in Motivation. Since it is hard to prevent users from run- every new Windows system. ning arbitrary programs within their own account, all Kernel module signing allows to establish basic secu- modern operating systems implement protection con- rity guidelines that have to be followed by kernel code cepts that protect the realm of one user from another. software developers. But the security of the approach Furthermore, it is necessary to protect the kernel itself rests on the assumption that the already loaded kernel from attacks. The basis for such mechanisms is usu- code, i.e., the kernel and all of its modules, does not ally called reference monitor [2]. A reference monitor have a vulnerability which allows for execution of un- controls all accesses to system resources and only grants signed kernel code. It is thus insufficient to check for them if they are allowed. While reference monitors are kernel code integrity only upon loading. an integral part of any of today’s mainstream operating systems, they are of limited use: because of the sheer W⊕X. W⊕X is a general approach which aims at pre- size of a mainstream kernel, the probability that some venting the exploitation of software vulnerabilities at system call, kernel driver or kernel module contains a runtime. The idea is to prevent execution of injected vulnerability rises. Such vulnerabilities can be exploited code by enforcing the W⊕X property on all, or certain, to subvert the operating system in arbitrary ways, giv- page tables of the virtual address space: A memory page ing rise to so called rootkits, malicious software running must never be writable and executable at the same time. without the user’s notice. Since injected code execution always implies previous instruction writes in memory, the integrity of the code versary may compromise arbitrary system entities, e.g., can be guaranteed. The W⊕X technique first appeared in files, processes, etc., as long as the compromise happens OpenBSD 3.3; similar implementations are available for only inside the VM. other operating systems, including the PaX [28] and Exec Shield patches for Linux, and PaX for NetBSD. Data Ex- ecution Prevention (DEP) [16] is a technology from Mi- SecVisor. SecVisor [22] is a software solution that con- crosoft that relies on W⊕X for preventing exploitation of sist of a general, operating system independent approach software vulnerabilities and has been implemented since to enforce W⊕X based on a hypervisor and memory vir- Windows XP Service Pack 2 and Windows Server 2003. tualization. In the threat model for SecVisor an attacker The effectiveness of W⊕X relies on the assumption can control everything but the CPU, the memory con- that the attacker wishes to modify and execute code in troller, and kernel memory. Furthermore, an attacker kernel space. In practice, however, an attacker usually can have the knowledge of kernel exploits, i.e., she can first gains userspace access which implies the possibil- exploit a vulnerability in kernel mode. In this setting, ity to alter page-wise permission in the userspace por- SecVisor “protects the kernel against code injection at- tion of the virtual address space. Due to the fact that tacks such as kernel rootkits” [22]. This is achieved by the no-executable bit in the page-table is not fine-grained implementing a hypervisor that restricts what code can enough, it is not possible to mark a memory page to be be executed by a (modified) Linux kernel. The hyper- executably only in user mode. So an attacker may simply visor virtualizes the physical memory and the MMU to prepare her instructions in userspace and let the vulnera- set page-table-based memory protections. Furthermore, ble code jump there. SecVisor verifies certain properties on kernel mode en- try and exit, e.g., all kernel mode exits set the privilege NICKLE. NICKLE [19] is a system which allows for level of the CPU to that of user mode or the instruction lifetime kernel code integrity, and thus rootkit preven- pointer points to approved code at kernel entry. Franklin tion, by exploiting a technology called memory shadow- et al. showed that these properties are prone to attacks ing. NICKLE is implemented as virtual machine moni- and successfully injected code in a SecVisor-protected tor (VMM) which maintains a separate so-called shadow Linux kernel [8], but afterwards also corrected the errors memory. The shadow memory is not accessible from found. within the VM guest and contains copies of certain por- tions of the VM guest’s main memory. Newly executing code, i.e., code that is executed for the first time, is au- 1.2 Bypassing Integrity Protection Mecha- thenticated using a simple cryptographic hash value com- nisms parison and then copied to the shadow memory trans- parently by NICKLE. Since the VMM is trusted in this Based on earlier programming techniques like return-to- model, it is guaranteed that no unauthenticated modifica- libc [17, 21, 27], Shacham [23] introduced the technique tions to the shadow memory can be applied as executing of return-oriented programming. This technique allows guest code can never access the privileged shadow mem- to execute arbitrary programs in privileged mode with- ory. Therefore, any attempt to execute unauthenticated out adding code to the kernel. Roughly speaking, it mis- code can be foiled in the first place. Another positive uses the system stack to “re-use” existing code fragments aspect of this approach is that it can be implemented in (called gadgets) of the kernel (we explain this technique a rather generic fashion, meaning that it is perfectly ap- in more detail in Section 2). Shacham analyzed the GNU plicable to both open source and commodity operating Linux libc of Fedora Core 4 on an Intel x86 machine systems. Of course, NICKLE itself has to make certain and showed that executing one malicious instruction in assumptions about underlying file format of executable system mode is sufficient to construct arbitrary computa- code, e.g., driver files, since it needs to understand the tions from existing code. No malicious code is needed, loading of these files. Currently, NICKLE supports Win- so most of the integrity protection mechanisms fail to dows 2000, Windows XP, as well as Linux 2.4 and 2.6 stop this kind of attack. based kernels. So far, NICKLE has been implemented Buchanan et al. [4] recently extended the approach to for QEMU, VMware, and VirtualBox hypervisors. The the Sparc architecture. They investigated the Solaris 10 QEMU source code is publicly available [20]. C library, extracted code gadgets and wrote a compiler The isolation of the VMM from the VM Guest allows that can produce Sparc machine programs that are made for a comparably unrestrictive threat model. In the given up entirely of the code from the identified gadgets. They system, an attacker may have gained the highest level of concluded that it is not sufficient to prevent introduction privilege within the VM guest and may access the en- of malicious code; we must rather prevent introduction tire memory space of the VM. In other words, an ad- of malicious computations. 2 Attacker Model. Like the mentioned literature, we 2 Background: Return-Oriented Pro- base our work on the following reasonable attacker gramming model. We assume that the attacker has full access to the user’s address space in normal mode (local attacker) and that there exists at least one vulnerability within a system call such that it is possible to point the control The idea behind a return-to-libc attack [17, 27] is that the flow to an address of the attacker’s choice at least once attacker can use a buffer overflow to overwrite the return while being in privileged mode.