自动化漏洞挖掘：为慈善而战，LibOTR安全测试之旅

背景

我们为DARPA网络大挑战开发的自动化漏洞挖掘系统（称为网络推理系统，CRS）原本针对DECREE操作系统的二进制代码运行。DECREE基于Linux，但与普通Linux有显著差异：无信号、无共享内存、无线程、无套接字、无文件，仅支持七个系统调用。这意味着DECREE与LibOTR等Linux库不兼容。

经过权衡，我们决定将LibOTR移植到DECREE，而不是为CRS添加完整的Linux支持。移植过程以通用方式进行，以便将来测试其他Linux软件。

移植LibOTR需解决两个主要问题：共享库依赖（LibOTR依赖libgpgerror和libgcrypt）和libc支持。我们使用LLVM一次性解决这两个问题。首先，使用whole-program-llvm将LibOTR及所有依赖编译为LLVM位码。然后在位码级别合并所有共享库，并积极优化结果位码。这一步骤消除了对共享库的需求，并大幅减少了需实现的libc数量，因为未使用的libc调用被优化掉了。为构建适用于DECREE的libc，我们结合了挑战二进制文件中的libc实现，存根了在DECREE中无意义的函数，并在适当处基于DECREE调用创建了新实现。

自动化测试

加密通信应用设计上难以自动审计：如果自动化系统能推理密文与明文的关系，加密通信系统就已失效。这些系统也难以通过随机测试（如模糊测试）审计，因为接收方会验证每条消息的完整性。通常测试加密系统时，会关闭加密（或在加密前或解密后操纵数据）。我们想模拟测试黑盒二进制文件，因此未以任何方式修改LibOTR。相反，我们认为最佳路径是让CRS模拟中间人（MITM）攻击。

由于测试的是未修改的LibOTR，我们的CRS无法有效攻击通过消息完整性检查的代码。但仍有大量攻击面：消息控制数据、标头以及解密/认证代码中的潜在缺陷。问题在于我们的CRS并非为MITM设计。我们转而架构测试应用程序（非LibOTR）以更容易攻击，导致了下述复杂架构。

CRS充当两个使用LibOTR通信的应用程序之间的中间人。

创建测试应用程序比将LibOTR移植到DECREE更困难。移植过程相当直接，耗时约两周。示例应用程序耗时稍长，且体验更令人沮丧：官方LibOTR分发版无示例代码，文档也不尽如人意。

我们的测试受示例应用程序使用的LibOTR功能（例如，未使用SMP）以及我们创建的特殊测试应用程序的限制。此外，某些漏洞可能仅在解密后出现，而修改加密和认证数据永远不会触发这些漏洞。

结果

测试LibOTR的结果非常令人鼓舞。我们使用48个Xeon CPU针对LibOTR示例应用程序运行24小时，未发现任何内存安全违规。

CRS充当两个使用LibOTR通信的应用程序之间的中间人。

这一阴性结果并不意味着LibOTR无漏洞。我们仅测试了LibOTR的子集，且有相当部分CRS从未审计。但缺乏明显漏洞是一个非常好的迹象。

结论

LibOTR赌约的时间框架已过，无任何报告的高严重性漏洞。我们用自动化漏洞挖掘工具审计了部分LibOTR，也未发现内存损坏漏洞。在设置此测试的过程中，我们学会了如何将Linux应用程序移植到DECREE，并验证了CRS能识别Linux程序中的真实漏洞。更好的文档、测试和覆盖每个LibOTR功能的示例应用程序将简化自动和手动审计。在此实验中，我们约束自己使用未修改的LibOTR。我们计划未来进行测试，修改LibOTR以启用更轻松的自动化测试。

如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News