2022 ciscn实践赛西南赛区半决赛只有两道pwn，一道简单vm栈溢出，还有一道1解kernel。

因为题目没有泄露函数，所以我依赖msg_msg构造越界读&任意写的原语，同时借助pipe_buffer完成内核地址泄露。

笔者对msg源码进行了浅要的剖析，有基础 or 对源码不感兴趣 的读者可自行选择跳过。

消息队列是Linux的一种通信机制，这种通信机制传递的数据具有某种结构，而不是简单的字节流。消息队列的本质其实是一个内核提供的链表，内核基于这个链表，实现了一个数据结构。

可以通过消息队列实现进程间通信等。

/include/linux/msg.h中有关于msg_msg结构体的定义：

其中list_head为双向链表结构体，储存next和prev指针：

在ipc/msgutil.c中有对msg_msgseg的定义，还有申请msg_msg结构体的函数：

可以看到msg_msgseg就是一个嵌套的结构体指针。

其中参数含义：

调用msgget函数会创建新的消息队列，或者获取已有的消息队列，若创建新的消息队列，会创建一个msg_queue结构体当消息队列msg_msg双向循环链表的起始节点。

需要注意的是后续若某进程调用msgsnd函数对消息队列进行写操作，需要该进程有写权限；同理msgrcv需要有读权限。这是由msgget函数中的第二个参数中的权限控制符所决定的。

引自Roland师傅的图：（概括性的，若读者不想看我对源码的分析可以直接参考这个表）

调用 msgsnd 系统调用在指定消息队列上发送一条指定大小的 message 时，会建立msg_msg结构体。

查看实现msgsnd系统调用的do_msgsnd函数部分源码：

查看load_msg函数：

调用了alloc_msg函数分配空间，同时将用户数据拷贝到内核msg_msg队列中。

再查看alloc_msg函数：

从该函数源码我们可以知道：

通俗点来说，msg_msg和msg_msgseg结构体最大size均不能超过page_size：

最后单个msg_msg消息会形成如下的单向链表结构：

而msg_msg之间则是用list_head 来链接，形成的是以msg_queue为首节点的双向循环链表结构，大致如下：

申请msg_msg的调用链：

同样引自Roland师傅的图：（进行了一点小更正）

msgrcv系统调用能从消息队列上接受指定大小的消息，并且选择性（是否）释放msg_msg结构体。

具体实现源码在/ipc/msg.c的do_msgrcv中。

该函数中源码中使用了内核源码中常见的一个宏定义：list_for_each_entry。该宏定义可以理解为一个for循环。

它实际上是一个 for 循环，利用传入的 pos 作为循环变量，从表头 head 开始，逐项向后（next 方向）移动 pos，直至又回head。

该循环遍历了msg_queue为首节点的双向循环链表，也就是遍历了所有msg_msg队列的头节点。

然后调用testmsg，根据mode和传入的msgtyp来筛选：

其中mode由convert_mode决定：

综合起来，可以看到用户是通过控制msgtyp来控制do_msg_rcv拷贝/取得 哪条队列信息：

特例：MSG_COPY位为1的时候，mode为SEARCH-NUMBER,在find_msg中会返回msg_msg双向循环链表中，第msgtyp个msg_msg，也就是返回第msgtyp条消息，而不是上述表格中根据msgtyp去和msg->m_type进行匹配。

在/ipc/msg.c中do_msgrcv：

内核首先会调用 list_del() 将其从 msg_queue 的双向链表上 unlink，之后再调用 free_msg() 释放 msg_msg 单向链表上的所有消息。

在do_msg_rcv函数最后，调用了msg_handler，看参数像是进行内核-->用户的数据拷贝。

其中msg_handler是do_msgrcv传进来的参数，是一个函数指针，向上看调用do_msgrcv的调用链：

可知msg_handler具体函数指针为do_msg_fill：

其中调用store_msg进行数据拷贝：

可以看到拷贝过程和之前msg_msg结构内存申请相对应：

ps：拷贝结束的标志均为seg->next指针为NULL

拷贝的总长度则由msgsz决定，而msgsz：

可以看到若bufsz足够的情况下，拷贝数据总长度是由msg->m_ts决定的。

需要注意的是，若我们带有MSG_COPY标志，则不会在双向链表上unlink，只会进行copy操作，具体实现在do_msgrcv中部分源码：

若有MSG_COPY标志，源码注释：If we are copying, then do not unlink message and do not update queue parameters.

不会调用list_del()去进行unlink，并且最后free_msg()释放的是我们在内核中copy出来的堆块。也就是说，我们可以通过设置MSG_COPY多次读取一条消息。

在通过find_msg定位一节已经讲过：

MSG_COPY位为1的时候，mode为SEARCH-NUMBER,在find_msg中会返回msg_msg双向循环链表中，第msgtyp个msg_msg，也就是返回第msgtyp条消息，而不是上述表格中根据msgtyp去和msg->m_type进行匹配。

由于MSG_COPY位为1的时候，内核会调用prepare_copy再申请一块内存出来。

申请内存大小为我们传入do_msgrcv的bufsz。

两个msg_msg之间的拷贝则由copy_msg负责，而在copy_msg函数中有一段代码如下：

若源src->m_ts大于目标dst->m_ts,则会发生溢出，因此会直接返回不会拷贝。

同时copy_msg函数末尾还有赋值操作：

因此我们要满足的条件是src->m_ts<=dst->m_ts即可。

即bufsz>=src->m_ts。

经过对源码的阅读和分析，可以想到我们可以做到的事情：

(1)改掉msg_msg->m_ts。

可以读取最多一页的内存，实现越界读。

(2)改掉msg_msg->m_ts和msg_msg->m_list中的next指针。

可以利用堆喷其他结构体+msg_msg越界读，获得一些堆地址 or 内核地址。

可以堆喷一些一些消息队列，每个消息队列上只有一条消息：即msg->queue双向循环链表里只有一个节点：

可以通过某个msg_msg的越界读，有几率读到其他消息队列的msg_msg的m_list字段，而我们构造每条消息队列上只有一条消息

，泄露其m_list，即为msg_queue的地址。泄露完之后，继续伪造msg_msg->next字段可泄露整个该消息队列中每个结构体的地址。

可以实现任意地址读。

但是需要注意的是，我们需要伪造我们需要读的地址target的next指针为NULL，不然在store_msg进行数据拷贝的时候，是以NULL指针为结束判断条件，因此我们需要满足target->next==NULL or target->next->next==NULL，反正需要我们伪造的任意读链表存在一个NULL节点，且中途不能到达不可读地址，否则会造成kernel panic。

在do_msgsnd函数中调用了load_msg进行用户到内核的数据拷贝，若我们利用userfault机制暂停一个线程，再在另一个线程中篡改掉msg->next指针，则可以实现任意地址写。

模板采用的arttnba3师傅的模板：

pipe是Linux系统跨进程通信的一种方式。管道是连接一个读进程和一个写进程，以实现它们之间通信的共享文件。基于pipe族系统调用实现(而非open())。而这个文件不是真正的文件，向管道文件读写数据其实是在读写内核缓冲区。

pipe() 创建一个管道，一个可用于进程间通信的单向数据通道。 数组 pipefd 用于返回两个指向管道末端的文件描述符。 pipefd[0] 是管道的读端fd。 pipefd[1] 是管道的写端fd。 写端把数据写入管道，直到读端读取数据。

管道不需要open，但需要close释放。

定义在/include/linux/pipe_fs_i.h中：

size为0x30。

在建立管道时，内核首先会申请一个pipe_inode_info结构体，然后在其pipe_inode_info->buf字段申请pipe_buffer结构体：

其中PIPE_DEF_BUFFERS=16；因此会申请0x10*0x30(size of pipe_buffer)的内存，也就是会从kmalloc-1k中取。

主要关注其release指针，在我们关闭一个管道的两端之后，管道会被释放，同样pipe_buffer也会被释放。调用的是函数表中的release指针。调用路径为：free_pipe_info->pipe_buf_release

pipe_buffer中的*pipe_buf_operations成员能泄露内核基地址。

PS：需要注意的是，利用pipe系统调用后需要调用一次写管道才能对函数表进行初始化：

覆写pipe_buffer->pipe_buf_operations->release为某些栈迁移指针。将rsi-->rsp。

题目开启了KPTI,SMAP,SMEP等正常保护。

内核版本：

从5.11内核版本开始，就禁止非特权用户使用userfaultfd了。所以这道题是userfaultfd版本最后的荣光 (bushi

在kernel_release函数中存在指针未清零的情况：

但是kernel_open函数判断了flag字段：

因此我们无法调用两次kernel_open后利用kernel_release的指针悬挂，来造成0x100 size的一个object的UAF。

但是由于kernel_read和kernel_write，kernel_open与kernel_release均未加锁，且read与write中含有类似于如下的copy_to_user操作：

因此我们可以考虑使用userfaultfd卡住当前进程，在另外一个线程中调用kernel_release。这样同样可以达到一个0x100 size的UAF。

所以笔者是考虑用这个简单的洞来泄露内核基址，用的是0x100 size对应的timerfd_ctx结构体。

不过笔者用这种方法无论如何都无法泄露出内核基址，后来咨询arttnba3师傅后得知：

内核调用fput对文件描述符进行释放，对于文件描述符的关闭会被delay，直到我们读取数据后才会关闭。

因此靠这种操作leak内核数据是不可行的。

程序除了module自身的open，release，read，write操作。

提供了简单的菜单堆功能：

所有功能都未加锁，因此可以用userfaultfd在edit时将进程卡死，在另一个线程中free掉这个堆块后申请某些object到该地址上，实现0x400 size object的UAF（只能更改一次值）。

申请一个消息队列，上面只放一条消息，且size为0x400。同时申请一个pipe_buffer。

改大msg_msg->m_ts，用带有MSG_COPY位的msgrcv进行越界读，泄露出pipe_buffer上的函数表。

得到内核基址。

leak内核地址分别消耗了一次add,delete,edit操作。因此我们还有一次UAF的机会。

笔者最先考虑的是用pipe_buffer提权，刚好满足0x400的size，因此我们利用UAF将pipe_buffer->pipe_buf_operations->release函数指针更改为某个栈迁移gadget即可。

但是我并没有找到可利用的gadget，其中有一条可能能达成的：

不过retf是按32位pop eip和cs，的，而32位根本不足以储存一个内核地址。

同时还有例如mov esp,esi类型的gadget，由于intel x86&x64的调用约定，当对32位寄存器进行赋值操作的时候，会将高32位寄存器值清零，因此也不可用。

同时注意到程序没有开启CONFIG_STATIC_USERMODEHELPER保护，因此笔者选择用UAF劫持0x400 size的freelist到modprobe_path附近，更改modprobe_path。

笔者是申请msg_msg结构体申请到modprobe_path附近，由于size太大，会将modprobe_path附近的所有内容全部清空。

直接进行接下来的提权or 读取flag操作会在成功前引起kernel panic，因此我们需要恢复modprobe_path附近的函数指针。

其中，kmod的函数指针恢复是必要的：

因为modprobe_path是一个Linux程序，最初由Rusty Russell编写，用于在Linux内核中添加一个可加载的内核模块，或者从内核中移除一个可加载的内核模块，因此modprobe是安装某个内核模块，而kmod是一个用于控制linux内核模块的程序，因此在后续调用中需要用到

最后直接利用modprobe_path_hijack更改flag权限后读取即可。

这里由于gcc编译的poc文件过大，远程超时，因此我选择musl-gcc进行编译。

但是奇怪的是，按理来说两种编译方式不会对poc造成影响，gcc的可以正常运行，而musl-gcc在modprobe_path_hijack后，第一次调用system时，内核会panic在slub里。

估计是system系统调用execve申请内存时，寄在了某一个没有修复好的freelist里，但是我的这种解法，应该是无法修复freelist的。

后续选择uclibc进行编译就成功了。如果有读者了解为什么musl-gcc编译出来会有这种情况，请务必教教我。

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