Linux内核(x86)入口代码模糊测试指南Part 2 （上篇）

发布时间：2025-11-04 23:35:22 来源：创站工坊 作者：数据库

在本系列的入口第一篇文章中，我们介绍了Linux内核入口代码的代码作用，以及如何进行JIT汇编和调用系统调用。模糊在本文中，测试我们将为读者更进一步介绍标志寄存器、指南堆栈指针、上篇段寄存器、入口调试寄存器以及进入内核的代码不同方法。

更多标志（%rflags）

方向标志只是模糊我们众多感兴趣的标志之一。维基百科上关于%rflags的测试文章列出了我们感兴趣的其他一些标志：

· bit 8：陷阱标志（用于单步调试）

· bit 18：对齐检查

大多数与算术相关的标志（进位标志等）并不是我们感兴趣的对象，因为它们在普通代码的指南正常运行过程中变化较大，这意味着内核对这些标志的上篇处理很可能已经过了充分的测试。而另外一些标志（如中断启用标志）可能无法被用户空间修改，入口所以即使尝试也没什么用。代码

我们需要重点关注陷阱标志，模糊因为设置该标志后，CPU在每条指令后都会传递一个调试异常，自然也会干扰输入代码的正常运行。

对齐检查标志也应当重点关注，因为当一个错误对齐的云服务器提供商指针被解除引用时，它会使CPU传递一个对齐检查异常。虽然CPU在0环中执行时不应该执行对齐检查，但是检查是否存在因为对齐检查异常而进入内核的相关漏洞还是很有意思的（我们稍后再谈）。

维基百科的文章给出了修改这些标志的程序，但我们可以做得更好一点。

这段代码将%rflags的内容压入堆栈上，然后直接修改堆栈上的标志值，再将该值弹出到%rflags中。实际上，我们在这里可以选择使用orq或者xorq指令；我选择xorq，因为它可以切换寄存器中的任何值。这样一来，如果我们连续进行多次系统调用（或内核入口），我们可以随机切换标志，而不必关心现有的值是什么。

既然我们无论如何都要修改%rflags寄存器，那么我们不妨把方向标志的修改纳入进去，把三个标志的修改合并到一条指令中。免费信息发布网虽然这是一个很小的优化，但没有理由不这么做，最后的结果如下所示：

如果我们不希望进程在设置陷阱标志时立即被SIGTRAP杀死，我们需要注册一个信号处理程序来有效地忽略这个信号（显然使用SIG_IGN是不够的）：

关于上面的SA_ONSTACK标志，我们将在下一节讨论。

堆栈指针（%rsp）

在修改%rflags之后，我们其实就不需使用堆栈了，这意味着我们可以在不影响程序执行的情况下，自由地更改栈指针。不过我们为什么要修改栈指针呢？内核又不会用我们的用户空间栈来做任何事情，对吧？事实上，它可能会。

像ftrace和perf这样的调试工具偶尔会在系统调用跟踪期间取消对用户空间堆栈的引用。事实上，我在这方面至少发现了两个不同的漏洞：

· report 1 (July 16, 2019),

· report 2 (May 10, 2020).

当向用户空间传递信号时，信号处理程序的堆栈帧由内核创建，通常位于被中断线程的当前堆栈指针的上方。

如果由于某些错误，%rsp会被内核直接访问，b2b信息网那么在正常操作期间可能不会被注意到，因为堆栈指针通常总是指向一个有效地址。要捕捉这种漏洞，我们可以简单地将其指向一个非映射地址（甚至是内核地址！）。

为了帮助我们测试堆栈指针的各种可能感兴趣的值，我们可以定义一个helper：

在这里，我使用了自己机器上的/proc/kallsyms中找到的一些内核指针。它们不一定是很好的选择，只是用于演示。正如我前面所提到的，我们需要找到一个平衡点，既要选择那些疯狂到没有人想过要处理它们的值（我们毕竟在这里试图寻找的是边缘案例），又要不迷失在巨大的非目标值的海洋中；我们可以统一选择随机的64位值，但这很难带来任何有效的指针（其中大部分可能是非规范的地址）。模糊测试的部分艺术是通过对哪些有可能和哪些不可能的关系进行有根据的猜测来抽出相关的边缘案例。

现在只是设置值的问题，幸运的是，我们可以直接将64位的值加载到%rsp中：

可以使用下列代码：

但是，对于上面提到的%rflags来说，有一点需要引起我们的高度注意：一旦我们在%rflags中启用了单步标志，CPU就会在随后执行的每条指令中传递一个调试异常。内核将通过向进程传递一个SIGTRAP信号来处理调试异常。默认情况下，这个信号是通过堆栈传递的，而堆栈上的值就是%rsp的值……如果%rsp无效，内核会用一个不可触发的SIGSEGV来杀死进程。

为了处理这样的情况，内核提供了一个函数，以便在传递信号时将%rsp设置为一个已知的有效值：sigaltstack()。我们要做的就是像下面这样来调用它：

然后，将SA_ONSTACK传递给处理SIGTRAP的sigaction()调用的sa_flags变量中。

段寄存器

说到段寄存器，你会经常看到这样的说法：其实在64位上已经不太有用了。然而，这并不是全部的事实。的确，你不能改变基地址或段大小，但几乎所有其他的东西都还是相关的。特别是一些与我们相关的东西，例如：

· %cs、%ds、%es和%ss必须含有有效的16位段选择器，指向GDT（全局描述符表）或LDT（局部描述符表）中的有效条目。

· %cs不能使用mov指令加载，但我们可以使用ljmp（远/长跳转）指令。

· %cs的CPL（当前权限级别）字段是CPU正在执行的权限级别。通常情况下，64位用户空间进程运行的%cs为0x33，即GDT的索引6，特权级别为3，内核运行的%cs为0x10，即GDT的索引2，特权级别为0（因此称为ring 0）。

· 实际上我们可以使用modify_ldt()系统调用在LDT中安装条目，但要注意的是，内核会对条目进行消毒，所以我们不能创建一个指向DPL 0的段的调用门。

· %fs和%gs的基地址是由MSRs指定的。这些寄存器通常分别用于用户空间进程和内核的TLS（线程本地存储）和per-CPU数据。我们可以使用arch_prctl()系统调用来改变这些寄存器的值。在某些CPU/内核上，我们可以使用wrfsbase和wrgsbase指令。

· 使用mov或pop指令设置%ss会使CPU在mov或pop指令之后的一条指令中屏蔽中断、NMI、断点和单步陷阱。如果下一条指令导致进入内核，这些中断、NMI、断点或单步陷阱将在CPU开始在内核空间执行后生效。这就是CVE-2018-8897的来源，内核没有正确处理这种情况。

LDT

由于我们可能会从LDT中加载段寄存器，所以不妨从设置LDT开始入手。由于modify_ldt()没有glibc封装器，所以我们必须使用syscall()函数来调用它：

我们可能要检查这里的返回值；我们不应该生成无效的LDT条目，所以知道我们是否存在这种条目是很有用的。

数据段（%ds）

下面展示如何使用数据段：

%fs与 %gs

对于％fs和％gs，我们需要使用系统调用arch_prctl()。在普通（非JIT汇编）代码中，可以这样使用：

不幸的是，这样做很有可能导致glibc/libstdc++在任何使用线程本地存储的代码上崩溃（甚至在第二次get_random_address()调用时就可能发生）。如果我们想生成系统调用来做这件事，我们可以通过支持代码进行协助：

需要注意的是，除了需要一些寄存器来执行系统调用本身之外，syscall指令还用返回地址（即syscall指令后的指令地址）覆盖%rcx，所以我们可能要在做其他事情之前进行这些调用。

小结

在本文中，我们为读者更进一步介绍了各种标志寄存器、堆栈指针以及部分段寄存器，在下一篇文章中，我们将为读者介绍调试寄存器以及进入内核的不同方法。

本文翻译自：https://blogs.oracle.com/linux/fuzzing-the-linux-kernel-x86-entry-code%2c-part-2-of-3如若转载，请注明原文地址

相关文章