2026-05-23 2026-05-23

glibc-2.35 新增保护机制

在 glibc 2.35 环境下进行堆利用时，保护机制的升级使得许多早期的经典利用手法彻底失效。相较于早期版本（如 2.23 - 2.27 甚至 2.29），2.35 版本的堆结构和内存分配器更加严格。以下是几个需要特别注意的核心变化和应对思路：

这是 2.35 下影响最大的改变（此机制从 2.34 开始就已被彻底执行）。

变化：__free_hook、__malloc_hook、__realloc_hook 等全局函数指针被完全删除。
影响： 过去“劫持 Hook -> 填入 system 地址 -> 触发 free/malloc”的“万金油”打法完全成为历史。
应对策略：
- FSOP (File Stream Oriented Programming)： 劫持 _IO_2_1_stdout_、_IO_list_all 等 IO 结构体。利用链的构造通常需要转向 House of Apple 2、House of Emma 或 House of Kiwi 等基于 _IO_FILE 虚表劫持的手法。
- 劫持栈返回地址： 利用任意地址读泄露 environ 变量获取栈基址，计算偏移后直接覆盖目标函数的返回地址进行 ROP（例如执行 SROP 或 Ret2csu 链）。
- 其他偏门目标： 劫持 tls_dtor_list（线程局部存储的析构函数链表），或者修改 __stack_chk_guard 配合栈溢出触发 __stack_chk_fail 打印信息。

从 2.32 版本开始引入并在 2.35 中严格实行的指针保护。

变化：fastbin 和 tcache 的 fd 指针不再直接明文存储下一个 chunk 的地址，而是存储了一个经过异或运算的加密值。
加密公式：$M = P \oplus (L \gg 12)$
- $M$ (Mangled Pointer)：内存中实际存储的密文值。
- $P$ (Plain Pointer)：原本要写入的目标指针地址。
- $L$ (Location)：当前 chunk fd 字段自身所在的内存地址。
应对策略： 必须具备堆地址泄露（Heap Leak）能力。在没有堆泄露的情况下，强行篡改 fd 会导致解密出的地址错乱并引发段错误。拿到堆基址后，可以通过逆向运算伪造出正确的密文写入 fd，从而恢复任意地址写（Arbitrary Write）能力。

变化： 针对 tcache 和 fastbin，系统增加了严格的 16 字节（0x10）对齐检查。
影响： 过去通过错位伪造 chunk 的手法（例如在 2.23 中常用的利用 main_arena 附近的 \x7f 伪造 fastbin size）变得极其困难。如果伪造的地址没有按照 16 字节对齐，程序在申请到该内存时会直接抛出 SIGABRT。
应对策略： 构造 Fake Chunk 时，必须确保劫持的目标地址低位严格对齐（通常以 0 结尾）。

变化： 从 2.29 开始引入的 tcache_key 检查在 2.35 中依然生效。每个放入 tcache 的 chunk，其 bk（对应的位置）会被写入一个指向 tcache_perthread_struct 结构体的指针（即 key）。
影响： 释放时如果检查到该 key 存在，就会遍历当前对应 size 的 tcache 链表。如果发现该 chunk 已经在链表中，程序就会崩溃报错 double free or corruption (fasttop)。
应对策略： * 最直接的方式是通过 UAF（Use-After-Free）将已释放 chunk 的 key 字段覆盖为垃圾数据，即可轻松绕过检测并实现同一 chunk 的二次释放。
- 或者将 chunk 填满 tcache（7个），使其进入 fastbin 或 unsorted bin 来使用其他 bin 的特性。

在这些机制的综合作用下，2.35 的堆利用通常形成了一套固定的起手式：泄露堆地址解密 Safe-Linking -> 泄露 libc 地址 -> 利用 UAF 篡改 tcache fd -> 实现任意地址写 -> 劫持 IO 结构体或栈地址执行控制流劫持。

你想先看一下 Safe-Linking 加解密的 Python 实现逻辑，还是探讨一下如何在 2.35 中具体构造 IO 劫持链？

更新: 2026-04-20 21:39:25
原文: https://www.yuque.com/idcm/wnemg9/iut8gyq4cao5c49i