从off-by-null到堆重叠：glibc 2.23堆利用实战详解

1. 一个字节能改变堆的“世界观”

1.1 off-by-null到底是什么

做堆题做到一定阶段，你会发现真正让人头疼的往往不是UAF那种“明牌”漏洞，而是off-by-null这种只有一个字节的暗伤。它指程序在向堆缓冲区写入数据时，多写了一个字节的\x00。常见触发场景有三个：一是strcpy/sprintf这类字符串函数在结尾自动补终止符；二是read/recv之后程序员手动执行buf[len] = '\0'；三是循环拷贝时边界判断少了1，导致末尾多余写一个0。这个额外的空字节看起来人畜无害，但若它恰好落在下一个堆块的size字段上，整个堆管理器的判断逻辑就会从根上歪掉。

很多人理解off-by-null时，喜欢把它和off-by-one混在一起说。我的建议是分开记：off-by-one是越界写任意一个字节，而off-by-null固定越界写0x00。别小看这个限制，正因为它只能写0，攻击者没有办法随意把size改成别的值，只能把某个字节“抹掉”。于是整个利用思路就变成：想办法让这个被抹掉的0，正好落在size字段的低位字节上，从而把一个合法的chunk size变成另一个看起来合法、但物理边界完全错位的size。

这篇文章面向的读者，是已经知道malloc/free、见过unsorted bin、fastbin这些名词，但始终没搞懂off-by-null到底怎么打的新手。我会用glibc 2.23环境，走一个最经典、最不容易被高版本安全检查干扰的完整流程，带你把“一个\x00如何变成堆重叠、再变成任意写”的链路彻底打通。

1.2 为什么选低版本glibc练手

标题里特意写了“还没有涉及高版本”，不是偷懒，而是刻意为之。glibc 2.29之后的版本增加了不少针对堆利用的硬校验，比如对top chunk size的检查、对unsorted bin中chunk size与next chunk的一致性检查、以及对_int_free中更多边界条件的校验。这些检查会把很多低版本时代“理所当然”的利用步骤直接拦死。初学者若是直接拿高版本环境去试，会发现明明每一步都照着文章做，结果程序偏偏在某个malloc_printerr报错退出，非常打击信心。

glibc 2.23是我最推荐的学习版本，原因有三：第一，它没有tcache，bin结构只有fastbin、unsorted bin、small bin、large bin，逻辑更简洁，便于理解堆管理的本质；第二，free和malloc的检查相对宽松，off-by-null之后触发的向前合并（后向合并）不会遇到太多额外拦截；第三，当时的CTF题目多、教程多、工具链成熟，踩坑经验可以互相印证。等你在2.23上把这套链路玩明白了，再去看高版本的绕过方案，会轻松很多。

2. 先看明白堆chunk的物理结构，再谈攻击

2.1 chunk头、预处理位、申请与可用长度的微妙关系

要理解off-by-null为什么可怕，先得把堆chunk的内存排布刻在脑子里。64位下，一个已分配的chunk结构是这样的：

size字段的低3位分别是PREV_INUSE(第0位)、IS_MMAPPED(第1位)、NON_MAIN_ARENA(第2位)。正常情况下，size值是按16字节对齐的，所以低3位恒为0，可以安全地用最低位标记“前一个chunk是否空闲”。

这里有个特别容易翻车的冷知识：malloc返回给用户的可用长度，并不等于chunk_size - 0x10，而是chunk_size - 0x8。什么意思呢？比如申请malloc(0x1f8)，glibc按request2size宏计算后会分配一个实际chunk大小为0x200的块，但用户可写的范围是从返回指针开始，往后0x1f8字节，这0x1f8字节的最后8字节，物理上其实是下一个chunk的prev_size字段。也就是说，glibc在分配一个chunk时，把下一块的prev_size区域临时“借”给了当前用户使用。这个设计对正常程序完全透明，但一旦配合off-by-null，就成了漏洞利用的支点。

2.2 为什么“写满+1”能把size字段干掉

理解了上面的借用机制，我们就能精确计算off-by-null的落点。假设申请了一个chunk A，实际chunk size是0x200，用户指针为ptrA。在A中写入0x1f8字节数据，刚好把用户可写区域填满，那么最后一个字节会写到ptrA + 0x1f7，而这个位置对应的绝对地址是A + 0x207，正好是下一个chunk B的prev_size字段的最后一个字节。接下来，如果程序执行buf[0x1f8] = '\0'，这个0会写到A + 0x208，也就是B的size字段最低字节。

B的size原本是类似0x211这样的值，低字节0x11被0x00覆盖后，整个size会从0x211变成0x200。注意这里同时发生两件事：第一，B的size被改小了0x11字节；第二，PREV_INUSE标志位也被清零，让堆管理器以为B前面的chunk是空闲的。前者造成了物理边界和逻辑边界的错位，后者则让free(B)时必然触发向前合并。这两个条件，正是后续所有利用的前提。

2.3 核心思路：改小size，伪造prev_size，让free帮你合并

初看off-by-null，很多人会琢磨“能不能直接把某个hook函数附近的地址写坏”，但现实是，一个\x00的破坏力并不体现在直接改数据，而体现在让堆管理器自己产生一个重叠区域。核心思路可以概括为三步：

第一步，用off-by-null把相邻chunk B的size从0x211改成0x200，并顺手清掉它的PREV_INUSE位。第二步，提前在B的prev_size字段里伪造一个值0x200，让堆管理器相信B前面有一个大小为0x200的空闲chunk。第三步，调用free(B)。此时glibc看到B的prev_inuse = 0，就会把B和前面那个“虚拟的空闲chunk”合并，合并后得到一个从A开始、大小为0x400的大chunk，并放入unsorted bin。

合并本身不是目的，真正的目的是：这个0x400的大chunk在物理上同时覆盖了原A和原B两个区域。接下来只要再把大chunk通过malloc申请回来，就能拿到一个跨越原A和B边界的大指针，用它去读写B的内容。而如果程序中仍然持有指向B的旧指针，或者后续能再次把B从unsorted bin中分配出来，就形成了经典的堆重叠（overlapping chunk）。有了堆重叠，泄露libc、改写hook都只是时间问题。

3. 完整利用流程：从off-by-null到堆重叠

3.1 设计初始堆布局

实操之前，先把实验环境说清楚。我使用的是Ubuntu 16.04自带的glibc 2.23，调试工具是gdb + pwntools。用docker起一个同样版本的环境也可以，关键是别用带有tcache的高版本glibc，否则下面的流程会被tcache机制干扰，新手容易误判。

为了制造一个干净的off-by-null场景，我模拟一段存在漏洞的代码。假设程序允许向chunk A写入数据，写满之后补一个\x00，并且这个A紧挨着一个受害者chunk B。我们按以下顺序申请堆块：

c复制void *a = malloc(0x1f8);   // A: 实际chunk size = 0x200
void *b = malloc(0x200);   // B: 实际chunk size = 0x210
void *c = malloc(0x100);   // C: 实际chunk size = 0x110
void *d = malloc(0x10);    // D: 防止top chunk合并，可选

对应的堆内存布局可以理解为：

这里有两个关键设计要解释。为什么A选0x1f8而不是0x100或0x200？因为只有请求0x1f8时，实际chunk size正好是0x200，用户可写0x1f8字节，补0后恰好落在B的size字段低字节，不多不少。为什么B选0x200？因为B的物理size必须带一个非零的低字节，比如0x211，这样off-by-null之后才能从0x211变成0x200，size主体被真正改小。

3.2 触发off-by-null并观察size变化

现在向chunk A写入0x1f8字节数据，并在末尾伪造prev_size。注意，写入的最后8字节不能随便填，要写成0x200，因为后续free(B)时，glibc会把这个值当作B前面那个“空闲chunk”的大小。

c复制// 填充A，最后8字节伪造B.prev_size = 0x200
memset(a, 'A', 0x1f0);
*(size_t *)((char *)a + 0x1f0) = 0x200;  // 覆盖B.prev_size
// 程序随后执行类似 a[0x1f8] = '\0' 的操作
// 这会把B.size从0x211改成0x200

我在实际调试时，习惯在触发前用gdb的heap chunks命令打印一下堆布局，确认A和B的地址是连续的，B的size确实是0x211。触发后再次打印，你会看到B的size变成了0x200，并且PREV_INUSE位被清掉。这一步看起来简单，但它决定了后面所有流程能否成立。

3.3 free触发向前合并，拿回大块

B的size被改成0x200、prev_inuse被清0、prev_size被伪装成0x200之后，直接调用free(b)。glibc执行_int_free时会做如下检查：先看B的prev_inuse位，发现是0，于是认为前一个chunk空闲，再根据prev_size=0x200找到前一个chunk的起始地址，也就是A；随后把A和B合并成一个0x400的空闲chunk，放入unsorted bin。

这个过程中，_int_free还会检查合并后的下一个chunk，也就是C，是否满足合法条件。好消息是C的size为0x110，大于最小chunk大小，且C的prev_inuse位还是1（因为B之前一直处于使用状态），所以检查能顺利通过。合并完成后，glibc会把C的prev_size更新为0x400，同时把C的prev_inuse位清零。

此时堆上存在一个大小为0x400的unsorted bin chunk，起始地址就是A。接着执行：

c复制void *big = malloc(0x3f0);

这个请求对应的chunk size也是0x400，恰好把整个合并chunk完整分配出来。big的user data从A+0x10开始，一直延伸到A+0x410，原A和原B的用户数据区都落在big的可写范围内。换句话说，我们手里现在有一个大指针，可以同时改写原A和原B的内容，堆重叠已经形成。

3.4 从堆重叠到libc泄露

拿到big之后，最直接的收益是泄露libc地址。方法是把原B区域“重新变成一个合法的已分配chunk”，再把它free进unsorted bin。具体操作分两步。

第一步，用big改写原B的chunk头。原B的chunk头在地址A+0x200，我们需要把它伪装成一个size为0x200、prev_inuse为1的chunk：

c复制// 通过big构造原B的header
*(size_t *)((char *)big + 0x200 - 0x10) = 0x200;   // B.prev_size
*(size_t *)((char *)big + 0x200 - 0x08) = 0x201;   // B.size = 0x200 | PREV_INUSE

这里偏移的0x10不要搞混：big的user data起始于A+0x10，所以big + (0x200 - 0x10)正好对应A+0x200，即原B的起始地址。

第二步，修复C的chunk头。因为刚才free(b)时glibc已经把C的prev_inuse清零了，如果直接再次free(b)，会触发double free or corruption (!prev)报错。必须先把C的prev_inuse位恢复为1，顺手把C的prev_size也设成0x200，让堆管理器认为B是一个独立且正在使用的chunk：

c复制// 通过big改写C的header
*(size_t *)((char *)big + 0x410 - 0x10) = 0x200;   // C.prev_size = 0x200
*(size_t *)((char *)big + 0x410 - 0x08) |= 1;      // C.size低位置1, PREV_INUSE=1

完成这两步后，再次执行free(b)。这次B会作为一个0x200的空闲chunk进入unsorted bin，其fd和bk指针都会指向main_arena附近。由于big仍然持有对B区域的引用，我们可以直接读取原B user data的前8字节来获得main_arena地址，再通过本地已知的libc偏移算出libc基址。

python复制# 伪代码示意
libc.address = u64(big[0x210 - 0x10:0x210]) - 0x3c4b20

拿到libc后，常规收尾是利用堆重叠继续构造fastbin attack，把__malloc_hook改写成one_gadget，再触发malloc拿到shell。这一步的细节根据题目环境不同会有些变化，但核心“重叠chunk”的基础到这里已经打牢。初学阶段，我更建议你把精力放在把overlap构造稳定上，因为一旦有了overlap，后面无论打fastbin还是打unsorted bin，都只是套模板的事。

4. 常见报错、坑位与调试建议

4.1 报错信息速查表

我练这个手法时，几乎把glibc所有常见报错都踩了个遍。这里整理一张速查表，方便你对照排查：

最常见的还是第一个和第二个。第一个报错多半是因为你伪造的B.prev_size和实际B.size对不上。记住一个原则：off-by-null把size改成多少，prev_size就要伪造成多少，两者必须完全相等。第二个报错则是因为合并后C的prev_inuse被glibc清零了，你没有及时修复。许多教程为了简略会跳过这一步，结果读者照做就报错，所以我特别提醒一下。

4.2 我常用的调试手法

调试这类堆漏洞，最忌讳的是肉眼盯着十六进制硬猜。我一般会开两个终端，一个跑gdb，一个跑exp脚本。gdb中加载pwndbg插件，重点使用几个命令：heap chunks查看所有chunk的size与标志位；heap bins查看各bin链表；x/20gx <addr>查看指定地址的原始内存。

具体到off-by-null，我建议在四个节点各下断点：触发off-by-null前（确认B.size原始值）、触发后（确认B.size变成0x200）、free(b)后（确认unsorted bin中出现了0x400的大chunk）、malloc(0x3f0)后（确认big覆盖了原A和B区域）。每到一个断点，就用heap chunks和x/20gx对比内存布局。只要这四个节点的状态都符合预期，后面基本不会翻车。

还有一个小技巧：如果你不确定某个偏移算得对不对，可以在payload里填入有规律的标记字节，比如0x4141414141414141，然后回看gdb内存。一旦发现数据落在不该出现的位置，就能很快定位是哪个偏移多算或少算了。这个方法听起来笨，但排查堆布局问题特别高效。

最后再说几句

我在第一次尝试打通off-by-null时，卡在“为什么malloc(0x1f8)的可用大小是0x1f8而不是0x1f0”这个问题上很久。后来才意识到，glibc把下一块chunk的prev_size借给了当前用户，这个设计本来是性能优化，结果却成了漏洞利用的温床。学这个手法的最大收获，不是背下某条利用链，而是学会从堆管理器的视角去审视每一块内存：谁在什么时候会读哪些字段，哪些字段在什么状态下是可以被骗的。想清楚这些，哪怕换一个漏洞类型、换一个glibc版本，你也能很快找到新的路径。建议你跟着上面的流程，亲手在2.23环境里复现一遍，遇到报错不要急着看答案，先对照速查表自己排查，这个过程比任何教程都值钱。