起因是这样的, 最近不是在学堆嘛, 得翻各种 glibc 源码. 但是 elixir 的索引做得很差, 点一下相当于全文搜索, 那我要你这索引干嘛. 后来找到了 woboq, 官方实例有 glibc, 试了一下还挺方便. 简单搜索了一下, 并没有找到别人搭建好的各种 glibc 版本的代码浏览器, 于是程序员思维: 自己动手!

介绍

竞争冒险Race Condition, 又叫竞争条件. 最初源自逻辑电路中两个电信号的竞争. 由于你电计科数电不讲这玩意, 所以我也不知道是啥. 在后来的计算机软件中, 由于并行进程访问同一个资源也可能造成竞争性的冲突, 这个词也就沿用了下来.

例子

学过操作系统的都知道, 如果两个并行的进程或线程对同一个资源的访问不是原子的, 那么就很可能出现意想不到的情况. 比如下面这个简单的例子:

原理

如未特殊说明, 均假定 libc 2.23, 64 位.

当 malloc 从 unsortbin 中取 chunk 时, 会有一个双向链表解链的过程 (为方便, 代码只截取数据结构部分):

原理

堆题的最后一步攻击手段, 有一个就是覆盖各种 hook, 其中就包括 __malloc_hook. 如果我们无法控制程序恰好写入到此处, 但是可以修改 chunk 的 fd 或者 bk, 达到 尝试任意地址分配 的效果, 那么就可以尝试分配到 __malloc_hook 附近. 为什么这里说尝试呢? 因为在 malloc 在从 bins 中取 chunk 的时候, 都会对这个 chunk 的 size 进行检测. 所以, 我们需要分配到 __malloc_hook 之前, 恰好 size 位满足条件的地方. (Tcache 的话就不用了, 因为没有任何检测)

一般来说, 程序在初始化了堆以后, __malloc_hook 前面不远处会有 libc 的地址. 这取决于 libc bss 节上变量的分布. 举个例子, 在某版本的 glibc 初始化了堆后, __malloc_hook 附近如下图所示:

可以看到, 在 __malloc_hook 前 0x8, 0x10, 0x20 处, 都有 libc 的地址, 且前 0x18 处为 0.

原理

如未特殊说明, 均假定 libc 2.23, 64 位.

Unsortbin

Unsortbin 就是 malloc state 中的 bins[1], 相关定义如下:

精灵的家!

原理

如未特殊说明, 均假定 libc 2.27, 64 位.

Tcache

Tcache 是 glibc 2.26 加入的东西, 从 cache 这个名字也可以看出来, Tcache 机制是为了更加高效地分配堆.

高效性和安全性是两个负相关的指标. 因为其安全检查机制的不完善, 所以我们的攻击会变得更加简单.

首先还是来分析 Tcache 的源码.

数据结构

在 malloc.c 中, 与 Tcache 有关的两个结构体如下: