CVE-2023-2008复现笔记
CVE-2023-2008复现笔记
mb_btcapvow 看雪学苑 2024-09-09 17:59
commit：2c85ebc57b3e1817b6ce1a6b703928e113a90442
总的config：
defconfig+menuconfig
(同样是修改了objtool的一个代码)
此外还需要在init脚本中给普通用户赋一个可以打开/dev/udmabuf文件的权限。
然后需要没有cg隔离，复现版本v5.10.0刚好不存在cg隔离；（笔者在复现时尽量认为是隔离的，不使用这一特性，本cve比较特殊，需要用到pipe）
在分配dmabuf的时候，内核会调用 dma_buf_export函数，其中传入一个dma_buf_export_info结构体来传递相关参数信息，该结构体的定义如下：
dma_buf_export函数内容大致如下：
之后还会调用dma_buf_fd等和文件相关的操作，最后返回给我们一个文件描述符；
当然我们重点要关注这里有一个分配页面空间的部分：
如上述代码所示，这里给pages分配了一个指针数组，请记住，后边这里会出现漏洞；
这里我们需要注意的是dmabuf有一个ops成员，这是一个函数表，上面有若干函数指针：
当我们对dmafd调用mmap时就会调用到mmap_udmabuf函数，下面我们简单看其代码：
总的来看就是我们可以在kmalloc分配的obj上越界写内核地址；
memfd_create
ftruncate
memfd_create+udmabuf
在使用udmabuf
设备之前，需要先使用memfd_create
创建一个内存文件，然后才能创建 DMA buffer（dmabuf）。这是因为memfd_create
和udmabuf
的组合提供了一种机制，将用户空间内存区域转换为可用于 DMA（直接内存访问）操作的缓冲区。以下是这种操作顺序的原因及其背后的机制。
1.memfd_create 提供匿名共享内存：
◆memfd_create
用于创建一个匿名的、基于内存的文件，这个文件存在于内存中，而不是存储在磁盘上。
◆创建的内存文件可以通过文件描述符（file descriptor, FD）进行访问，并支持类似文件的操作（如mmap
、write
、read
）。
◆内存文件提供了一块用户空间的内存区域，可以安全地共享和管理。这对于在多个进程之间共享数据或跨设备传递内存数据非常有用。
2.udmabuf 将内存文件转换为 DMA 缓冲区：
◆udmabuf
是一个 Linux 驱动程序，它的主要功能是将一个用户空间的内存区域（通常是通过memfd_create
创建的内存文件）转换为可以供 DMA 使用的缓冲区。
◆当你通过memfd_create
创建内存文件后，你得到一个文件描述符，这个描述符引用了一个匿名的、驻留在内存中的文件。
◆这个文件描述符然后被传递给udmabuf
，udmabuf
设备将这个内存文件映射为 DMA 缓冲区。这样，内核中的 DMA 引擎（或其他硬件设备）就可以直接访问这块内存。
udmabuf使用接口
预定义：
memfd_create及其相关处理：
打开设备文件：
然后通过设备文件获取一个udmabuf：
通过mmap进行映射：
通过mremap进行扩展：
笔者在写这部分的时候已经完全复现成功该漏洞；
依据复现过程来看，似乎是dmabuf一经创建就会在其数组中写入若干个内核地址，然后mmap时会与用户空间进行映射，而mremap似乎并没有对这个数组做任何处理，仅仅是放宽了边界条件，使得我们访问的时候不算越界；导致我们越界访问的时候会自动读取数组下面的非法数据作为page_struct；
那么问题来了，这个dma访问内存是否还是一句页表呢？看起来这个访问映射似乎与页表逻辑是不相符的；那么ops函数表中的函数对mmap到底是怎么处理的呢？
源代码路径：
mmap的操作很简单，就是简单的赋值；
笔者个人感觉是，最开始分配了一些内存（分配物理页，但是要用虚拟地址管理），mmap的时候只分配虚拟地址，并在页表项中设置，到时候第一次访问就会走udmabuf_vm_fault进行物理内存的映射：
所以可能是mmap写了多少项页表，我们才能访问多少项，这个限制了越界，而mremap则是只修改了页表项，没有扩展这个数组；
这个kmalloc_array函数是在udmabuf_create函数中被调用的，且在内核中被调用的次数比较少，我们可以直接下断点：
笔者先分配dmabuf、然后喷射内核密钥，之后再扩展dmabuf，似乎并没有越界写内核地址：
似乎可以写入一个内存地址实现USMA攻击？
这个pages所指向的应该是page_struct结构体；
我们可以在创建dmabuf之后喷射pipe并set_size，（本环境下没有cg隔离）这样dmabuf下面就会出现一个pipe的page_struct结构体，我们就有了使用用户态地址读写pipe的page的能力了，然后我们将对应的pipe关闭，那么这个page就会被释放掉；
现在我们有了一个能够制作UAF-page的能力，但是应该如何将这个page申请出来呢？
pipe页未成功释放原因探究
经过调试发现，是因为我们的pipe->ops这个函数表为空，导致了无法成功释放我们的page；
笔者在gdb中将其手动修改之后即可成功命中：
而直接调试发现，我们命中的pipe_buffer一开始是有ops的：
然而到了release的时候这个ops指针就被清空了：
这不得不让笔者想起来之前有一个pipe_read，这个read似乎也调用了一些类似的函数。
果然，==如果不读这个pipe，我们的ops就仍然存在==；
现在仍然回到了原来无法重用的问题，继续探究，最终发现是目标物理页的refcount是2，导致close之后没有成功将其free掉；为什么会是2呢？
终于找到了原因，我们==利用dma首次读取该页内容会导致该页的引用计数增加==：
所以不能通过读dma来获取命中的id，必须盲测；
问题最终得到解决：
我们不对pipe set_size了，就用原来的四则，此时要求我们的dmabuf的个数分别为初始的0x80和扩展后的0x100，然后我们给每个pipe写入超过0x1000字节的数据，用dmabuf越界读pipe的第二个页用来泄露idx，然后再用第一个页作为命中用；
我们关闭命中的pipe之后，set_size，可以成功将释放的物理页喷射出来，然后作为某一个pipe_buffer：
至此，我们有了任意读写pipe_buffer的能力了！
LEAK
此时我们可以通过读pipe_buffer中的内容，泄露page_struct的地址和内核代码段的地址；
如果还能有一个可控的内核堆地址，我们就可以利用pipe_buffer劫持控制流进而提权了；
其实也可以利用dirty_pipe直接进行攻击；（但是笔者内核版本有点低，本身就有dirty-pipe，这样似乎有点不雅观。）
本来还想用seq_file的，但是太浪费文件描述符了，命中率很低；
可以构造两次cve的利用，想用pg_vec，但是无奈pg_vec使用太多物理页了，我们释放的物理页一不小心就成了pg_vec映射的物理页了，根本没机会用来构造pg_vec；
其实我们只需要有个结构能够泄露一个我们可控的地址就行了；
栈迁移
KPTI
pipe制造UAF页调试关键看refcount；（包括之前的多进程共享pipe，也一定是导致了refcount的增加）。
参考
FINAL-EXP
exp.c（https://bbs.kanxue.com/CVE-2023-2008.assets/exp.c）
pg_vec.h（https://bbs.kanxue.com/CVE-2023-2008.assets/pg_vec.h）
page.h（https://bbs.kanxue.com/CVE-2023-2008.assets/page.h）
key.h（https://bbs.kanxue.com/CVE-2023-2008.assets/key.h）
msg.h（https://bbs.kanxue.com/CVE-2023-2008.assets/msg.h）
参考
bluefrostsecurity/CVE-2023-2008: Proof of concept code for CVE-2023-2008 (https://github.com/bluefrostsecurity/CVE-2023-2008)
CVE-2023-2008 – Analyzing and exploiting a bug in the udmabuf driver | Bluefrostsecurity（https://labs.bluefrostsecurity.de/blog/cve-2023-2008.html）
看雪ID：mb_btcapvow
https://bbs.kanxue.com/user-home-975602.htm
*本文为看雪论坛精华文章，由 mb_btcapvow 原创，转载请注明来自看雪社区
# 往期推荐
2、恶意木马历险记
球分享
球点赞
球在看
点击阅读原文查看更多