CSS09-Countering Kernel Rootkits with Lightw

摘要
Kernel rootkit通过修改控制数据或者内核中的钩子而劫持控制流，从而隐藏自己的存在。因此保护这些钩子函数成为一个关键问题（引出出问题了）。但是有许多从内核堆中动态分配的钩子，并且与其它内核数据混在一起，这造成了很多难度。另外，缺少灵活的商业硬件支持，造成了所谓的保护粒度沟（内核钩子的保护要求byte级别的粒度，但是商业硬件只支持页级别的保护）。
为解决这些问题，本文提出了HookSafe的概念，基于hypervisor的轻量级的系统，可以保护guestOS中几千个内核钩子免遭劫持。我们方法的一个关键点是我们观察到一个内核钩子，一旦初始化，可能会频繁的进行读访问，但极少进行写访问。这样，我们可以分配这些内核钩子到一个专用的页对齐的内存空间，然后使用基于页面的保护管理对钩子的访问。我们开发了一个HookSafe的原型并用其保护了geustlinux的5900多个内核钩子。而使用了9个rootkit的实验证明了HookSafe可以有效的抵御内核钩子劫持，并且开销很小（只有6%的性能下降怎么算出来的……）。

Introduction
之前对于rootkit的防御的研究可以粗略分拆成3类：
1. 例如Panorama，HookFinder，K-Tracer和PokeR等重点分析rootkit行为。
2. 通过检测rootkit感染后特定症状来监控rootkit的工具，如Coilot，SBCFI，VMwatchter等。
3. SecVisor，Patagonix和NICKLE等通过组织恶意rootkit代码的执行来保持内核代码的完整性，但这种防御可以通过return-oriented的rootkit【11】来绕过：首先修改内核控制流（如劫持函数指针或者返回堆栈的地址），然后发动攻击。

从上面可以看出，除了保护内核代码的完整性，保护相关内核控制数据以保证内核控制流的完整性也是很重要的。
本文中，如果内核数据在kernel的执行过程中的某个点被装入了PC寄存器，那么该内核数据就被当做控制数据。
有两种主要的内核控制数据：返回地址和函数指针
返回地址的研究已经很多，而我们的工作主要集中于保护函数指针
在本文中 function pointers = kernel hook

之前的方法：
为保护kernel hook，一个直觉上的方法是利用硬件的页面保护机制，任何的对于包含kernel hook的写指令都会被监控。这个方法，如果只有很少的kernel hook并且这些hook都没有跟经常修改的内存数据位于一起，可以工作的很好。但在Linux或Windows中，存在着几千个hook，并且这些kernel hook分布在整个内核空间。而且许多kernel hook可能从内核堆中动态分配，并跟其他的可写入的内核数据位于同一个物理内存页面上。因此上面的方法不可行。

本文的方法：
基于hypervisor，我们提出一个基本的challenge，命名为protection granularity gap，硬件提供页面级别的保护，而我们需要的是byte级别的粒度。为解决这个challenge，我们观察到，kernel hooks，一旦初始化，基本上不会再改变它的值。这启发了我们将kernel hooks放到一个指定的页对齐的内存中，引入一个很薄的hook indirection 层次，来管理对所有的hook的访问通过物理的页面保护机制。

Problem Overview
rootkit分为KOH和DKOM两类，96%的KOH：劫持kernel的控制流通过劫持代码hook或者数据hook【31，32】。Code hook是文本段，比较方便保护。Kernel data hook通常都是函数指针，存放于两个内存区域中，一个是动态分配的内存区域如内核的堆，另一个是预先分配的内存区包括数据段，bss段和内核引导区中。HookSafe保护这两块内存区域

使用QEMU分析了Ubuntu8.04，证明了protection granularity gap的存在。找到5881个kernel hook，分布在41个物理页面上。并统计了内存页面写的次数与触发hook写的次数的比率。结果为1%

本文中假设系统有一个可信根，例如tboot（信任链？）。使用这个可信根，可以安全的装入hypervisor，确保guest系统的完整性。同时假设运行时hypervisor也是完整的。本文不考虑对于hypervisor的攻击，如SMM【14】等。

HookSafe Design
为提高性能，对hook的读和写的操作分开对待，以提高性能，读操作在guestOS内部完成，减少了一次内存拷贝。

整个hooksafe分为两步：离线统计和在线检查
1. Offline hook profiling为每一个受保护的hook找到HAP集合（HAP就是访问kernel hook的哪些指令），使用了QEMU。受保护的hook集合通过对两个内存区的如何扫描得到：每4byte检查一次，如果只想某个内核函数的首地址，则认为是一个hook
2. Online Hook protection：

2.  Online Hook protection ：

3.

a.  启动：为受保护的 kernel hook 分配空的内存区，将 kernel hooks 从原来的位置拷贝到新的区域吧（原来的代码还要保留，以方便代码的返回，相当于多使用了一块内存）。 HAP 要绕过原来的位置，转到新的 shadow memory copy 中

b.  运行时读写的拦截：为校验写数据的合法性，要求写入的值必须在采样过程中出现过（可见采样过程需要大量的数据）

c.  运行时对动态分配的 hook 的跟踪：动态的 hook 基本上都位于动态分配的内核对象中，而内核对象的分配时使用 slab 来进行的，只要监控对 slab 的分配和 free 就好。另外一个 challenge 是在 HookSafe 运行前，就已经有对象动态分配了，但是任何动态分配的 object 都必须能以某种方式进行访问，这样来跟踪已经分配的 object 。

d.  硬件寄存器的保护：保护 GDT 和 LDT ，以及 DMA

实现：

1.  Offline Hook Profiler ：标记，监控访问 hook 的指令并记录其值，利用了 QEMU 的二进制翻译技术，添加了自己的监控代码。

2.  Hook 转向：替换找到的 HAP 指令，用 jmp 指令来代替。在 shadow memory 中处理完后，跳转回去原来的指令流执行。

a.  指令的替换有些问题（ X86 的指令长度是不定的）： jmp 指令取 5byte 的长度，但原来的指令可能大于 5byte ，也可能小于 5byte ，这样不能直接在原指令中进行替换进行跳转（可能会覆盖后面的指令，而后面调回来执行需要后面的指令），采用了这样一种方式：将原来的函数转化成的二进制指令代码拷贝一份新的并在新的上面修改，而原指令开头部分也修改一下，指向新指令的起始位置，这样不会对原来的指令造成破坏。

3.  运行时 LKM 和 Hook 的跟踪

监控两个 slab 分配函数。在这两个函数返回前，看分配的 slab 是不是指定的对象。

challenge ：如何精确定位 hooks 的地址。

解决： hooks 在 LKM 中的相对偏移量是固定的，只要找到 LKM 的 base address 就好。问获得 LKM 的基地址，利用了 virtual machine introspection 【 10 ， 23 ， 26 】技术。

4.  内存保护

5.  系统调用转向优化

DISCUSSION

这种方法的采样集的获得是最大的问题，如何得到完整的采样集

可以与目前的静态方法相结合

相关工作

1.  Kernel rootkit prevention ： SecVisor 【 26 】使用硬件方法保护代码完整性。 Patagonix 也利用 hypervisor 检测二进制指令。 Lares 是跟本文最相关的工作。

2.  Kernel Rootkit Dection ：检测 rootkit 是否出现

3.  Kernel Rootkit Analysis ：采样 rootkit 的行为模式

CSS09-Countering Kernel Rootkits with Lightweight Hook Protection

更多文章、技术交流、商务合作、联系博主

微信扫码或搜索：z360901061

微信扫一扫加我为好友

QQ号联系： 360901061

您的支持是博主写作最大的动力，如果您喜欢我的文章，感觉我的文章对您有帮助，请用微信扫描下面二维码支持博主2元、5元、10元、20元等您想捐的金额吧，狠狠点击下面给点支持吧，站长非常感激您！手机微信长按不能支付解决办法：请将微信支付二维码保存到相册，切换到微信，然后点击微信右上角扫一扫功能，选择支付二维码完成支付。

【本文对您有帮助就好】元

2元

5元

10元

20元

自定义