超越DECREE:多平台挑战二进制文件如何重塑漏洞挖掘基准

本文探讨DARPA网络大挑战中发布的挑战二进制文件数据集如何成为程序分析工具的新基准。这些包含真实漏洞的复杂程序被移植到主流操作系统,为工具评估提供标准化测试套件,推动漏洞发现和缓解策略的技术发展。

你的工具比我的更好?证明它

毫无疑问,DARPA的网络大挑战(CGC)将因推动多个领域的技术进步而载入史册:符号执行、二进制翻译和动态插桩等等。但我们认为有一个贡献至今被忽视,而它可能被证明是最有用的:挑战二进制文件数据集。

所有工具的通用指标

网络大挑战的参赛者需要识别为DECREE系统编写的挑战二进制文件(CBs)中的漏洞,这些程序基于32位Intel x86架构。自2014年以来,DARPA已经发布了100多个这类易受攻击程序的源代码。这些程序专门设计了代表各种软件缺陷的漏洞。它们不仅仅是简单的测试用例,而是近似真实软件,具有足够的复杂性来考验手动和自动化的漏洞发现能力。

如果CBs被广泛采纳为基准测试,它们可能改变我们解决安全问题的方式。这反映了SAT和ML社区在建立标准化基准和定期竞赛后的快速发展。挑战二进制文件、有效测试输入和样本漏洞创建了一个行业标准基准套件,用于评估:

  • 漏洞查找工具
  • 程序分析工具(例如自动化测试覆盖生成、值域分析)
  • 修补策略
  • 漏洞利用缓解措施

CBs比之前衡量软件分析工具质量的方法(如SAMATE测试、NSA Juliet测试或STONESOUP测试用例)更加健壮。首先,CBs是复杂的程序,如游戏、内容管理系统、图像处理器等,而不仅仅是易受攻击的代码片段。毕竟,要有效,分析工具必须处理错误密度相当低的真实软件,而不是直接的易受攻击代码片段。其次,与添加了错误的开源项目不同,我们非常有信心CBs中的所有错误都已被发现,因此分析工具可以与客观标准进行比较。最后,CBs还附带广泛的功能测试、引入错误的触发器、补丁和性能监控工具,使得修补工具和错误缓解策略的基准测试成为可能。

创建行业标准基准测试集将解决几个阻碍未来程序分析工具开发的问题:

首先,缺乏标准化基准阻止了客观确定哪些工具是“最好的”。真实应用程序不附带复杂错误的触发器,也不附带这些错误的详尽列表。CBs提供了比较指标,例如:

  • 发现的错误数量
  • 每单位时间或内存发现的错误数量
  • 发现和遗漏的错误类别
  • 配置选项导致的性能差异

其次,哪些缓解措施最有效?CBs附带强调原始程序功能的输入、检查已知错误存在的输入和性能测量工具。这些使我们能够探索以下问题:

  • 各种错误缓解策略(例如控制流完整性、代码指针完整性、堆栈Cookie等)的潜在有效性和性能影响是什么?
  • 结果程序运行速度慢多少?
  • 缓解措施与真实补丁相比如何?

在家参与

参加CGC的团队已经花了数年时间磨练和调整他们的错误查找工具以适应DECREE的特殊性。但现实世界并不在DECREE上运行;它在Windows、Mac OS X和Linux上运行。我们认为研究应该由现实世界的挑战和参数指导。因此,我们决定移植*挑战二进制文件以在这些环境中运行。

我们尝试了几次才找到最佳的移植方法,以最小化代码更改量,同时在平台之间保留尽可能多的原始代码。最终的解决方案相当简单:在没有标准包含文件的情况下构建每个编译单元(因为所有CBs都是静态链接的),使用它们的本地等效实现CGC系统调用,并进行各种小修复以使代码与更多编译器和标准库兼容。

我们对多平台CBs在几个方面的潜力感到兴奋:

  • 由于不需要仅为DECREE设置虚拟机,您可以在已有的机器上运行CBs。
  • 有了这个障碍,我们现在都有一个行业基准来评估程序分析工具。我们可以进行比较,例如:
    • CGC工具与现有程序分析和错误查找工具相比如何?
    • 当新工具发布时,它与当前最佳工具相比如何?
    • 处理源代码的静态分析工具是否比处理二进制文件的动态分析工具发现更多错误?
    • 为Mac OS X编写的工具是否比为Linux编写的工具更好,它们是否比为Windows编写的工具更好?
  • 当研究人员开源他们的代码时,我们可以评估他们的发现在特定操作系统或编译器上的效果如何。

在您观看参赛者的CRS对决之前,探索机器人将在您熟悉的环境中尝试解决的挑战。

获取最常见操作系统中的CGC挑战二进制文件。

*特别感谢我们的实习生Kareem El-Faramawi和Loren Maggiore进行移植工作,以及Artem、Peter和Ryan的支持。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计