在前些日子结束的 corCTF 2021 国际赛中，出现了两个有意思的0解Linux kernel题，赛后我的队友crazyman@r3kapig向我推荐了这两道题，我浏览了一下官方题解，做了复现。

这两到题的主要目的是介绍了 <在Linux Kernel中，当我们控制了 struct msg_msg 之后，如何构造任意（越界）读、任意写、以及任意释放的原语。进而如何配合userfaultfd实现对于当前进程的task_struct，以及cred的进攻利用，实现权限提升> 的这样一种技术。

这是出题人的想法与官方WP：

Fire of Salvation

Wall Of Perdition

这个仓库里收集了题目文件：

Github

Linux Kernel Communication — Netfilter Hooks

netfilter是一个用于数据包处理的框架，在正常的套接字接口之外。

它有四个部分。首先，每个协议都定义了 "钩子"（IPv4定义了5个），这些钩子是数据包穿越该协议栈过程中的明确定义的hook point。在每一个点上，协议都根据数据包和hook number调用netfilter框架。

Netfilter给了我们一种在固定的point对packet进行回调，解析，修改，过滤的可能。

Netfilter提供了一种叫做netfilter hooks的东西，这是一种使用回调的方式，以便在内核内过滤数据包。

有5种不同的netfilter hook分别位于如下位置 1～5。

他们对应的是:

NF_INET_PER_ROUNTING

NF_INET_LOCAL_IN

NF_INET_FORWARD

NF_INET_POST_ROUTING

NF_INET_LOCAL_OUT

具体的，我们需要使用 nf_register_net_hook 针对hook进行注册（结构体nf_hook_ops）

题目描述

可以看到开启了一堆保护和额外的加固。

注意以下选项：

值得注意的是的使用了SLAB分配器而非SLUB。

题目源码在：

https://paste.ubuntu.com/p/2xzRxyVjqy/

题目本身实现了一个 内核态的防火墙驱动，定义了针对ipv4数据包的出入站规则 。

init_firewall

对应的结构体如下：

firewall_inbound_hook && firewall_outbound_hook

process_rule

firewall_add_rule

firewall_delete_rule

这个函数没有UAF可以用

firewall_edit_rule

可以编辑几个对应的属性

firewall_dup_rule

本题漏洞很明显，首先在delete函数中不存在UAF，会设置对应free entry为NULL。

但是在 firewall_dup_rule 中用对应idx的entry来填充了list中查找到的第一个为NULL的entry。

如果我们先一步调用 firewall_dup_rule ，相当于在（对称的）list上放了同一个entry的一个copy，我们free掉一个，再利用对称的list里剩下的没有设置为NULL的copy即可完成UAF。

这离要注意 dup = (user_rule.type == INBOUND) ? firewall_rules_out : firewall_rules_in;

也就是说dup的时候firewall_rules_out链表的会dup到firewall_rules_in；firewall_rules_in会dup到firewall_rules_out。是一个对称的dup，而不是在同一个list中dup。

并且由于flag标志位同一个entry只能dup一次。

我们可以UAF的对象属于kmalloc-4096，并且我们可以配合edit完成UAF-write，但是edit限制为只能任意写UAF对象部分长度。

根据 ：manpage

这个对象在上层主要对应的操作是 msgsnd() 还有 msgrcv()

int msgsnd(int msqid, const void *msgp, size_t msgsz, int msgflg)

ssize_t msgrcv(int msqid, void *msgp, size_t msgsz, long msgtyp,int msgflg);

这两个syscall主要用于发送message到系统的消息队列，然后从消息队列接收message。调用他的进程必须对消息队列有写权限才能发送消息；有读权限才能接收消息。

在内核中 msgsnd 会到达 do_msgsnd ：

do_msgsnd

load_msg

alloc_msg

上一部分已经简单介绍了这个函数，这里我们注意一下 struct msg_msgseg

原生的只有一个next指针实际下方还有对应的data区域。

分配的时候 seg = kmalloc(sizeof(*seg) + alen, GFP_KERNEL_ACCOUNT); 会加上剩下的数据的alen的长度，总的长度就是 sizeof(struct msg_msgseg) + alen

当一个消息过长时，其典型结构如：

do_msgrcv

本函数中，如果设置了MSG_COPY，那么会调用 prepare_copy 进行预先分配，其实就是 load_msg 的一个封装。也就是先把用户态的放到一个copy上。

接下来，在for循环中通过 find_msg 中的list_for_each_entry扫描了msg_queue.q_receivers 队列。最终返回合适的 struct msg_msg *

如果设置了 msgflg & MSG_COPY 当开启 CONFIG_CHECKPOINT_RESTORE 时成功调用 copy_msg

在copy_msg中，首先从struct msg_msg 中进行拷贝到函数一开始copy的副本中。

然后拷贝struct msg_msgseg ，从 msg_msg.next 到 msg_copy.next 。

而这个函数中的src参数我们是可以劫持的，下文会详细讲。

注意，如果设置了MSG_COPY 不会进行接下来的出队unlink操作，而是直接 goto out_unlock0;

从队列中unlink，更新队列状态。list_del(&msg->m_list)

最终会到达 bufsz = msg_handler(buf, msg, bufsz); 这个 msg_handler 是 do_msgrcv 的最后一个参数

这个msg_handler实际上就是 store_msg ：

最终会 kfree(msg)

store_msg

本函数主要作用是将内核态放好的msg再拷贝到用户态

do_msgrcv

https://elixir.bootlin.com/linux/v5.8/source/ipc/msg.c#L1090

首先我们创建一个正常的firewall_rule。

delete上一个firewall_rule

从kmalloc-4k中通过创建一个msg_msg取回来free掉的firewall_rule，此时转换成了msg_msg结构

在堆上喷射大量的带有全局数据的 shm_file_data 结构。

利用outbound list上存在的指针，对此时的msg_msg结构进行edit，主要目的是修改 m_ts 为一个大值。

调用 msgrcv 从消息队列中读取，由于此时 m_ts 被劫持为一个大值，所以我们可以进行越界读取。

越界读取到喷射 shm_file_data 利用其中的 init_ipc_ns 泄漏kernel base，bypass fg-kaslr

首先，回顾一下拷贝的过程。

考虑当我们打开MSG_COPY 、 CONFIG_CHECKPOINT_RESTORE时，当我们调用 do_msgrcv 会有如下过程：

首先将用户态传入的buf（一开始是空的）拷贝到一个内核态的副本上（aka. msg_msg_copy, msg_msgseg_copy）

调用 find_msg 根据消息类型，从队列中查找是否有匹配的消息。即查找真正合适的msg_msg结构（就是我们UAF后控制的那个）。

接下来调用 copy_msg 拷贝查找到的匹配的消息msg_msg 以及对应的msg_msgseg到msg_msg_copy、msg_msgseg_copy（通过next指针链接）

接下来一个goto，最终到达 msg_handler(buf, msg, bufsz) 。本质上是调用:

​ do_msg_fill->store_msg->copy_to_user 将对应的msg里的消息copy到用户态。

总结一下：当开启了 MSG_COPY 、 CONFIG_CHECKPOINT_RESTORE 内核会在不更新msg队列信息，不进行unlink的情况下，几乎是直接将对应的msg+msgseg的内容拷贝到用户态连续的地址空间。

这样的好处在于，由于msg_msg不出队，我们可以一直用edit进行多次的hijack。

具体的，我们通过edit，改mas_msg.next指向init_task+0x290的位置，那么我们就可以读取将init_task中的内容作为msg_msgseg读出来，而init_task本质上是一个task_struct，其中有task_struct链表中指向下一项的指针，还有对应的pid。

我们通过一次edit+read可以读一个task_struct，每读一次用读到的task链表的next指针重新设置msg_msg.next通过重复这个过程，就完成了一个对于task_struct链表的遍历，我们的最终目标就是找到当前进程对应的task_struct结构体。

当我们找到当前进程对应的task_struct的位置之后，只需要劫持task_struct中的两个关键指针，即可完成权限提升：

我们通过offset定位这两个指针在 &task_struct + 0x538 和 0x540 的位置。

首先我们针对idx = 1再来一次UAF，构造出一个可控制的msg_msg：

我们配合userfaultfd机制，利用 msgsnd 触发一段对mmap后没有初始化的内存的copy操作。启动userfaultfd的handler。

在handler中，我们edit对应的msg_msg结构，主要目的是修改其next指针为&task_struct + 0x538 - 0x8的位置，相当于伪造出一个msg_msgseg。

紧接着在handler中恢复对应的未初始化的内存为我们构造的恶意数据。

恢复之后，msgsnd 继续，此时将对应的用户态的恶意数据拷贝到内核态，最终在对于我们伪造的msg_msgseg赋值的过程中，实际上覆写了当前task_struct结构体的real_cred 、 cred指针。使其指向了具有全局root权限的init_cred。完成权限提升。

我的exp：

本题是上一题的进阶版本。

主要改变在：

Rule_t中没有那个0x800大小的desc了，这样导致我们的对象大小发生了变化，在内核中变成了0x30大小，属于kmalloc-64 。

前面的利用过程都有点像，不同的是我找到了一个比官网WP更稳定的内核全局数据 dynamic_kobj_ktype 方便在不进行 shm_file_data 喷射的情况下拿到内核基地址。

这一部分利用过程比较复杂。我会配合原文的图片进行说明。

在main函数的一开始，我们先注册两个userfaultfd，起两个handler，这两个我们后面都会用到。

之后我们构造创建两个msg队列一个UAF

此时，在针对qid发送消息的时候，会将我们释放的rule从kmalloc-64中再拉回来，变成了上方的msg_msg#1。而通过对这个msg_msg的m_ts的劫持，进而可以实现任意（越界）读。

通过越界读，我们可以读到以下内容：

dump对应的数据：

接下来像上一题一样，扫描task_struct链表，找到当前进程的task_struct，读出pid，cred *。

接着上面的步骤，我们通过从qid_1的队列中不设置MSG_COPY的读取消息，让我们的msg_msg出队后被放入kmalloc-4k

可以看到，通过两次读取我们将qid_1队列中的msg_msg以及msg_msgseg进行了释放。

在这些工作都结束后，我们新开一个线程，调用 allocate_msg1

在allocate_msg1 中，再创建一个新队列qid_2。然后取出被free到kmalloc-4k的。通过 msgsnd操作，我们将msgsnd要发送的用户态的数据的地址设置为：page_1 + PAGE_SIZE - 0x10 ，那么他在copy_from_user的时候会被卡在未初始化的 page_1 + PAGE_SIZE 也就是 FAULT_PAGE 。

可以看到，由于SLAB分配器LIFO的性质，我们 msgsnd 的时候首先把先前 msg_msg#2的msg_msgseg从kmalloc-4k中取出来了，接着申请出的是先前的msg_msg#2。等于说这个链表在一次free一次重新申请之后反向了。然后放置上了对应的控制头数据，然而当我们继续向下放置消息数据的时候，就会触碰到 FAULT_PAGE，也就是 page_1 + PAGE_SIZE的位置。

此时copy_from_user被挂起，接下来，userfaultfd_1中启动的page_fault_handler_1捕捉到对应地址为FAULT_PAGE的userfault 。

进入while大循环首先确认我们捕捉到的地址是否是我们想要的 FAULT_PAGE 的地址。

在本函数中，我们会卡在 if(release_pfh_1) 这里，我们想要达到的目的是在恢复这个pagefault之后，使next指针指向cred结构体地址-0x8，相当于伪造当前进程的cred结构体为一个fake msg_msgseg。

接下来，我们的重点放在如何构造任意地址free。我们调用 arb_free 函数，在此函数中首先进行一次UAF write，劫持我们堆上的第一个msg_msg的next指针，让他也指向对应的msg_msgseg

然后调用msgrcv，导致上图的MSG #0和最右侧的msg_msgseg被free掉。

注意，指向msg_msgseg的除了正常的msg_msg（qid_2），还有第一次的msg_msg（qid）中的next指针。

也就是说，这个操作结束之后，msg_msg（qid_2）的next指针指向了一个被free的区域（kmalloc-4k），并且他认为这是他的msg_msgseg。

接下来，我们再起一个 allocate_msg2 。

在本函数中，我们再新建一个队列qid_3 。同时再开一个FAULT_PAGE_2再构造另一个pagefault。（page_2），然后调用msgsnd卡住这个copy_from_user。

注意，上一张图被我们free到kmalloc-4k的会被再次申请出来作为msg_msg（下图中蓝色的），那么此时我们就构造出两个msg_msg链式相连的结构了。

而在 page_fault_handler_2 会重启第一个pagefault的恢复工作。

回忆一下，我们第一个page fault是卡在从用户态向内核态队列msg_msg中拷贝数据的过程。

当此过程恢复后，此时next指针是指向PAGE_FAULT_2对应的msg_msg的。也就是说会发生从用户态向蓝色的区域对应的msg_msg拷贝数据。如果我们控制好拷贝的数据，那么可以实现修改next指针，指向cred结构体。

在 page_fault_handler_2 中等待 page_fault_handler_1 恢复完毕。然后再对PAGE_FAULT_2进行恢复。

当 page_fault_handler_2 运行完了，PAGE_FAULT_2也被恢复。针对PAGE_FAULT_2的msgsnd中的copy_from_user操作接触阻塞继续执行，此时由于我们已经劫持了next = cred，那么在拷贝到msg_msgseg的时候，实际上就转换成了了针对cred结构体的劫持（写操作）。此时的cred结构体像一个fake msg_msgseg。

至此，整个流程结束。

这一部分由于exp实在太长，而且很乱，我就不放上来自己完整的了。如果想学习的可以去看官方的exp（链接已在开头给出），实在是比我写的整齐太多。

在Linux内核中，如果我们可以控制kernel heap上的 struct msg_msg ，并且允许用户态自定义userfaultfd的使用，且内核开启了 CONFIG_CHECKPOINT_RESTORE 时。可以利用struct msg_msg 以及其后续的 struct msg_msgseg 结构，通过调整MSG_COPY标签，调用 msgsnd 完成内核态分配操作与写操作；调用 msgrcv 完成内核态释放操作与读操作。进而可以构造任意地址读写的原语；以及通过构造恶意的msg_msg链表，可以构造出任意地址释放的原语。最终根据具体情况不同，可以用于内核态的漏洞利用。

https://blog.csdn.net/guoping16/article/details/6584024

https://www.cnblogs.com/52php/p/5862114.html

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)