Drifuzz:从金种子中收获设备驱动程序中的漏洞
摘要:
现代计算机中的外围硬件通常被认为是安全的且不带恶意,并且设备驱动程序以信任从硬件输入的方式实现。然而,最近的漏洞攻击(如Broadpwn)已经证明攻击者可以通过易受攻击的外围设备利用主机,凸显了保护操作系统和外围边界的重要性。在本文中,我们提出了一种无需硬件的共模增强模糊测试器,针对WiFi和以太网驱动程序,并提出了一种生成高质量初始种子(称为黄金种子)的技术,在驱动程序初始化期间允许模糊测试绕过困难的代码结构。与使用符号执行或灰盒模糊测试的先前工作相比,Drifuzz 更成功地自动找到允许网络接口完全初始化的输入,并且在 WiFi 驱动程序中提高了 214%(3.1 倍)的模糊测试覆盖率,在以太网驱动程序中提高了 60%(1.6 倍)。在我们对十四个 PCI 和 USB 网络驱动程序进行实验时,发现了十二个以前未知的错误,其中两个已被指定为 CVE。
Broadpwn:
Broadpwn是一种针对Broadcom Wi-Fi芯片的漏洞攻击,它可以通过Wi-Fi信号远程控制设备并在没有用户交互的情况下执行恶意代码。这个漏洞影响了许多智能手机、平板电脑和其他移动设备,因为它们使用Broadcom Wi-Fi芯片组件。该漏洞由安全研究人员在2017年发现,并被认为是一个非常严重的安全威胁。
CVE:
CVE是常见漏洞和披露(Common Vulnerabilities and Exposures)的缩写,是由MITRE公司维护的一个公共漏洞标识符号系统。该系统为已知漏洞分配唯一的标识符,以便更容易地进行跟踪、共享和检索有关漏洞的信息。每个CVE标识符都包括漏洞的描述、影响范围、解决方案等详细信息,这些信息可以帮助安全研究人员、厂商和用户更好地理解和应对这些漏洞。CVE标识符还被广泛用于安全评估、漏洞报告和其他安全相关活动。
一、简介
1.起因
通常我们认为内置的外围设备(如PCI设备)是可信的,设备驱动程序也是基于此而实现的,
2.存在的问题
1)已存在的问题
现代外围设备是具有自己固件和漏洞的复杂设备。如果外围设备的固件受到攻击,则可以利用该设备对主操作系统发动攻击并控制整个系统。WiFi(链接)和蓝牙适配器(链接)中的最近漏洞强调了通过设备驱动程序中的漏洞远程攻击宿主机的可能性。此外,即使在未发现外围设备固件漏洞的情况下,拥有物理访问权限的攻击者也可以执行“恶意女佣”攻击,即连接一个将自己标识为支持的外围设备的恶意设备,然后利用该设备中的漏洞。
2)已有的研究
设备驱动程序有两个主要安全边界:用户空间-操作系统边界和操作系统-外围边界。许多设备驱动程序安全相关工作聚焦于前者,即测试ioctl系统调用。虽然一些先前的工作研究了底层的操作系统-外围边界,但这方面的研究总体上还不充分。后者由硬件相关输入组成,包括端口I/O、内存映射I/O(MMIO)、直接内存访问(DMA)和中断。MMIO用于访问单个硬件寄存器,而DMA用于批量传输。最后,硬件中断会导致CPU停止,并将控制权转移到设备驱动程序中的中断处理程序中。测试设备驱动程序的一个主要挑战是外围设备的多样性。一些先前的工作假定每个要测试的驱动程序都有实际的外围设备存在,但这样的方法难以扩展(因为需要多个物理设备以便并行模糊测试),并且可能很昂贵(因为必须获取目标硬件;对于旧驱动程序,获得真正的硬件甚至可能是不可行的)。
3本文的尝试
1)可能的方案
一种替代方案是在模拟环境(如QEMU)中测试驱动程序。模拟器不需要任何专门的硬件,只需启动模拟器的更多副本即可扩展测试。
2)存在的问题
除了QEMU相对较小的外围设备集合外,测试设备驱动程序还需要一些对应外围设备预期行为的了解。例如,在初始化期间,许多设备驱动程序会探测识别和状态寄存器的值,并且如果返回的值与预期值不同,则会将该设备视为损坏或不支持。这种重要路径上的检查失败会导致立即终止,使得更深层次的驱动程序代码无法被测试到,而其中可能存在更深的漏洞。
3)问题带来的挑战
这个问题加剧了代码模式,例如驱动程序代码中的魔数检查和轮询循环,这些模式构成了传统模糊测试技术所面临的障碍,因为它们生成的随机值无法通过这些检查。我们认为这些障碍是阻塞分支,在设备驱动程序中普遍存在。
魔数检查:
一种检查文件格式的技术。在计算机科学中,不同的文件格式可能有不同的“魔数”(magic number)或“幻数”(magic value),用于唯一标识该文件格式。通过比对文件开头处的魔数与已知文件格式的魔数是否匹配,可以确定该文件的类型和格式,从而采取相应的处理方式。这个过程就被称为“magic value checks”。这种技术常用于各种工具,如文件压缩、文件转换和文件分析软件等。
轮询循环:
是一种在计算机编程中常用的技术,用于检查某些事件是否已经发生。这种技术通常在需要等待某个操作完成或某个条件满足时使用。具体来说,polling loop是一个无限循环,它不断地运行并检查某个变量或者状态,以确定某个条件是否已经满足。如果该条件已经满足,则跳出循环并执行相应的操作;否则,继续等待并检查该条件是否被满足。
模糊测试技术:
模糊测试(Fuzz Testing)是一种软件测试技术,它用于发现应用程序或系统中的安全漏洞、性能问题和其他异常行为。模糊测试技术通过输入各种随机、无效、异常的数据来检测程序的稳定性和鲁棒性。这些输入可能包括错误的命令参数、过长或过短的字符串、格式不正确的数据等。模糊测试旨在测试目标应用程序的边界条件和错误处理功能,以评估其对非预期输入的响应能力。模糊测试技术可以帮助开发人员和测试人员发现软件中的潜在问题,并帮助他们改进软件的质量和可靠性。模糊测试已被广泛应用于许多行业,包括计算机安全、网络协议、工控系统等。
4)解决方案
虽然驱动程序初始化失败的方式有很多种,但通常会有一条“黄金路径”可以通过这些检查并完全初始化设备驱动程序。如果没有这个“黄金路径”的知识,模糊测试只能找到早期终止驱动程序的浅层路径。
本文引入了一种技术,将符号执行和强制执行相结合,以生成“黄金种子”:可用于指导驱动程序初始化的模糊器输入。符号执行允许 Drifuzz 快速解决难以进行模糊测试的约束条件,例如魔数检查,而强制执行则可以让我们绕过重复检查(例如轮询循环),否则这些检查将阻碍符号和符号执行的方法。
我们利用这个思想构建了Drifuzz,这是一个协同共测辅助模糊测试工具,旨在发现操作系统和外围设备之间的驱动程序漏洞。我们将系统实现为混合模糊器:在生成黄金种子之后,我们在覆盖率引导的随机模糊测试和符号执行之间交替进行。
虽然混合模糊化是其他领域中常见的技术,但它以前未被用于操作系统-外围边界。混合模糊化对于测试设备驱动程序特别有效,因为它们具有相对较低的执行吞吐量和随机模糊测试难以处理的代码模式。
混合模糊化:
混合模糊化(hybrid fuzzing)是一种结合静态分析和动态分析技术的模糊测试方法。在混合模糊化中,首先使用静态分析技术对程序进行分析,以便了解程序的控制流信息、数据类型和语法等特征,然后生成测试用例并将其输入到程序中进行动态分析。混合模糊化可以有效地提高模糊测试的覆盖率和效率,从而更好地发现程序漏洞。
5)测试结果
在我们的实验中,我们发现使用黄金种子开始混合模糊测试可以使复杂的 WiFi 驱动程序的覆盖范围提高 214%(3.1 倍)。对于较简单的以太网 NIC 等驱动程序,我们发现 Drifuzz 的表现优于基线模糊器,并实现了 60%(1.6 倍)以上的覆盖范围。此外,在测试的十个 PCI 驱动程序和四个 USB WiFi 驱动程序中,我们发现了六个新的错误。
4主要贡献
1)介绍了一种生成“黄金种子”的技术,使设备驱动程序代码可以在没有实际硬件的情况下成功执行,从而使模糊测试能够深入到驱动程序代码中。
2)通过将符号执行和强制执行添加到 PANDA 动态分析平台来实现这些想法;据我们所知,Drifuzz 是第一个测试操作系统外围边界的整个系统混合模糊测试器。
3)使用 Drifuzz 发现并修复了 12 个 Linux 设备驱动程序错误,其中两个被分配了 CVE 编号。
二、背景
1.设备驱动程序安全
1)被攻击的原因
操作系统内核作为用户级软件和硬件之间的抽象实现。在硬件和内核子系统的抽象之间,存在设备驱动程序。由于需要支持各种各样的硬件,因此设备驱动程序也是多种多样的。这使得维护者很难审核设备驱动程序的安全性;Renzelmann等人指出,设备驱动程序通常也具有较低的测试优先级。与此同时,设备驱动程序以内核模式运行,并具有高度特权,这使它们成为诱人的攻击目标。
2)可能的攻击目标
来自两个来源的攻击者控制的输入都会暴露给设备驱动程序:。
<1>一种攻击类型来自用户空间,Linux用户空间程序可以使用ioctl系统调用来调用和利用驱动程序,以执行本地权限提升到内核模式。
<2>另一种攻击类型来自硬件方面;在这里,外围设备被认为是恶意或已经被攻破。本文重点讨论PCI和USB设备(如WiFi和以太网外设)中的硬件攻击向量。因为它们通过以太网或无线信号接收外部输入,这些驱动程序的漏洞可能会被远程和悄无声息地利用。
2.系统仿真与分析
1)实现
用QEMU进行全系统仿真对于测试内核子系统和驱动程序非常有用。使用全系统仿真器可以连接模拟的硬件外设,并通过模糊输入响应操作系统的交互。之前的工作,如USBFuzz 、Syzkaller的USB Fuzzing 和Agamotto也使用全系统仿真来实现这个目的。
2)名词/方法解释
KVM和TCG模式:
QEMU为全系统仿真提供了两种模式:
<1>基于内核的虚拟机(KVM)。QEMU-KVM利用Linux的KVM虚拟化子系统通过CPU支持硬件虚拟化,使其能够以接近裸金属速度运行编译后的操作系统二进制文件。
<2>和Tiny Code Generator(TCG)模式,相比之下,QEMU-TCG将二进制文件转换为中间表示(IR),然后将IR转换为适用于主机体系结构的机器代码进行执行。虽然TCG模式比硬件慢,但是TCG模式可以实现污点分析[15]和符号执行。
TCG模式:
TCG模式是QEMU(Quick Emulator)用于执行二进制代码的一种模式。TCG代表“Tiny Code Generator”(小型代码生成器),它负责将二进制指令翻译成目标主机上的代码,并在运行时执行这些代码。TCG是QEMU的默认执行模式,可以提供高性能和跨平台兼容性,支持多种架构的处理器和设备模拟。
LLVM模式:
Chipounov等人介绍了一种动态将TCG IR转换为LLVM IR的技术,以便可以使用现有的LLVM分析技术与QEMU一起使用。这项工作减少了创建整个系统动态二进制分析的开发开销,但是它引入了一个大的性能惩罚,在后面本文会讨论。PANDA (Platform for Architecture-Neutral Dynamic Analysis) 是一种基于QEMU的TCG和LLVM模式构建的记录和重放工具。PANDA在全系统仿真中插入钩子以记录后续确定性重放所需的关键输入。记录和重放功能允许用户在相当快的TCG模式下记录执行,并在重放时执行更重的分析。在分析驱动程序代码时,这非常重要,因为许多驱动程序具有超时和看门狗线程,如果执行速度太慢可能会触发这些线程。
看门狗线程:
看门狗线程(watchdog thread)是一种在多线程编程中常用的技术,目的是监测程序运行是否正常,并在程序出现异常情况时采取相应的措施。通常情况下,看门狗线程会周期性地检查主线程或其他子线程的运行状态,如果发现异常情况(例如线程挂起或死锁),则会自动触发一些处理操作,比如重启程序或者释放资源等。看门狗线程可以减少程序崩溃的风险,提高系统的稳定性和健壮性。在实际开发中,它也经常被用于处理一些关键性任务,如网络连接、数据传输等,以确保系统的可靠性。
PANDA支持插件系统中的污点分析
用户可以将输入字节标记为污点,并观察污点流和依赖于有污点数据的分支指令。它首先将TCG-IR转换为LLVM-IR,对LLVM进行仪器化以添加污点跟踪,然后编译并运行LLVM代码。与TCG模式相比,该过程引入了约20倍的开销:10秒的记录在TCG模式回放中可能需要1分钟,在LLVM模式回放中可能需要20分钟。在使用模糊测试工具时,这种开销可能会妨碍进展。在第4.3节中,我们讨论了优化方法,以有选择地运行LLVM模式来提高速度。
符号执行:
在现实世界的程序中,随机变异策略可能会遇到难以通过检查的问题,例如魔数或校验和验证。符号执行是一种方法,它对具体输入使用符号执行生成与具体路径不同的新输入。这些相邻的路径可能会引导模糊测试工具探索未经探索的代码部分,并帮助模糊测试工具克服这些阻塞分支。
3.面临的挑战
1)硬件的多样性和可用性
<1>多样性高
硬件多样性是之前涉及硬件的工作的主要缺点。Charm 需要将新设备的驱动程序移植到主机虚拟机和Android系统中,这项任务根据作者的估计需要2到5天的时间。尽管Periscope 所需的人力成本较少,但仍然需要将其组件移植到被测试的Android设备上。
<2>可用性低
硬件在环路中的方法不具有可扩展性。即使驱动程序源代码可用,研究人员也需要购买与每个驱动程序相对应的硬件,从而严重限制了研究人员进行广泛测试的能力。依赖于物理硬件也限制了测试速度,因为每个设备一次只能运行一个测试用例。并且拥有许多核心的强大服务器硬件无法有效地用于此类测试,因为正在测试的设备会成为瓶颈。
出于这些原因,我们认为使用仿真进行模糊测试是保障操作系统-外围设备边界安全的更好解决方案。
2)在驱动程序中难以模糊化的代码模式
不使用真实设备进行模糊测试的好处是,我们可以轻松地扩展到多个虚拟机上运行。
与此同时,缺乏真实硬件意味着我们很难知道驱动程序应该看起来像什么。当对用户空间程序进行模糊测试时,可以通过构建一组有效输入作为初始种子来减轻这个问题;然而,外围设备驱动程序的输入不符合任何特定的文件格式,因此没有可用的种子输入。此外,驱动程序包含许多构造,例如魔术值和轮询循环,这些对传统的模糊测试器和符号执行引擎具有挑战性,并且驱动程序通常会在检测到设备异常响应时立即中止。要通过检查,模糊器需要提供4字节的值等于魔数和另一个4字节的值等于版本ID。在我们的实验中,我们发现Agamotto这样的最先进的灰盒模糊测试器无法通过此条件,并且无法初始化设备驱动程序。常规模糊化可能无法帮助,因为魔数通常被掩码或移位后再进行比较。
轮询循环在驱动程序代码中也很常见,现有技术可能难以处理这样的构造:模糊测试不太可能在每次迭代中生成正确的值,符号执行可能会遇到路径扩散(因为在循环的每次迭代中都会生成新状态),并且共计执行需要一次生成256个输入才能通过循环。
三、Drifuzz的设计
1.总述
1)组成:
如图1所示,我们使用三个主要部分设计了Drifuzz:
<1>种子生成
<2>模糊测试
<3>共辅执行。
(转载自Drifuzz: Harvesting Bugs in Device Drivers from Golden Seeds 图1)
2)流程
<1>我们生成金种子,在共辅执行和强制执行的帮助下,帮助深入驱动程序代码。<2>我们将金种子传递给我们的模糊测试工具,该工具向多个KVM虚拟机发送变异输入。
<3>每个虚拟机(VM)使用输入种子处理MMIO / DMA读取;种子被分割并按I / O地址保留以提高稳定性。
<4>虚拟机客户端初始化设备驱动程序并启动目标网络接口。
<5>虚拟机将分支覆盖位图报告给模糊测试程序的核心部分,而模糊测试工具支持使用共辅执行线程的混合模糊测试。
2.设备驱动程序输入
MMIO和DMA是设备驱动程序的两个主要输入源。在低层次上工作时,PCI驱动程序通常直接使用端口I/O、MMIO和DMA。此外,USB驱动程序使用通用协议在更高层上工作,其中数据以数据包的形式传输。
1)MMIO的处理
QEMU的PCI设备仿真接口处理MMIO。当我们创建一个仿真设备时,我们添加反映真实硬件上PCI存储器布局的内存映射区域。每当客户操作系统访问这些MMIO区域时,QEMU会查询我们的仿真设备,将MMIO读取转发到模糊测试工具核心部分。我们忽略对仿真MMIO的任何写入。由于QEMU将端口I/O空间实现为其自己地址空间中的另一个内存区域,因此我们也以这种方式处理端口I/O。
2)DMA的处理
DMA访问需要特殊处理。Linux文档定义了两种类型的DMA缓冲区:一致性DMA和流式DMA。一致性DMA同步工作:驱动程序和设备可以随时读取和写入分配的空间,并且结果立即对另一端可见。流式DMA使用异步通信,其中驱动程序分配缓冲区并允许设备异步访问缓冲区。当设备完成工作时,它通过MMIO或中断通知驱动程序。然后,如果需要,驱动程序释放缓冲区并读取数据。
我们修改内核代码以拦截DMA分配并通过DMA缓冲区提供模糊输入。我们用不同的方式处理一致性DMA和流式DMA。因为一致性DMA类似于MMIO,因此在分配一致性DMA时将内存区域注册为MMIO区域,并在解除分配时删除该区域。另一方面,流式DMA用于异步传输大量数据。读取输入发生在解除分配后。因此,每当解除分配时,我们都使用模糊输入填充缓冲区。
3)USB的处理
USB设备主要通过批量传输来传输数据。在最低层次上,这些数据包由DMA控制器传输,并且与流式DMA类似。然而,我们利用QEMU的USB层,并在数据包层面进行处理,类似于USBFuzz 。
3.搜索黄金种子
在本小节中,我们介绍了一种基于共同执行的搜索算法,以找到我们模糊测试器的“黄金种子”。
1)总述
驱动程序代码中的许多符号分支具有首选条件。例如,指示设备仍然处于活动状态的I/O标志、检查是否有新输入或版本ID检查。如果驱动程序初始化成功,这些分支必须始终以相同的方式解决。如果不是这样,驱动程序通常会中止并阻止对驱动程序代码的进一步探索;我们称这些为阻塞分支。因此,我们可以使用共同执行找到这样的分支并将它们固定为首选条件,以达到更深入的代码。
2)具体实现
<1>算法思想
我们将偏好定义为从分支指令到其首选条件的映射(Preference: Branch→ Condition)。翻转时增加覆盖率的分支通常被视为阻塞分支,而一个执行中可能有多个阻塞分支。我们的算法贪婪地尝试最大化基于唯一符号分支数量的得分。我们的黄金种子搜索算法通过迭代执行种子并使用约束求解器改进种子来识别阻塞分支。
<2>具体实现
(转载自Drifuzz: Harvesting Bugs in Device Drivers from Golden Seeds 列表2)
如列表2所示,从空白偏好映射(第2行)开始,通过执行随机输入并记录任何依赖于设备输入的分支并将其存储在new_branches中,初始化要考虑的符号分支集合。然后while循环(第6-27行)通过尝试找到每个新分支的首选条件来逐步增加首选项映射。它通过使用强制执行(在下一节中描述)运行带有设置为true或false的分支的输入(第13行),这记录了所有符号分支并生成了一种诱导路径的新输入。如果这暴露出新的分支,则更preferred_results以便在下一次迭代中考虑这些分支。已存在于最近的执行中的分支条件将被跳过(第11-12行),因为它们已经由当前跟踪满足。
一旦评估了当前迭代中的所有分支,我们选择最高得分的分支条件,将其保存在首选项中(第23-24行),并选择相应的输入以及它暴露的分支以便在下一次迭代中处理(第26-27行)。当测试分支条件时没有发现新分支时,循环终止(第18-20行),并将当前输入指定为黄金种子。
从经验上讲,我们发现评估输入的最佳指标是它们暴露的唯一符号分支数量。与块或分支覆盖率相比,唯一符号分支的数量强调我们的输入如何影响执行路径。如果有平局,则更喜欢导致较少总符号分支的输入(因为较短的跟踪对于模糊测试更有效)。
4.强制执行
1)共同执行
(转载自Drifuzz: Harvesting Bugs in Device Drivers from Golden Seeds 列表3)
传统的共同执行每次只能翻转一个分支;如果检查是重复的并具有首选条件,则会导致许多浪费的执行和调用约束求解器。清单3中的代码显示了Atheros ath9k驱动程序中的真实例子。最佳路径在第6行的条件每次返回false时遍历循环256(0x100)次,需要256次共同执行运行。
2)强制执行
强制执行通过简单地强制分支进入所需方向来优化设备驱动程序中重复的共同执行分支,而不是试图解决约束条件。
为了克服共同执行的这种限制,我们使用强制执行来获取所需的路径并生成正确的输入以遍历该路径,避免不必要的分支翻转。对于清单3中的示例,强制执行将允许我们在第6行设置分支为假的情况下遍历所有0x100个迭代,从而进行单次执行。然后可以在此路径上使用共同执行以一次找到满足分支条件的输入,而不必逐个解决每个分支实例。
3)存在的问题
强制执行的一个问题是我们无法保证生成的执行与任何输入相对应:我们可能会遍历具有冲突条件的路径,导致不可行的路径。在黄金种子搜索期间,我们始终先尝试强制执行,如果第一次执行由于不可行的路径而失败,则使用求解器提供的输入重试。如果仍然失败,则将测试的分支从黄金种子搜索中排除。在后面,我们详细描述了如何通过即时修改生成的TCG IR来实现强制执行。
5.传统和混合模糊测试
本文的设计继承了kAFL传统模糊测试的设计。核心模糊器基于覆盖反馈进行变异和记录输入。通过运行合成执行,能够提供混合模糊测试。在种子生成后,大多数时间使用传统模糊测试,并调用符号执行来克服难以通过的分支条件。当遇到新路径时,模糊器核心将输入转发给符号执行器,以生成相邻路径的输入。然后将新生成的输入发送到模糊器核心,测试它们是否导致新的覆盖率。
四、具体实现
1.缓冲输入馈送
1)传统做法
传统的操作系统外设边界模糊测试器通常将模糊器输入表示为单个文件,并按顺序从该文件返回数据,使驱动程序尝试从设备读取数据。
2)存在的问题
这种紧凑的顺序表示使变异策略(如位翻转和有趣字节)表现良好,但可能导致相同的输入在并发驱动程序下展现出不同的行为,因为内核调度程序可能以不同的顺序运行线程。这反过来可能使复制模糊器生成的测试用例更加困难,并且使覆盖率测量不稳定。而并发在设备驱动程序中很常见,其中一些任务可能在后台线程中注册运行,而中断处理则在另一个线程中进行。
3)本文的做法
相反,我们将模糊器输入存储为根据它们的 I/O 地址或 DMA 缓冲区大小分开的一组序列。直觉是不同的 I/O 地址通常具有不同的目的,并且不同的线程通常处理不同的任务,因此即使线程以不同的顺序运行,这种分离也更有可能提供相同的行为和覆盖率。我们对该技术的评估没有发现我们测试的驱动程序的位图覆盖率存在重大差异。然而,由于它不会增加额外的开销,并且仍然可能对我们尚未测试的驱动程序产生好处,因此我们将其保留为启用状态。
2.KASAN 优化
1)存在的问题
模糊测试器的效力主要在于它能够快速测试单个输入的速度。在评估之前的工作时,我们发现虚拟机执行速度比本地速度慢得多,例如运行Linux modprobe命令加载和初始化设备驱动程序。尽管该命令在本地可以在毫秒级别完成,但在虚拟机中某些驱动程序需要超过一秒钟。
2)原因剖析
分析执行性能后,我们发现Kernel Address Sanitizer(KASAN)中的堆栈跟踪导致了这种开销。默认情况下,KASAN记录每个内存(de)分配及其调用堆栈;尽管此信息不用于检测内存错误,但它允许KASAN为(de)分配站点生成堆栈跟踪,这对于调试或崩溃去重非常有用。然而,在模糊测试期间,这种成本由每个进程和线程承担,特别是内核模块加载涉及许多分配(例如,用于模块代码和所有数据结构)。
3)本文做法
我们发现禁用KASAN中的堆栈跟踪平均可以加速4倍。尽管这会产生略微不够详细的错误报告,但我们可以通过使用未修改的KASAN回放感兴趣的输入来轻松重构缺失的信息并生成完整的报告。在附录A中,我们提供有关堆栈展开开销的性能影响和原因以及评估替代解决方案的进一步详细信息。
3.选择性符号执行
1)存在的问题
如前所述,PANDA专门用于离线分析,因此为了精度而牺牲了速度。但是,在模糊测试中,高吞吐量对于有效的缺陷发现至关重要。
2)本文的做法
受之前的工作的启发,我们应用了选择性符号执行,并仅在LLVM模式下运行设备驱动程序代码。在KASLR不存在的情况下(我们已禁用它),可加载的设备驱动程序位于64位x86系统上从地址0xffffffffa0000000开始。我们修改了PANDA,仅在代码地址高于此地址时使用LLVM翻译。
我们还为需要分析的三个额外的内核代码启用了LLVM:I/O函数、memcpy和上下文切换函数。 I/O函数(例如ioread32)对于我们注册符号或污点值至关重要。memcpy函数可以从内核模块调用,但驻留在主内核的代码中。上下文切换函数对于符号或污点跟踪的正确性非常重要。当驱动程序代码被中断时,内核将当前寄存器保存在堆栈上。当驱动程序代码再次运行时,调度程序首先恢复寄存器。为了正确地保留寄存器中的符号标签,我们强制上下文切换函数以LLVM模式运行。
3)本文做法的优点
通过仅在LLVM模式下运行相关驱动程序代码,我们可以将分析加速最多20倍。通过此优化,符号执行的开销几乎与TCG模式的开销相同。原因是通常有许多内核线程在后台运行,因此驱动程序代码只占总执行时间的相对较小部分。
4.协同执行
1)本文做法
类似于Siewertsen(尽管是独立实现的),我们基于PANDA现有的污点分析插件构建了我们的共同符号执行。这种设计给我们带来了许多优势。记录和重放系统可以让我们以相当快的TCG模式运行时间敏感的驱动程序代码,并在计算密集型的LLVM模式下执行分析。我们需要完全的系统仿真来连接模拟设备,而PANDA已经可以处理这种用例。最后,PANDA是建立在QEMU之上并保留了QEMU-KVM支持;尽管我们无法在KVM模式下记录或重放,但直接使用PANDA减少了冗余代码。对于约束求解,我们使用微软的Z3 ,因为它速度快、被广泛使用且稳健。
PANDA的污点系统将TCG IR转换为LLVM IR,并用提供精细的(字节级)污点跟踪的函数进行仪器化。根据LLVM IR指令类型,污点可以传播或去除。例如,乘法会混合输入寄存器的污点,而存储指令将目标上的污点替换为源的污点标签。
微软的Z3:
微软的Z3是一个高性能自动定理证明器,用于求解数学公式和逻辑问题。它可以处理多种类型的约束,例如布尔逻辑、线性整数和实数算术、位向量以及有限域等。Z3被广泛应用于各种领域,包括编程语言工具、软件分析、安全验证、人工智能、计算机视觉和自动驾驶等。在符号执行和模糊测试中,Z3通常用于求解路径约束或生成输入,以探索程序的不同执行路径和行为。
2)具体实现
为了实现共同符号执行,扩展了PANDA污点系统的阴影内存,以保存指向Z3表达式的指针,并为每个LLVM IR操作实现了符号规则。对于每种IR指令类型,我们应用等价的符号表达式并将结果存储在阴影内存中。例如,在LLVM IR %result = %reg1 + % reg2中,如果%reg1具有符号值x,而%reg2具有具体值7,则%result将保存符号值x+7。
为了标记初始的符号输入,我们编写了一个插件,拦截MMIO和DMA读取,并创建字节级别的符号标签。然后我们可以在执行期间收集符号分支条件;完整的路径条件只是这些约束的连接。对于强制执行生成的跟踪,我们可以直接使用路径条件来从求解器中获得一个输入,该输入将在没有强制执行的情况下产生跟踪(如果存在)。在混合模糊测试期间,我们可以使用路径条件通过截断与该分支对应的项之后的约束连接来反转特定的分支,否定该项,并将所得到的公式传递给Z3求解器以获取导致分支方向相反的新输入。
为了处理符号指针,Drifuzz使用在运行时观察到的具体值对符号地址进行具体化。这是与其他共同符号执行实现共享的常见设计选择,但可能限制我们处理生成涉及符号指针的复杂约束的驱动程序代码的能力。这可以通过实现类似Mayhem 等系统中找到的符号指针推理来改进。
5.通过修改TCG强制执行
1)具体实现
为了在捕获有用的路径约束的同时实现分支修改,我们钩入QEMU的TCG生成模块。在种子生成期间,我们修改目标分支以始终走向所需条件(始终为真或始终为假)。同时,我们跟踪原始分支条件,以便我们可以收集相应的路径约束。
当共同符号执行器看到一个被修改的分支时,它会添加一个对应于所需条件的路径约束。在共同符号执行结束时,当我们收集到所有路径约束时,我们使用Z3来解决约束并找到该路径的实际输入。
在ath9k示例(清单3)中,我们可以快速测试分支的始终为真或始终为假条件。如果条件始终为真,则测试I/O函数会快速失败,并向调用者返回错误代码,从而中止初始化。另一方面,当分支始终为假时,256次循环可以在单个执行中完成,使核心能够继续执行并找到未见过的符号分支。新的分支使始终为假的条件得到良好的评分,然后我们可以继续查找和解决其余阻塞分支。
2)存在的问题
虽然强制执行在实践中表现良好,但有时可能会导致不可行的路径(即没有实际输入与路径相对应)。当存在两个彼此依赖的符号分支时,修复一个分支的结果可能会导致不可行路径。其根本原因在于,在强制执行期间,与修改后的分支条件相关的变量保留其原始具体值。如果后续分支依赖于相同的变量,则分支结果将与具体值一致,产生一对矛盾约束和不可满足的路径条件。例如,在清单4中,强制使第4行为真而不更改第8行的条件可能会导致在第10行返回超时错误。
由于我们TCG修改的设计,我们无法即时强制后面的分支。TCG修改发生在执行期间,并且必须在整个记录和重放阶段保持一致。由于我们在记录时不知道符号值,因此我们不能修改路径以强制执行符合先前强制执行的分支的一致性。
3)应对措施
但是,我们可以检测到这种情况:在不可行的路径中,来自两个条件的路径约束互相矛盾,Z3将返回unsat。当检测到这种不一致性时,我们删除后面的路径约束并生成一个满足第一个路径的新输入。然后我们使用新生成的输入重复共同符号执行。因为我们实际上改变了具体值,所以这也允许满足第二个分支。
虽然这适用于大多数不可行路径的情况,但在更复杂的情况下(例如有多于两个相关条件),此技术可能会失败。在这种情况下,我们仅忽略特定分支的偏好,在生成黄金种子时不考虑该分支。
6.模糊器的实现
1)实现思路
我们基于成熟的fuzzer kAFL来构建我们的fuzzer,因为它可以与QEMU-KVM实例一起使用。这使得在测试新输入和收集代码覆盖率时可以利用快速的硬件虚拟化。
2)具体实现
该fuzzer同时启动多个QEMU-KVM虚拟机实例。对于PCI目标,每个QEMU实例都配置了一个模拟的外围设备,并发送fuzzing输入到目标设备的PCI设备ID2。对于USB目标,我们附加一个带有USB描述符的模拟USB外围设备,其中包含目标驱动程序的正确设备标识符;此标识符可以从驱动程序代码中的USB_DEVICE声明获取。我们还为与fuzzing后端通信的VM附加了另一个虚拟设备。VM还运行一个修改过的客户机Linux内核,它公开DMA映射。
(转载自Drifuzz: Harvesting Bugs in Device Drivers from Golden Seeds 列表5)
每个实例通过加载VM快照来启动新环境。然后,在客户机VM内部运行一个脚本(如清单5所示),使用modprobe加载驱动程序,等待一秒钟以让任何后台设置完成,然后尝试启动网络接口,以便接收或传输数据包。我们定制的内核检测到初始化期间的失败,防止模块加载并及早终止运行,以避免在不成功的运行上浪费时间。
当脚本完成后,它报告覆盖范围并将VM恢复到保存的快照。如果实例超时或出现内存错误,我们记录输入并重新启动虚拟机。对于fuzzing PCI驱动程序,我们还在每75个MMIO读取/写入时触发设备的中断。这允许探索中断处理代码同时保持确定性和可重复性。
我们的fuzzer使用根据前面的算法生成的黄金种子作为初始输入,并为达到新覆盖范围的每个执行创建测试用例。初始种子和测试用例都以包含二进制文件的格式存储,该文件包含要返回的实际值以及将MMIO地址和DMA读取大小映射到PCI设备的值。由于对USB设备的输入在更高级别的数据包接口处处理,因此仅需要二进制文件。
五、评价
1.测试环境
评估是在两个独立的系统上进行的:一个具有2个AMD EPYC 7542 32核CPU和512 GiB RAM的服务器(本节中简称“服务器机器”),以及一个具有16核AMD Ryzen 5950x CPU和32 GiB RAM的桌面计算机(“桌面机器”)。我们使用前者进行更大规模的fuzzing实验,后者用于较小规模的实验以及需要专门内核(例如与Agamotto进行比较)或其他广泛的本地修改(例如SymDrive的构建和运行时环境)的实验。
2.评估Drifuzz
1)黄金种子的生成
在这个实验中,我们在桌面计算机上运行我们的黄金种子生成算法,对十个目标驱动程序进行评估:三个PCI WiFi,四个PCI以太网和三个USB WiFi。
(转载自Drifuzz: Harvesting Bugs in Device Drivers from Golden Seeds 图2)
在表2中,我们列出了跨三次试验生成种子所需的平均时间、发现的符号分支总数,以及已发现并解决的阻塞分支数。其中,在我们先前未知的12个错误中,有10个是在种子生成期间发现的。
种子生成所需的时间因驱动程序复杂性而异,从ris_usb和mwifiex_usb几分钟到ath9k驱动程序的138分钟不等。种子旨在生成一次,然后用于更长时间的fuzzing活动,因此我们认为这些时间是合理的。发现的符号分支数量表明Drifuzz能够深入到驱动程序代码的更深路径,特别是对于PCI驱动程序。我们的结果还显示,阻塞分支相对常见,并且存在于所有测试的驱动程序中。
2)消融研究
配置:
为了更好地理解黄金种子生成和符号执行模糊测试组件对Drifuzz覆盖复杂驱动程序代码能力的贡献,我们进行了一项消融研究,在不同配置下比较了七个PCI网络驱动程序(三个WiFi和四个以太网)达到的代码覆盖率:
<1>基于随机种子的灰盒fuzzing(RandomSeed,我们的基准),
<2>基于随机种子的符号执行fuzzing(RS+C)
<3>使用生成的黄金种子的灰盒fuzzing(GoldenSeed),
<4>以及使用黄金种子的符号执行fuzzing(GS+C,我们的完整系统)。
测试的WiFi驱动程序是 :
<>1rtwpci
<2>ath9k
<3>ath10k,
以太网驱动程序包括 stmmac_pci、8139cp、atlantic 和 snic。
选择WiFi驱动程序是因为它们是实现大部分802.11功能的复杂SoftMAC驱动程序,大多数功能在软件中而不是硬件中实现,而以太网驱动程序则可与之前的工作进行比较。
实验内容:
我们的实验在64个QEMU实例中并行运行,利用所有物理核心。对于每个配置,我们运行1小时的fuzzing实验,总计64个核心小时。在运行符号执行时,我们暂停QEMU实例,以确保所有设置使用相同的CPU时间。按照Klees等人提供的fuzzing建议,我们重复每个实验十次;我们还提供了完整系统(GS+C)与基线之间的覆盖率增加,并使用双侧Mann-Whitney U测试进行统计显着性评估。为了测量覆盖范围,我们计算覆盖图中的非零字节数(这相当于发现的唯一边缘数,模哈希碰撞)。
实验结果:
我们发现,与基线相比,在平均值下,完整的Drifuzz配置可以将WiFi PCI驱动程序的覆盖范围提高214%,以太网PCI驱动程序的覆盖范围提高60%。对于除stmmac_pci外的所有驱动程序,结果在统计上具有显著意义(尽管8139cp驱动程序的收益非常小)。通过手动检查,我们发现stmmac_pci和8139cp具有相对简单的初始化函数,因此这些驱动程序上的标准灰盒fuzzing就足够了。
结论:
使用黄金种子的配置往往优于从随机种子开始的配置。即使在fuzzing期间不使用符号执行,这也是正确的。我们认为,这可能表明驱动程序代码中的许多更困难的条件都在初始化阶段找到,因此使用黄金种子的配置在种子生成期间捕获了符号执行的大部分好处。我们没有发现两个黄金种子配置之间存在统计显着差异,进一步证明符号执行fuzzing并没有增加太多额外的好处,仅使用黄金种子就足够了。
3.与先前工作的比较
1) SymDrive
对比原因:
当面对复杂设备驱动程序中的代码结构时,纯符号方法可能会遭受路径爆炸的困扰,因此我们采用组合的符号执行和强制执行来设计我们的黄金种子生成算法。为了测试这一点,我们将Drifuzz的黄金种子生成与以前基于符号执行的设备驱动程序测试系统SymDrive[38]进行比较。
实现:
由于SymDrive相对较旧(发表于2012年)并且实现在Linux 3.1.1上,我们将Drifuzz移植到这个内核版本,然后使用两个系统来测试该内核版本中存在的四个PCI WiFi驱动程序:ath5k、ath9k、atmel_pci和orinoco_pci。由于Linux 3.1.1不支持通过kcov进行内核覆盖率测量,因此我们比较每个系统完成其探索所花费的时间,以及在每个系统的搜索终止时是否成功初始化网络接口(eth0或wlan0)以及发现的错误数量。与SymDrive论文一样,我们进行三次试验并报告平均时间。
结果分析:
界面发现和错误发现方面的结果在所有三次试验中保持一致。
对于四个驱动程序中的三个,SymDrive完成速度比Drifuzz要快,但在orinoco驱动程序中遭遇了路径爆炸,并花费了420分钟(7小时)才能完成。然而,SymDrive只成功地初始化了其中一个驱动程序ath9k的网络接口,而Drifuzz能够在所有四个驱动程序中初始化接口。SymDrive的符号探索基于优先级策略,该策略更青睐成功的返回值(大部分为零,在Linux内核的大多数部分中都是如此)。实现不同的搜索策略可能使SymDrive能够在其他三个驱动程序上成功,但这超出了我们工作的范围。最后,虽然SymDrive的探索没有发现所测试驱动程序中的任何错误,但Drifuzz在ath5k和orinoco_pci驱动程序中发现了内存安全问题。我们发现orinico的漏洞已经在以后的内核版本中被独立发现并修复;然而,ath5k的漏洞仍然存在于现代内核中。我们向内核维护者报告了此缺陷并提供了修复方案。
2)Agamotto
对比原因:
Agamotto是与我们自己的工作最相关的研究,因为它在操作系统外围边界应用了灰盒模糊测试。
实现:
由于硬件兼容性问题,我们在桌面机器上进行比较,而不是服务器机器上。与之前一样,我们运行一个小时的实验,但由于桌面机器上CPU核心数较少,这导致了16个核小时的实验;我们重复实验十次并报告结果的显著性。我们添加对前面测试的三个PCI WiFi驱动程序的支持,以使评估与我们的消融研究更加一致,并测试四个PCI以太网和三个USB WiFi驱动程序(包括在Agamotto的评估中)。
我们还对Agamotto进行了轻微修改,以使配置更一致且可与Drifuzz进行比较。Agamotto的覆盖率测量使用共享全局变量来存储先前的程序计数器,这会在存在多个线程时向覆盖图添加虚假的边缘。因此,我们将其转换为线程本地变量。Agamotto还在整个网络子系统中测量覆盖范围;由于Drifuzz针对驱动器模糊测试进行了优化(特别是在驱动代码之外禁用了其符号执行分析),因此我们将Agamotto的覆盖范围跟踪限制在驱动程序代码中。
结果分析:
PCI驱动程序:
我们在表5中比较了Drifuzz和Agamotto在基于PCI的驱动程序上的性能。我们发现,Drifuzz在PCI驱动程序上平均实现了154%(2.5倍)更高的覆盖率。对于所有测试的驱动程序,这些结果的显著性水平为p<0.001或更好。尽管实验时间较短,但总体覆盖率与我们消融研究的结果相当;我们认为这是由于桌面系统单核性能显著提高所致。
USB驱动程序:
在这里,我们在Agamotto和Drifuzz上评估了三个USB WiFi驱动程序,这些驱动程序包含在Agamotto的评估中。为了与Drifuzz保持一致,在测试Agamotto时,我们省略了USB断开选项,并比较在驱动程序内部实现的覆盖率。请注意,与我们评估中的其他实验不同,我们测量的是块覆盖率,而不是边缘覆盖率,因为Agamotto(以及其基于Syzkaller的USB支持)在模糊测试USB设备时不报告分支覆盖率。结果显示在表6中。
Drifuzz在每个驱动程序上均优于Agamotto,找到了四个以前未知的错误,这些错误Agamotto无法检测到。我们使用交互式覆盖UI(由Syzkaller继承)并确认,在三个驱动程序中,有漏洞的代码没有被Agamotto覆盖。
4.查找BUG
除了我们主要评估过程中发现的漏洞外,我们还使用黄金种子生成算法对ath9k USB驱动程序进行了临时测试。通过Drifuzz,我们能够发现该驱动程序中的两个漏洞:一个是已由Syzkaller报告的漏洞,另一个是在修复Syzkaller报告的缺陷补丁后,由Drifuzz揭示的未知漏洞。
总体而言,我们使用Drifuzz在四个PCI驱动程序和四个USB驱动程序中发现了12个先前未知的漏洞。在我们开发fuzzer的过程中,手动发现了其他两个PCI驱动程序漏洞。我们已向Linux开源社区提交了14个漏洞的补丁;其中13个补丁已被内核接受,其中一个仍在审核中。
(转载自Drifuzz: Harvesting Bugs in Device Drivers from Golden Seeds 图7)
表7列出了我们使用Drifuzz发现的12个内存漏洞。其中10个是在黄金种子生成的混合探索阶段发现的,另外两个是在混合fuzzing期间发现的。
六、不足和未来的工作
1.不足
与许多其他使用符号执行的系统类似,我们在处理具有符号地址的指针时存在限制:
理想情况下,在符号地址处进行读取或写入应该考虑所有满足约束条件的可能地址都可以被修改;然而,在实践中这可能非常昂贵。我们采用了一种常见的实际解决方法,即对指针进行具体化。但是,由此带来的后果是,我们无法解决涉及符号地址的复杂结构,例如在rtwpci驱动程序中解析非易失性只读存储器(NVRAM)的内容。我们希望通过采用某种形式的符号数组建模来消除这个限制,类似于Mayhem中找到的那种。
正如在我们的相关工作中所讨论的那样,嵌入式设备重定位领域的萌芽阶段试图自动建立设备外围的模型,以便完全在软件中仿真嵌入式设备固件,其目标与我们的工作有许多相同之处。重定位和无硬件驱动程序fuzzing都需要生成满意的响应以回答驱动程序的查询,否则驱动程序将得出硬件故障的结论并中止。虽然fuzz驱动程序所需的驱动程序功能水平明显低于仿真整个嵌入式系统所需的功能水平,但我们认为在避免路径爆炸的同时找到外围响应的良好值的一些技术也适用于重定位问题,并且我们计划在未来的研究中进一步探讨这种联系。
2.未来的工作
我们希望将我们的工作扩展到闭源Android设备驱动程序。由于这些设备是移动设备,因此它们更容易通过WiFi和蓝牙进行远程攻击;同时,许多驱动程序是闭源和专有的,这使得大规模测试变得困难。我们当前的工作流程仅需要驱动程序源代码以进行覆盖收集;然而,硬件辅助覆盖收集[40,41]和静态二进制重写[14,18,55]的最新进展可以使针对闭源驱动程序的覆盖率收集变得更加容易。最后,我们还希望将我们的fuzzer扩展到探索不同的中断调度,以暴露更难发现的驱动程序错误,例如竞争条件。
七、相关工作
以往工作:
最近,学术研究人员对模糊测试的关注程度有了很大提升。在这里,我们重点关注与Drifuzz最相关的工作;对于最近的模糊测试研究的更完整概述,我们将读者引导到Manès等人的调查中。 Drifuzz通过使用强制执行和共轭测试来生成复杂驱动程序代码的良好初始种子,扩展了传统的模糊测试方法,并允许有效测试操作系统外设边界而不需要实际硬件。混合模糊测试是克服随机模糊测试某些限制的一种流行方法;然而,大多数这类工作都集中在用户空间程序上。HFL 与Linux内核一起工作,但主要研究系统调用接口,不处理MMIO、DMA或中断。
当前工作:
尽管PCI设备驱动程序迄今为止受到相对较少的关注,但一些先前的工作已经研究了USB驱动程序的安全性。在这里,激励威胁模型是攻击者可以物理访问机器并插入恶意USB外围设备。先前的工作在模糊测试和恶意软件检测中使用程序转换。T-Fuzz 应用强制执行来禁用复杂的条件检查,并在符号执行过程中恢复路径。尽管基本思想相似,但Drifuzz与内核代码一起工作,并在共轭执行期间修改驱动程序代码,以快速识别优选的分支条件。
Agamotto:
Agamotto 使用快照来加速设备驱动程序模糊测试。在模糊测试中找到新路径是罕见的情况;大多数fuzzer的时间都花费在已发现的路径上。Agamotto在执行期间主动创建快照。当它执行一个新输入时,它通过最长公共前缀找到最接近的快照,并从快照开始执行。保存实际执行和恢复之间的时间差,从而加速模糊测试。尽管我们的评估发现,Drifuzz的种子生成能力更好,能够处理复杂驱动程序并达到更深入的路径,但如果必要的符号状态在快照中保存,该快照机制也有可能使Drifuzz受益。
基于硬件的回路测试:
在硬件测试方面,基于硬件的回路测试可以是一种有效的错误查找策略。不幸的是,这种技术需要大量人力和资源来测试新设备。例如,Periscope需要将自定义Android内核刷到测试设备上,而Charm则需要将设备驱动程序移植到修改后的内核中。最近的一项工作,BOSD,使用记录和重播来缩放GPU驱动程序的模糊测试,通过在多个核上重播真实硬件的记录响应,但仍需要至少一个真实的设备,并且仅关注系统调用.
八、总结
本文介绍了一种有效生成“黄金种子”的技术,可以在无需访问真实硬件外设的情况下高效地测试操作系统-外围边界。我们的实现增强了PANDA现有的污点分析功能,以执行符号执行,并利用TCG修改来优化符号执行黄金种子的生成。我们对14个WiFi和Ethernet驱动程序的评估表明,黄金种子和混合模糊测试使得Drifuzz比先前的技术水平具有更高的覆盖率,并发现了设备驱动程序中的真实漏洞。其中两个严重影响的漏洞被分配了CVE编号。
个人思考
一、个人总结
传统的设备驱动程序往往是在信任硬件设备的情况下运行的,并没有对外围硬件设备有很好的安全措施,但随着科技的发展,各种硬件输入输出设备愈加复杂、功能愈加繁多,使得攻击者可以通过易受攻击的外围设备来控制主机,本文因此着眼于设备驱动程序的安全问题,通过分析以往研究发现操作系统-外围边界方向的研究仍不充分,分析了测试设备驱动程序的主要困难–外围设备的多样性带来的低扩展性和高成本难题。为此,针对WiFi和以太网驱动程序,本文提出了一种无需硬件的共模增强模糊测试器来测试驱动程序中潜藏的漏洞,为了解决设备驱动程序探测识别导致始化失败的问题,提出了一种生成高质量初始种子(称为黄金种子)的技术来提高测试效率,最后比以往的类似实现来体现本文方案的优点。
二、思路剖析
1.确定了研究方向为设备驱动程序中潜藏的安全问题
2.分析了以往对于设备驱动程序安全问题的研究,发现操作系统-外围边界方向的研究仍不充分
3.深入剖析了操作系统-外围边界方向的研究仍不充分的主要原因即–外围设备的多样性带来的低扩展性和高成本难题。
4.提出了一种无需硬件的共模增强模糊测试器来解决上述问题
5.在研究中遇到了设备驱动程序探测识别导致始化失败的问题
6.提出了一种生成高质量初始种子(称为黄金种子)的技术来增强测试效率
7.对比过往类似的研究,对比分析了效率,展现了本文提出技术的优点
8.分析了局限性和对以后的期望
三、值得借鉴的点
1.本文通过将其他领域中常见的技术-混合模糊化,引入操作系统-外围边界中,成功解决了测试设备驱动程序的难题,这种移植技术的思维和做法值得我们学习。
2.在遇到值得探索的问题,比如设备驱动程序中的安全问题时,能准确的查找到研究较少的操作系统-外围边界方向,并分析出了主要限制因素,并针对这个限制提出有价值的新方法。
3.在提出共模增强模糊测试器时遇到设备驱动程序探测识别导致始化失败的问题时,能打破常规做法,采用黄金种子和强制来解决,并极大提升了程序效率。
4.研究的问题具有针对性,本文只针对WiFi和以太网驱动程序,一方面使得研究内容不会过大而难以进行,另一方面,本文研究方向正好有之前产生的漏洞作为研究样例,具有参考价值,也更正具有可信性。
四、大胆揣测
本文是从测试驱动程序代码方向进行的研究,因为驱动程序默认外围硬件可信任,我们是否可以研究从攻击外围硬件的方向下手,研究驱动程序中可能的漏洞