自动化漏洞挖掘：LibOTR慈善黑客挑战与技术实践

背景

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

我们决定将LibOTR移植到DECREE，而不是为CRS添加完整的Linux支持。移植过程需解决两个主要问题：共享库依赖（LibOTR依赖libgpgerror和libgcrypt）和libc支持。我们使用LLVM一次性解决这两个问题：

1. 使用whole-program-llvm将LibOTR及所有依赖编译为LLVM位码。
2. 在位码级别合并所有共享库，并积极优化结果位码。
3. 通过优化消除未使用的libc调用，减少需实现的libc量。
4. 结合挑战二进制文件中的libc实现、存根无意义函数，并基于DECREE调用创建新实现，构建适用于DECREE的libc。

自动化测试

加密通信应用设计上难以自动审计，因为若自动化系统能推理密文与明文关系，加密系统即已失效。随机测试（如模糊测试）也困难，因为接收方会验证每条消息的完整性。

通常测试加密系统时会关闭加密（或在加密前/解密后操纵数据），但为模拟黑盒二进制测试，我们未修改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

页面内容
背景 | 自动化测试 | 结果 | 结论

近期文章

• 使用Deptective调查依赖
• 做好准备，AIxCC评分轮正在进行！
• 超越私钥风险的智能合约成熟化
• Go解析器中意外的安全隐患
• 评审首批DKLs23库的收获
• Silence Laboratories的23个库

© 2025 Trail of Bits.
使用Hugo和Mainroad主题生成。