如何针对 Linux KVM 编写模糊测试？
情况应该是，当 Linux 内核是主机内核时，它不应受到虚拟机内来宾内核执行的内容的不利影响。
我想通过模糊从来宾内核到主机内核的接口来测试该属性。在我看来，很明显测试需要在来宾内核（例如，在内核模块中）内运行，生成任意代码，然后执行该代码。如果主机内核崩溃（或做了一些“有趣的”事情），测试就会失败。
所以，我的问题是：
- 你知道有什么测试已经实现了这一点吗？
- 是否存在我需要避免的预计会导致主机内核崩溃的指令？
- 在 Linux 内核中生成垃圾的最佳方法是什么？
- 一旦生成了垃圾，我该如何执行它？
目前，我只想关注一般的模糊测试方法。稍后，在我完成此测试后，我将对其进行更改，以对内核中的不同虚拟化指令和驱动程序进行模糊测试。
更新：进一步考虑之后，用完全垃圾进行模糊测试是行不通的，因为我的客户机器崩溃的频率比我预期的主机崩溃的频率要高。所以，我认为我需要从一开始就采取外科手术的方式来解决这个问题。有什么建议吗？
It should be the case that the Linux kernel, when it is a host kernel, should not be adversely affected by what a guest kernel executes inside a virtual machine.
I'd like to test that property by fuzzing the interface from the guest kernel to the host kernel. It seems clear to me that the test needs to run inside the guest kernel (say, in a kernel module), generate arbitrary code, and then execute that code. The test fails if the host kernel crashes (or does something "interesting").
So, my questions are:
- Do you know of any tests that already accomplish this?
- Are there instructions that are expected to crash the host kernel that I need to avoid?
- What is the best way to generate garbage inside the Linux kernel?
- Once I've generated the garbage, how do I execute it?
For the time being, I'd like to just focus on the general fuzzing approach. Later on after I get this test working, I'll change it to surgically fuzz different virtualized instructions and drivers in the kernel.
Update: After thinking about it further, fuzzing with complete garbage isn't going to work since I'll be crashing my guest machine way more often than I expect to be crashing my host. So, I think I need to approach this surgically from the start. Any advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在很大程度上，发现严重的 0day 就是编写富有想象力的测试。当您构建测试系统时，您需要识别其攻击面。在 Web 应用程序中，这很简单，即 GET/POST 请求。对于像虚拟机这样的东西，它更复杂。提供给您的实际硬件是 KVM 创建的幻象。在某些时候，与该设备的数据交互将由主机处理。
其他重要资源是寻找目标中已发现的漏洞。程序员常常会犯非常相似的错误，并且类似的错误也很常见。 这些 CVE：CVE-2010-0297 CVE-2010 -0298 CVE-2010-0306 CVE-2010-0309，是 LInux 漏洞的一个很好的例子KVM。 CPU 和 USB 是两个突出的硬件设备，它们都受到了损害。
Peach 是一个非常强大的模糊测试平台。许多测试可以单独使用 XML 创建，尽管如果您了解 python，则可以扩展 peach 来执行任何操作。
To a large extent finding serous 0-days is about writing imaginative tests. When you are building a test a system you need to identify its attack surface. In web applications this is easy, GET/POST requests. For something like a VM, its more complex. The actual hardware provided to you, is an illusion created by the KVM. At some point this data interaction with this device will be processed by the host.
Other important resource is looking for vulnerabilities that have already been found in your target. Often times programmers make very similar mistakes, and similar bugs are very common. These CVE's: CVE-2010-0297 CVE-2010-0298 CVE-2010-0306 CVE-2010-0309, are a good examples of vulnerabilities LInux's KVM. Two hardware devices that stick out are the CPU and USB, which where both compromised.
A very powerful fuzzing platform is Peach. Many tests can be created using XML alone, although if you know python you can extend peach to do anything.
虽然模糊设备驱动程序通常很高效，但其中大多数不是由 KVM 模拟的，而是由用户空间组件模拟的。 USB 驱动程序，正如之前的答案所举的例子，完全由 QEMU 模拟。虽然资助模拟 EHCI 驱动程序中的漏洞固然很棒，但它不会是 KVM 漏洞，并且不允许您开发内核漏洞。有一些驱动程序是在 KVM 中模拟的，例如某些 PIC 定时器（例如 i8254 和 i8259），但大多数都保留在用户空间中。
KVM 模拟的另一件事是某些指令。您可以通过模糊这些特定指令来模糊 KVM。阅读 KVM 源代码，了解哪些是最复杂的，以及如何触发最复杂或最敏感的行为。在较旧的 CPU 架构上，CPU 无法向 guest 虚拟机提供实模式执行 (unrestricted_guest=1)，甚至会模拟更多指令。
特别是在利用指令仿真时，通常会涉及竞争条件。
While fuzzing device drivers is often productive, most of those are not emulated by KVM, but by a userspace component. USB drivers, as the previous answer gave as an example, are emulated entirely by QEMU. While funding a vulnerability in the emulated EHCI driver would be fantastic, it would not be a KVM vulnerability, and it would not allow you to develop a kernel exploit. There are a few drivers which are emulated in KVM, such as certain PIC timers (e.g. i8254 and i8259), but the majority are kept in userspace.
Another thing which KVM emulates are certain instructions. You could fuzz KVM by fuzzing these specific instructions. Read the KVM source to see which are the most complex, and how to trigger the most complex or sensitive behavior. On older CPU architectures where the CPU cannot provide real mode execution to the guest (unrestricted_guest=1), even more instructions are emulated.
Especially when it comes to exploiting instruction emulation, race conditions can often be involved.