1. 核心原理、

Use After Free (UAF，释放后重用) 是一种严重的内存损坏型安全漏洞。它发生在堆内存被释放（Free）之后，程序仍然使用指向该内存的指针（Dangling Pointer，野指针），依然通过原来的指针去访问（读取或写入）该内存区域。

在堆管理机制中，被释放的内存并不会立即被操作系统收回，而是被堆管理器缓存到特定的Bin（如 Tcache, Fastbin）中以备复用。如果程序没有将原指针清空，攻击者就可以通过巧妙的内存布局控制这块“已被释放但仍被引用”的内存。

UAF 漏洞的本质是悬空指针（Dangling Pointer）的生命周期管理不当。其标准发生过程如下：

• 1. 分配内存：程序在堆中申请了一块内存，并将其地址赋给指针；
• 2. 释放内存：程序调用free(P) 或delete P释放了这块内存，系统将该内存标记为“空闲”；
• 3. 遗留悬空指针：程序在释放内存后，没有将指针P设置为NULL，指针P依然指向原来的堆地址，此时该内存块被放入堆管理器的空闲链表中；
• 4. 内存重用（关键步）：程序申请了一块新内存。由于堆管理器的优化机制（如glibc的fastbins机制），系统往往会将刚才释放的那块内存重新分配给新对象；
• 非法重引用：程序在不知情的情况下，再次通过旧指针P去读写数据。此时，由于内存已被新对象占用，读写操作实际上是在篡改或读取新对象的数据；

2. 漏洞利用

利用UAF的关键在于“伪造”。既然指针P还能用，攻击者就需要想办法让P指向的内容变成攻击者可控的数据，利用UAF可以劫持控制流，即篡改函数指针，这是最经典的Get Shell手法。

假设原本的堆块存储了一个结构体，里面包含一个函数指针（例如：void (*func_ptr)()）：

• 1. 释放该结构体堆块；
• 2. 申请一个相同大小的新堆块。由于堆管理器的复用机制（后进先出LIFO），新申请的块会直接占用刚才释放的旧块空间；
• 3. 攻击者在新堆块中写入控制数据，将原本存放func_ptr的位置覆盖为system函数或one_gadget的地址；
• 4. 触发：程序再次调用旧指针P->func_ptr()，由于内存已被篡改，程序将直接跳转去执行system(“/bin/sh”)；

3. 漏洞实例

3.1 CVE-2019-5786 (Google Chrome)漏洞

这是2019年被发现在Google Chrome浏览器中并被野外利用（0-day攻击）的顶级UAF漏洞，存在于Chrome的FileReader组件中。

Chrome 的FileReader允许网页中的JavaScript读取本地文件。为了提高性能，读取大文件时，Chrome会在堆内存中分配缓冲区，并使用多线程来处理数据。

3.1.1 漏洞成因

该漏洞的主因是由于FileReader 成为了悬空指针：

• 1. 正常创建：JS 脚本创建了一个FileReader对象，Chrome在底层C++堆中为该对象分配了多块内存，用于存储文件流数据；
• 2. 多线程竞争与释放：攻击者利用精心编写的JavaScript异步并发代码，触发了组件内部的一个竞争条件（Race Condition）。这导致浏览器在某个线程还在读取数据时，另一个线程已经把该FileReader对应的内存块给 free（释放） 掉了；
• 3. 悬空指针：FileReader的主控制指针没有被置空，成为了悬空指针；

3.1.2 漏洞利用

攻击者在JavaScript中紧接着创建了大量的ArrayBuffer（字节数组）对象。由于大小和刚刚释放的FileReader内存极其接近，DOM引擎的堆管理器把这些ArrayBuffer分配到了刚才被释放的内存地址上；

此时，Chrome还在运行的旧线程试图通过悬空指针继续写入文件数据，这一写实际上直接写进了攻击者控制的ArrayBuffer里。攻击者通过这种方式，成功修改了浏览器的内部敏感对象（如特定的C++虚函数表vtable），直接绕过了Chrome的沙箱（Sandbox）保护，在受害者的电脑上执行了任意恶意代码。