HEAPHOPPER: Bringing Bounded Model Checking to Heap Implementation Security

摘要

堆元数据攻击已经成为攻击者利用内存损坏漏洞的主要方式之一。尽管堆实施开发者已经引入预防和检查崩溃的错书，攻击者仍然能围绕它们做一些事情。在某种程度上，这是因为这些预防措施没有一个原理基础，这导致它在很多时候复杂而低效。

在本文中，我们提出HEAPHOPPER，一个自动化的方式，基于模型检测和符号执行，来分析内存损坏情况下的堆利用实现。使用HEAPHOPPER，我们能够对不同的广泛的堆实施进行分析，发现其中令人惊讶的问题。例如，我们的结果显示，ptmalloc(大多数Linux发行版使用的堆分配器实现)中新引入的缓存机制如何显著降低其安全性。此外，HEAPHOPPER指导我们实现和评估对ptmalloc安全性的改进，用一种有效的防御方法取代了最近为减轻特定形式的堆元数据损坏而进行的无效尝试。

介绍

软件利用的艺术是在不断发展的战场上实践的。过去10年的黑客使用了简单的策略——利用基于堆栈的缓冲区溢出跳转到堆栈上的shellcode，二进制文件的构造函数、析构函数和全局偏移表是实现执行控制的有效目标，而不正确的边界检查在大多数情况下保证了成功执行。但是，随着安全在我们这个相互联系的世界中变得越来越重要，技术水平也在不断提高。安全研究人员开发了一个又一个的缓解措施，旨在减少软件漏洞的影响。栈被弄得不能执行，导致攻击者发明了ROP，变成了ROP攻击者和防御者之间的战争。stack canary投入使用，后来被一些情况绕过……无数保护函数指针的措施被开发出来并又被绕过。二元战争的猫鼠游戏已经持续了很长一段时间:地点发生了变化，但战斗仍然激烈。

面对一系列针对许多经典漏洞的有效缓解技术，黑客发现了一种新的、几乎是无法缓解的武器:堆元数据破坏。应用程序堆负责C和c++程序的动态内存分配(包括其他高级语言的运行时)，由于需要平衡运行时性能、内存性能、安全性和可用性，所以它非常复杂。由于性能原因，许多现代堆实现(包括最流行的[1])将动态分配的应用程序数据放在存储堆操作控制信息的内存区域中。此元数据不受保护，与处理存储在堆中的应用程序数据相关的安全漏洞可能会导致其损坏。反过来，堆元数据的损坏可能会导致堆处理函数以攻击者可控制的方式失败，从而导致攻击者的能力增强，并可能导致完全的应用程序改变。

这个弱点并没有被忽略:堆实现开发人员引入了加强机制来检测堆元数据损坏的存在，如果出现损坏，则终止程序。不幸的是，任何此类措施都必须考虑安全性措施对性能的影响，而这种权衡导致了许多安全性“半吊子措施”对减少今天[44]黑客可用的大量堆利用技术几乎没有什么作用。

这个问题在最近的两起事件中得到了例证。在2017年，GNU标准C库(glibc)堆实现提出并接受了一个补丁。这个补丁表面上修复了一种堆利用技术，这种技术源于对分配记录大小的部分覆盖。尽管补丁的有效性存在不确定性(部分原因是缺乏工具来推断其实际的安全效果)，但补丁还是被提交了。然而，几乎立即就发现可以通过对攻击[45]进行轻微修改来绕过检查。

甚至在最近，ptmalloc分配器(由glibc使用)引入了一个名为tcache的速度优化特性，其目的是从根本上加快频繁分配。同样，没有可用的工具来分析此更改对安全性的影响，而且几乎没有对该更改进行讨论。然而，正如我们在执行这个项目期间所确定的，以及黑客们自那时以来所认为的那样，tcache显著降低了ptmalloc堆实现对元数据损坏的恢复能力。

这些事件表明，迫切需要一种有原则的方法来验证存在软件漏洞时堆实现的行为。虽然在过去已经进行了一些堆操作的安全性分析[32、34、35、39、54]，但是没有一个采用堆安全性原则分析的形式，这种分析直接适用于任意堆实现。

在本文中，我们提出了HEAPHOPPER，它是在存在内存损坏的情况下，将有界模型检查引入动态内存分配器实现的可利用性分析的第一种方法。假设攻击者可以进行一部分的潜在堆误用,并假设不应堆实现故障,攻击者可以利用放大他们的控制过程中,侵犯HEAPHOPPER使用定制的动态符号执行技术来识别对一个规则可配置的模型的违背。如果发现了这样的违背，我们的工具输出概念验证(PoC)代码，这些代码可用于研究堆实现的安全性违规，并测试潜在缓解措施的有效性。

我们将HEAPHOPPER应用于三个不同堆实现的五个不同版本，系统地识别堆攻击:由攻击者触发的堆操作链，以在程序中实现更多内存损坏(例如任意目标的写操作)的能力。这些针对分配器的系统化攻击使我们能够随着实现的发展跟踪安全性的改进(或者，更准确地说，开发难度的增加)，并观察明显缺乏改进的情况。

贡献：

• 我们开发了一种新的方法来执行堆实现的有界模型检查，以在元数据损坏的情况下评估堆实现的安全性。
• 我们通过分析不同版本的堆实现来演示我们的工具的功能，展示了安全性改进和安全性问题。
• 我们使用该工具来分析glibc分配器中引人注目的补丁和更改，从而改进正在等待最终签署并合并到glibc中的补丁。