“我希望这一路经历过的艰难,到最后不要让我意难平”
0x00背景
从微软的描述上可知该漏洞是在2022/03/08时候被披露,并且是CD-ROM 驱动中存在漏洞,可导致特权提升。
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-24455
0x01补丁对比
要进行补丁对比的主要思路就是把未打补丁和打了补丁的文件进行对比,看看哪些函数进行了修改,从而推测去漏洞的关键位置所在。好了,根据我们所了解的信息,我们只知道这是CD-ROM中存在漏洞,哪里这个文件是在哪里呢?
毕竟这是微软的驱动,我们还是要找微软的文档去进行查阅,很快,我通过查阅找到了这个链接。
"When the operating system enumerates a CD-ROM device, it loads a native CD-ROM class driver (Cdrom.sys). This driver exposes an I/O control request (IOCTL) interface. All public I/O control codes for drivers of CD-ROM devices use buffered I/O. Consequently, the input or output data for these requests is at Irp->AssociatedIrp.SystemBuffer. For more info, see CD-ROM I/O control codes"
https://docs.microsoft.com/en-us/windows-hardware/drivers/storage/cd-rom-drivers
通过这个描述我们知道了CD-ROM 类驱动程序是Cdrom.sys,并且驱动程序公开一个 I/O 控制请求 (IOCTL) 接口,这就意味着我们通过IOCTL的形式就能够从用户态进入到内核。
接下来我们只需要下载了patch的补丁KB5011485,再用未修补的补丁就是对比。下载补丁的方式在下面。
https://www.catalog.update.microsoft.com/Search.aspx?q=KB501148
我们把新旧的cdrom.sys拖进IDA的bindiff进行对比,关于如何进行补丁对比这里不再阐述了
通过补丁对比,可以看到函数RequestHandleVolumeOnline进行了明显的修改
0x02触发漏洞到BSOD
上面我们说过这个漏洞是通过IOCTL来触发的
在Windows中,如果根据IOCTL来从用户层进入到内核层,可以通过WINAPI DeviceIoControl来实现通信,该函数定义如下:我们可以看到第二个参数就是IOCTL
BOOL WINAPI DeviceIoControl(
__in HANDLE hDevice,
__in DWORD dwIoControlCode,
__in_opt LPVOID lpInBuffer,
__in DWORD nInBufferSize,
__out_opt LPVOID lpOutBuffer,
__in DWORD nOutBufferSize,
__out_opt LPDWORD lpBytesReturned,
__inout_opt LPOVERLAPPED lpOverlapped);
通过逆向分析知道IOCTL为0x56C008或者0x56C064时,可以进入到漏洞函数
通过构造特定的数据就能触发BSOD(自己可以尝试通过一些方法去触发),很抱歉文章到这里就结束了,因为这个CVE他是一个很旧的漏洞,不像是win32k 这类常见的驱动模块(当然现在还有Windows 通用日志文件系统 (CLFS)、NTFS驱动等等...),我没有浪费太多时间在这里,如果你想学习更多关于Windows Kernel的漏洞,后续我仍会介绍一些win32k常见的漏洞模型。
如果你能把上面这些简单看完了,我希望你能大概了解到:如何通过微软的披露找到存在漏洞的驱动、再通过存在漏洞的驱动找到存在漏洞的函数、然后再想办法触发,一步步的递进,如果你能学习到这个简单的想法,那么太棒了。
以下是存在漏洞的BSOD
原文始发于微信公众号(墨雪飘影):Windows CVE-2022-24455 从补丁对比到BSOD
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论