自动化漏洞挖掘：在LibOTR中实践慈善黑客行动

Artem Dinaburg
2016年1月13日
cyber-grand-challenge, privacy

去年年底，我们有一些空闲时间探索为DARPA网络大挑战开发的自动化漏洞挖掘技术的新颖用途。当其他参赛者正悄悄准备CGC决赛时，我们可以通过讲述在真实Linux应用程序上运行漏洞挖掘工具的故事来娱乐大家。

2014年11月4日，Thomas Ptacek（来自Starfighter）与Matthew Green（来自约翰霍普金斯大学）打赌，认为libotr（安全消息软件中使用的流行库）在未来12个月内会出现高严重性漏洞（例如远程代码执行、信息泄露）。在Trail of Bits，我们喜欢好的赌注，尤其是当收益用于慈善时。而我们恰好有一个闲置的自动化漏洞挖掘系统，渴望找点事情做。诱惑太大无法抗拒：我们决定使用网络大挑战中的自动化漏洞挖掘系统来查找libotr中的漏洞。

在继续之前，我们应该声明这不是安全审计。我们只是想测试自动化漏洞挖掘系统在真实Linux软件上的表现如何，并可能为慈善事业赢得一些钱。

我们成功增强了漏洞挖掘系统以支持libotr库，并进行了广泛测试。我们的系统确认在我们测试的代码路径中没有关键漏洞；由于没有其他人报告任何漏洞，赌注以Matthew Green向Partners in Health捐赠1000美元结束。

继续阅读以了解加密通信系统对自动化测试带来的挑战，我们如何解决这些挑战，以及我们的测试方法。当然，仅仅因为我们的系统没有在libotr中发现漏洞，并不意味着libotr没有漏洞。

背景

我们为网络大挑战构建的自动化漏洞挖掘系统，称为网络推理系统（CRS），在DECREE操作系统的二进制代码上运行。虽然DECREE基于Linux，但它与普通Linux有很大不同。DECREE没有信号、没有共享内存、没有线程、没有套接字、没有文件，只有七个系统调用。这意味着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的结果非常令人鼓舞。我们针对libotr示例应用程序运行了48个Xeon CPU 24小时，没有发现任何内存安全违规。

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

这一负面结果并不意味着libotr没有漏洞。我们只测试了libotr的一个子集，有相当大部分我们的CRS从未审计过。然而，缺乏明显漏洞是一个非常好的迹象。

结论

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

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

页面内容
背景
自动化测试
结果
结论
近期文章
我们构建了MCP一直需要的安全层
利用废弃硬件中的零日漏洞
Inside EthCC[8]：成为智能合约审计员
使用Vendetect大规模检测代码复制
构建安全消息传递很难：对Bitchat安全辩论的 nuanced 看法
© 2025 Trail of Bits。
使用Hugo和Mainroad主题生成。