!exploitable崩溃分析器的历史

在本月初的CanSecWest会议上，我们首次公开发布了!exploitable崩溃分析器。虽然即将发布的白皮书和CanSecWest幻灯片详细介绍了相关技术，但我们认为探讨该工具的历史可能有所帮助。

起源于模糊测试

最终成为!exploitable崩溃分析器的技术和研究源于MSEC（以及整个微软）在模糊测试技术上的投资。在Windows Vista发布之前，进行了为期14个月的模糊测试工作，总计超过3.5亿次迭代。在检查模糊测试产生的崩溃时，我们观察到崩溃之间存在许多相似之处。几位来自现在MSEC的成员（Adel Abouchaev、Damian Hasse、Scott Lambert和Greg Wroblewski）在2007年11月的MSDN杂志上发表了一篇关于这些发现文章。

模糊测试的一个显著好处是消除了确定“攻击者是否可以访问问题代码”的需要。由于畸形数据是以攻击者可能提供的方式提供的，我们知道如果在模糊测试期间能够生成问题，真实攻击者很可能也能够访问相同的代码。

另一个观察是，代码中的单个问题可能通过多个向量被触发，导致看似不同但根本原因相同的崩溃。通过将发生在代码同一区域的崩溃分组，需要查看的崩溃数量可以显著减少。

在下图中，我们看到了针对1个解析器使用4个不同模糊器进行2周模糊测试的结果，发现了57次崩溃，且模糊器之间的重叠非常少：

[图片：模糊测试结果对比图]

当相同的57次崩溃通过!exploitable崩溃分析器运行并按相似性分组时，我们看到有15个独特问题，将需要查看的崩溃数量减少了近4倍，并且模糊器A和B发现了除2个问题外的所有问题，显示了哪些模糊器对此应用程序的覆盖率最好。

[图片：!exploitable分析结果对比图]

然而，即使在分组相似崩溃时，也需要对发现的崩溃严重性进行粗略分类。!exploitable崩溃分析器就是为满足这些需求而构建的。因此，该工具假设故障指令中的信息由攻击者控制——这是评估模糊测试运行结果时的正常情况。

应用于其他崩溃时的影响

一旦我们超越模糊测试，工具内置的假设会使结果不太可靠。与我们模糊器生成的崩溃不同，我们实际上不知道崩溃是否由攻击者可能控制的信息引起。即使在这种情况下，堆栈跟踪哈希也让我们能够分组相似问题。但我们必须对!exploitable提供的可利用性评级添加一个隐含的警告：“如果攻击者控制了故障指令的源数据……”。

这对开发者意味着什么？实际上，这意味着我们不知道是仅仅有一个有问题的编码问题或错误，还是一个真正的安全漏洞。只有当攻击者能够访问它（通常通过提供无效数据）时，编码问题或错误才会成为安全漏洞。可能问题代码无法被攻击者访问，在这种情况下我们仅仅有一个错误。可能有一些代码路径（我们可能找到也可能没有找到）将问题代码暴露给攻击者控制的数据。或者可能尚未实现的功能将暴露该问题。但对于软件开发人员，尤其是在开发早期发现这些编码问题时，知道代码中存在潜在问题应该足以促使创建和实施修复，或适当地提供给用户安装。

可利用性有多可利用？

即使在崩溃是由攻击者提供的数据引起的情况下，我们也不知道攻击者有多少控制权。例如，如果我们查看故障内存复制，攻击者可能控制目标地址、源地址、移动长度或所有三者的某种组合。在!exploitable崩溃分析器内部，我们假设攻击者控制所有三个。虽然这可能不是实际情况，但我们愿意接受这种情况下风险的过度评估，因为编码问题被认为足够严重，随之而来的误报率是我们认为可接受的。

在分析崩溃时，!exploitable会查看详细信息，并根据相当粗粒度的启发式方法对严重性进行分类。您可以将!exploitable的输出解读为“这是经验告诉我们可能被利用的那种崩溃”，对于软件开发人员来说，这应该是所有必要的信息。弄清楚如何交付漏洞利用远远超出了工具的范围；这种分析往往需要高度熟练的人类。

此外，即使在漏洞可利用的情况下，编译器和平台内置的漏洞利用缓解措施可能足以防止实际利用。这并不意味着根本问题不应该修复，就像有安全气囊和系安全带并不意味着可以不修复刹车一样。但这确实意味着有时最终用户受到保护，即使其他一切都出了问题。

目标受众

从根本上说，这是一个防御性工具，针对软件开发人员，尤其是那些没有深厚安全威胁专业知识的人员。通过分组常见问题、识别多个代码路径流向相同根本问题的情况，并提供个别崩溃安全影响的粗略分类，我们认为它为软件开发人员在开发过程中分类错误提供了有价值的服务。我们在微软内部确实发现了这种情况。

Dave Weinstein和Jason Shirk
微软安全工程中心
发布内容“按原样”提供，不提供任何保证，也不授予任何权利。