kctf-2023 第九题 突破防线 98k战队wp

引言

后面两段主要是逆向和内核两位大手子写的

本题叠buf式的考点让几位师傅隔着各种远程投屏互相帮忙调了几个通宵，无数次都在祈求出题人收了神通，不过最后还是做出来了。没打过内核，当时并不觉得把静态c程序exp改成shellcode可以很有可行性，随口提了一句，结果几位大爹说还真可以，属于歪打正着了，最后和IChild大爷被几个socket调用调戏了一通宵到精神恍惚。不知道是否有能在禁止execve/at的情况下更为精妙的可行思路。

大体流程：

1.利用用户态漏洞进行 rop 和布置 shellcode-seg1
2. rop 利用 mprotect 调用成功运行小段 shellcode-seg1
3.在 shellcode-seg1 中用 socket 操作读入大段 shellcode-seg2 （这段直接来自于打内核的 exp binary），并完成场景还原和跳转
4.跳转运行 shellcode-seg2 完成内核漏洞的利用（精神污染），篡改 busybox 的 poweroff 逻辑
5.杀 vm 进程，在防止内核崩掉（需要一点处理）的情况下让 init 高权限顺序执行 poweroff ，利用 8080 端口反弹信息。

程序分析

用户态程序 vm 是 go 语言写的，在 的帮助下顺利恢复函数名，再手动恢复下自定义结构体的信息就能得到程序逻辑。

开了 sandbox ， dump 出来发现是禁用了 execve 和 execveat 。开了个 http server ，有三个接口，每个接口的输入格式都是 main.Req 的 json 形式。提取出来逻辑如下：

ioctl 调用说明这里要跟内核交互了。逆内核模块 vmfs ，得到几项功能：

create 会对 Size 做检测，不能大于 0x10000

mov_to_trash 会将 list 中已有的项添加到 trash 中，并释放分配的数组内存，但是没有置为空

delete_from_trash 将 trash 中的一项彻底删除，并将 list 中对应项释放掉并且置为空

set_data 和 get_data 就是向分配的数组中写入数据和拿出数据

sort 会对 list 中的项目排序，不同 method 值采用不同的排序算法。其中当 method = 3 时采用选择排序，而选择排序不是稳定的排序算法，即不能保证排序之前值相同的项在排序后保持相同的顺序，再结合 mov_to_trash 就可以 double free 。不过这是内核的利用部分了，用户态程序是没有 ff01 的接口的，需要先找用户态程序的漏洞。

在内核模块初始化时会自动添加一条 list 中的记录：

Size 为 0x10000 ，而用户态程序可创建的最大大小为 0x8000 ，如果只是看用户态程序是没问题的，而添加的这一条记录就给用户态程序带来了漏洞，因为 run-file 会将数据从内核复制到用户态程序中，用户态程序并没有检查 Size 的大小，用来保存数据的栈内存只有 0x8000 字节（即 4096 个 uint64 ），如果从内核里复制出来的长度大于 0x8000 字节就可以覆盖栈上数据，先覆盖的是 vm 执行时的 memory 结构体，覆盖指针、长度就可以任意读写；再之后是上层函数的 lr 指针，再后面是当前函数的参数，因为函数返回之前要调用第一个参数的一个虚表函数，所以需要设置为一个程序里的值。再后面就是随便栈溢出构造 rop 了。 arm 的 rop 不太好做，不过幸好能找到这样一条 gadget ,大概是类似于x86的 setcontext 的用法：

再结合 go 程序里自带的 syscall 函数，加上前面的任意地址读写，加上程序没开 pie ，可以直接在 bss 段写入 shellcode 之后调用 mprotect 改 bss 段权限，再跳转到 shellcode 执行，在 shellcode 中调用 accept 得到与用户交互的 fd ，这样就可以读取更多的 shellcode 用于执行，这样就可以进入到内核利用了。

接下来就是这题比较恶心的点了。调试时首先循环 read 4 号 fd ，发现不阻塞且无法得到大于 0 的结果。最后关掉 4 ，然后用对 socket fd 3 调用 sys_accept ，调了半天还是 accept 不进来，最后发现原来是 accept 不阻塞。最后循环 accept 和 recvfrom ，才开始稳定读取 shellcode 并利用。

由于禁用掉了 execve 和 execveat ，于是只能把用来打内核的 exp 的 binary 给读出来，作为 shellcode 来执行。 mmap 出代码段，即 exp 中的 0x23300000 和 stack 段，全部内存 dump 进去还原现场，设置完 sp 和 pc ，最后从 start 开始执行

Kernel Module Exploitation

周二事情比较多，加上俺也确实不太会逆向，所以专业的事情让专业的逆向爷爷来做。所以当我真正上手这个题的时候逻辑好像跟我无关了。

在我的视角中，只知道有内核菜单堆的几个功能，其中 0xff01 的 free 之后还留着 Dangling Pointer。并且，这个 Dangling Pointer 还会在选择排序之后被换位... 然后就是... Double Free~

补充一点：选择排序是一种不稳定的排序算法。在这个题中，选择排序会导致相同 id 不同 idx 的两个 object 位置发生交换。当其中一个已经是 Dangling Pointer 的时候，进行选择排序，再尝试 free 另一个 object。因为发生了交换，所以第二次 free 的还是原来的那个 object。这就构成了 Double Free。

POC 如下：

于是接下来就进入到常规 Linux kernel exploitation 的环节。Double Free 在内核堆利用中算是比较好利用的一种，而且这个题还可以控制 double free object 的大小，所以思路应该有很多。比如用直接用 tty_struct 泄露+ROP。

不过俺之前被 aarch64 的 ROP 整怕了，而且也不知道新内核里面 gadget 够不够用，思来想去还是别赌了，还是打稳定一点的 cross-cache 吧...

思路呢就和去年 N1CTF 的 Praymoon 差不多。指路牌 ->

这里简单概括一下：

1. 通过 sock 构造 order 0 的页风水。可以参考 。当然，嫌麻烦 pipe_buffer 也能构造出来，但是后面的利用会用到 pipe_buffer，所以不想搞混了。
2. 释放掉 sock 获取的奇数页面，分配 pipe_buffer 以占据。
3. 释放掉 sock 获取的偶数页面，先用 vm_area_struct 占用一点，再用题目的漏洞结构体占用一点。所以页面布局大概就是下面这样。
4. 第一次 free vuln_object，用 user_key_payload 再占回来；第二次 free vuln_object，再用 vuln_object 占用回来（题目的 vuln_object 还挺好用，居然可以往里面写东西，感动）。这样就可以修改 user_key_payload 的 datalen 字段以实现溢出读。又因为 vm_area_struct 里面有 list_head 结构，所以很容易泄露出堆地址。同样的也泄露出了 pipe_buffer 们的地址。
5. 将 double_free 从 vuln_object 转移到 pipe_buffer。这里用的是 (感谢 CorCTF 两位大爹)。结合我们已经泄露出的堆地址，我们用 poll_list 占据步骤 4 中用完释放的 user_key_payload。此时步骤 4 中分配的 vuln_object 和 poll_list 占用同一块空间，所以利用 edit 功能把 poll_list->next 改到 pipe_buffer 上，就可以构造 pipe_buffer 的 UAF 了。
6. 利用和 pipe_buffer 同在 kmalloc-cg 的 msg_msg 结构体（两年不见，你还好吗）就可以修改 pipe_buffer 的 flag 了。
7. 最后就是喜闻乐见的 提权了。修改 busybox 的 halt_main 函数，就可以在 init.sh 执行到 poweroff 的时候以 root 身份执行 shellcode。

一切都看起来很简单，俺也在 6 个小时的时间内调通了内核 exp。此时正是凌晨 4 点，用户态那边也基本弄完了，一切都在向好的方向发展...

所以，为什么俺们又从早上搞到了晚上 9 点呢？

联合调试

前情提要，用户态 vm 开了 seccomp，ban 掉了 execve 和 execveat。如果只是一个用户态题目，rop 执行 orw 也就结束了，但是... 我们还有一个内核 exp 的二进制需要上传执行。没有 shell，怎么传？传不了一点。

和用户态爷爷（还是 IChild）商量了一下，可以在用户态执行 shellcode 之后，就可以给我 mmap 一段 rwx 内存，我就可以手动把二进制文件"加载"到内存中，然后执行。(WHO NEEDS EXECVE? UH?)

单步跟了一下，发现问题出现在栈上。 libc_start_main 会从栈上拿 env。所以，我们这次把一个合法的栈也拷贝进内存了。

然后。。。继续 SegmentFault。。。 WTF？？？

而且这次死的地方十分玄学，死在内核 exp 刚刚进去的 mmap syscall 中，也就是程序进了 mmap syscall 中再也没出来。。。

于是果断地拉来了巨神，在巨神的指导下把 aarch64 的 strace 编译好放到了 rootfs 里面，运行...

“这个 SIGURG 是你预期的吗？”

“【黑人问号】哪来的 SIGURG?”

“但它就是被 SIGURG 杀了...”

于是在 shellcode 里面 handle 了一下 SIGURG（此处省略 4 个小时。。。）

...

终于在马拉松式的调试一天之后，成功改完了 busybox，复用 8080 端口 nc -e 拿到了反弹的 root shell！