介绍部分来自参考资料[0]，其余内容参考自glibc malloc源码，本文结合源码探讨了malloc中的多种机制：包括malloc consolidation，unsortedbin sort，mmap，heap grow等

overflow write、use after free

该利用技巧的核心是 malloc_consolidate 函数，当检测到有 fastbin 的时候，会取出每一个 fastbin chunk，将其放置到 unsortedbin 中，并进行合并。以修改 fd 为例，利用过程如下：

抓住重点：house of rabbit 是对 malloc_consolidate 的利用。因此，不一定要按照原作者的思路来，他的思路需要满足的条件太多了。

实验环境：libc 2.35

流程如下：

填充满tcachebin，以便后续使用fastbin chunk

申请同大小的chunk再释放，使其进入fastbin，指针是p1

申请一个tcache-sized chunk p3，触发malloc_consolidate

此时指向fastbin的指针指向刚刚申请的p3，此时可以再次释放p1，从而对同一个地址连续释放了2次，触发了双重释放

当再次申请p4的时候，位置和p3依然是一样的

简单来说，就是轻量版本的free里的consolidation过程，是针对fastbin chunk的，流程如下：

设置av->have_fastchunks为false

遍历每一个fastbin

遇到fastbin chunk，就进行合并

安全检查：该chunk的大小和该bin的大小需要匹配

向上合并（低地址），能合就合

向下合并（高地址），能合就合

_int_malloc中，当不能从fastbin中申请，且申请大小不属于small size时，如果当前arena有fastbin chunk，就会进行调用：

_int_malloc中，当无法通过top chunk分配，且arena中有fastbin chunk时，就会进行调用：

_int_free中，释放到unsortedbin进行consolidation的过程中，在向前向后合并完成了以后，如果合并的大小超过0x10000，就检测fastbin chunk并进行合并：

和 libc 2.23 相比，新增了3个检查：

在遍历的时候，会检查chunk的内存对齐

在遍历的时候，会检查chunk的大小和fastbin的大小是否匹配

在向前合并的时候，会检查prev_size和前一个chunk的size是否相同

实验环境：libc 2.23

这个实验我做了2天，还是思想太局限了，没收集好题目给出的信息，就在硬做，看到大佬的exp，恍然大悟，实在精彩！精彩！

保护：没有PIE，以及Partial RELRO，意味着got表可以作为利用目标

main函数：很简洁，三个功能，其中没有任何地方能打印

malloc的函数：根据输入的选项申请固定大小的内存

edit函数：存在释放后写入漏洞，可以修改释放后的chunk

free的函数：释放后没清楚函数指针，可能存在UAF，Double-Free（由于没有libc leak，没法用double-free打）

其中重要变量的内存布局：

由于整个程序不会打印任何东西，所以没法得到libc leak

但是其中有一个功能提供了申请0xFFFFFFFFFFFFFF70LL大小和0xA00000uLL大小内存的功能（当时我还不懂，后来发现这是整个利用的核心！）

其实这个0xA00000uLL是个提示，回顾一下libc 2.23下malloc的过程：

首先是检查是否满足fastbin大小要求，满足且存在适合的chunk就从fastbin中分配

然后检查是否满足smallbin，满足且存在适合的chunk就从smallbin中分配

同时检查是否满足largebin，满足就计算一下所属的largebin的索引idx

进行unsortedbin的处理过程，从后向前遍历unsortedbin链表，满足切割分配就切割分配，大小精确匹配就分配，大小不匹配的就根据大小装入largebin和smallbin

unsortedbin处理完之后，从largebin中找满足大小要求的chunk分配，要么直接分配出去，要么切割分配出去，剩下的部分装入unsortedbin

最后在从top chunk分配，分配不了就用sysmalloc去映射内存或者扩大top chunk

在从unsortedbin或largebin，smallbin中断链的时候，会检查next chunk的prev_size和当前size是否匹配

这里的0xA00000给出的提示就是要用到largebin去分配巨大的0xFFFFFFFFFFFFFF70LL内存，通过分割来获得能覆盖指针数组的chunk

那么处理思路就是：

首先申请2个0xa00000的chunk，并释放掉，目的是：

用来提升​**av->system_mem**​ （后面探讨原因，见后文：探讨2）

然后申请fastbin size chunk，释放掉，通过WAF漏洞来修改其fd指针指向buffer，此时的bin：

此时buffer被修改成如下样子

这里为什么要这样构造buffer结构？

回顾一下malloc consolidation的过程：

从fastbin中依次取出fastbin chunk

对chunk进行简易版的free的consolidation过程

这里会进行向前向后合并的操作，修改prev_inuse标志为1，可以使其不向上合并，但是依然会进行向下合并的检查：

这里的下一个chunk在0x602140，然后再下一个chunk由于大小是0，所以还在同样的位置，检查prev_inuse位是1，不进行合并操作，触发malloc consolidation后会直接把chunk 0x602130加入unsortedbin（堆中的chunk被合并到top里了）

触发malloc consolidation有两种好达到的情况：

后续通过申请0xa00000大小chunk来触发：

接下来要做的就是把该chunk放入largebin了，此时unsortedbin只有1个chunk，需要做到修改unsortedbin大小为0x80000到0xa00010之间，然后申请一个比该chunk大的内存：

这里就是普通的unsortedbin的处理过程：遍历chunk，如果不能通过remainder分配，且大小不精准匹配，就装入largebin或smallbin

修改后的内存：

bin：

此时修改该largebin chunk size为一个巨大的值，这个值需要满足：

修改成0xFFFFFFFFFFFFFF70 + 0x80 = fffffffffffffff0 即可 （注意unlink的时候会计算next chunk检查prev_size）

申请巨大内存后：

这里就没啥好说的了，申请一个0x20字节的chunk，触发remainder，可控内容为got表的地址：

修改其中的内容指向system函数

然后找一个写有/bin/sh的指针进行free：

即可拿到shell

正常情况下，超过top大小的申请，会进入sysmalloc进行处理

在sysmalloc中，会优先使用mmap来处理，使用mmap的条件：

mp_此时的状态：

其中，mp_.mmap_threshold的值为初始值：0x20000，小于申请大小nb，mmap数量也没超过上限，就会进入mmap的流程，映射一块内存分配下来

从前面的结果来看，第二次申请同样大小的chunk时，没有通过mmap处理，而是top grow来处理分配

这说明第二次到这里的时候条件不再满足，调试查看mp_的状态：

发现是mp_.mmap_threshold的值发生了变化

在这两次申请内存之间只间隔了一个free，问题应该就出现在free中

可以看到，如果chunk是映射的，就会调整mp_.mmap_threshold的大小，这意味着，小于该大小的chunk将不再通过mmap进行分配

可以推测出映射内存的一个条件是：当申请内存超过上一次映射释放的大小了之后，才会重新映射内存来分配

在malloc的过程中有一个检查，在处理unsortedbin的时候：

这里检查unsortedbin chunk的大小，大小不能超过堆申请的总大小

关于这个av->system_mem，它会在top grow之后进行累加，在sysmalloc函数中，heap grow之后有这么一段：

这里会记录heap中新增的大小，累加到av->system_mem中，表示现在系统中可用的内存有这么大

后续触发unsortedbin sort机制的时候，需要满足这个条件，就需要提前去增加av->system_mem的大小，方式就是触发heap grow

回顾该exp，总共使用了5次对0xa00000内存的申请，其中第4次触发sort机制

如果刚开始不去触发heap grow，则只会在malloc consolidation的时候触发mmap的调用，在触发sort机制的时候触发heap grow，但是顺序是先检查unsortedbin chunk size，再heap grow，所以来不及

因此：就需要至少申请一次该大小的chunk在之前

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课