VX Heavens

Since a few years we have seen a lot of rootkits using loadable kernel modules. Is this a fashion ? not really, lkm's are widely used because they are powerfull: you can hide files, processes and do other nice things. The first rootkits using lkm's could be easily detected because they where listed when issuing a lsmod. We have seen lots of techniques to hide modules, like the one used in Plaguez's paper [1] or the more tricky used in the Adore Rootkit [2]. A few years later we have seen other techniques based on the modification of the kernel memory image using /dev/kmem [3]. Finally, a technique of static kernel patching was presented to us in [4]. This one solves an important problem: the rootkit will be reloaded after a reboot.The goal of this paper is to describe a new technique used to hide lkm's and to ensure us that they will be reloaded after a reboot. We are going to see how to do this by infecting a kernel module used by the system. We will focus on Linux kernel x86 2.4.x series but this technique can be applied to other operating systems that use the ELF format. Some knowledge is necessary to understand this technique. Kernel modules are ELF object files, we will thus study the ELF format focusing on some particular parts related to the symbol naming in an ELF object file. After that, we will study the mechanisms wich are used to load a module to give us some knowledge on the technique which will permit to inject code into a kernel module. Finally, we will see how we can inject a module into another one in real life.

Kernel rootkits have posed serious security threats due to their stealthy manner. To hide their presence and activities, many rootkits hijack control flows by modifying control data or hooks in the kernel space. A critical step towards eliminating rootkits is to protect such hooks from being hijacked. However, it remains a challenge because there exist a large number of widely-scattered kernel hooks and many of them could be dynamically allocated from kernel heap and co-located together with other kernel data. In addition, there is a lack of flexible commodity hardware support, leading to the so-called protection granularity gap - kernel hook protection requires byte-level granularity but commodity hardware only provides page-level protection.To address the above challenges, in this paper, we present HookSafe, a hypervisor-based lightweight system that can protect thousands of kernel hooks in a guest OS from being hijacked. One key observation behind our approach is that a kernel hook, once initialized, may be frequently "read"-accessed, but rarely "write"-accessed. As such, we can relocate those kernel hooks to a dedicated page-aligned memory space and then regulate accesses to them with hardware-based page-level protection. We have developed a prototype of HookSafe and used it to protect more than 5, 900 kernel hooks in a Linux guest. Our experiments with nine real-world rootkits show that HookSafe can effectively defeat their attempts to hijack kernel hooks. We also show that HookSafe achieves such a large-scale protection with a small overhead (e.g., around 6% slowdown in performance benchmarks).