为慈善而战：自动化漏洞挖掘在LibOTR中的应用
背景介绍
我们为DARPA网络大挑战开发的自动化漏洞挖掘系统——网络推理系统（CRS），原本设计用于DECREE操作系统的二进制代码分析。虽然DECREE基于Linux，但与标准Linux系统存在显著差异：不支持信号、共享内存、线程、套接字和文件，仅提供七个系统调用。这意味着DECREE与LibOTR等Linux库既不二进制兼容也不源代码兼容。
经过评估，我们决定将LibOTR移植到DECREE系统，而不是为CRS添加完整的Linux支持。移植过程需要解决两个主要问题：共享库依赖（LibOTR依赖libgpgerror和libgcrypt）和libc支持。我们使用LLVM一次性解决这两个问题：
- 使用whole-program-llvm将LibOTR及其所有依赖编译为LLVM位码
- 在位码层面合并所有共享库并进行激进优化
- 构建适用于DECREE的libc实现，包括从挑战二进制文件中提取的实现、存根无意义函数，以及基于DECREE调用的新实现
自动化测试方法
加密通信应用本质上难以进行自动审计，这是设计使然：如果自动化系统能够推理密文与明文的关系，加密通信系统就已经被攻破。这些系统也难以通过随机测试（如模糊测试）进行审计，因为接收方会验证每条消息的完整性。
我们选择不修改LibOTR，而是让CRS模拟中间人（MITM）攻击。由于测试的是未修改的LibOTR，我们的CRS无法有效攻击通过消息完整性检查后的代码，但仍可攻击消息控制数据、头部信息以及解密/认证代码中的潜在缺陷。
测试应用的创建比移植LibOTR到DECREE更具挑战性。移植过程相对直接，耗时约两周，而示例应用的开发更加困难：官方LibOTR分发版没有示例代码，文档也不够完善。
测试结果
我们对LibOTR示例应用进行了24小时、48个Xeon CPU的测试，未发现任何内存安全违规。这一负面结果并不意味着LibOTR没有漏洞，因为我们只测试了LibOTR的子集，且CRS从未审计过相当部分的功能。但缺乏明显漏洞仍然是一个积极的信号。
结论
LibOTR赌约的时间框架已经结束，期间没有报告任何高严重性漏洞。我们使用自动化漏洞挖掘工具审计了LibOTR的部分代码，也未发现内存损坏漏洞。通过这次测试，我们学会了如何将Linux应用移植到DECREE，并验证了CRS能够识别Linux程序中的真实漏洞。
更好的文档、测试和覆盖所有LibOTR功能的示例应用将简化自动和手动审计过程。在此实验中，我们限制自己使用未修改的LibOTR，但计划在未来进行修改LibOTR以支持更轻松自动化测试的实验。