CVE-2023-36900 clfs.sys 提权漏洞分析

概述

2023年8月8日，微软 patch thuesday 发布新补丁后，我们观察到 Windows Common Log File System Driver 模块修复了一个 Elevation of Privilege 类型的漏洞https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36900， 通过分析补丁目前已经写出了 POC。

分析环境

• windows 10 版本 10.0.19045.3208
• x64 dbg，windbg，IDA Pro 7.5

补丁对比

通过补丁对比分析在 CClfsBaseFilePersisted::ExtendMetadataBlockDescriptor(ulong,ulong) 函数中发现新增了一处校验，该函数用于扩展元数据块。

使用 IDA 分析补丁前后代码变化发现新增了一处校验【3】，在校验【3】之前可以看到原本已经存在一处校验【1】。分析函数 CClfsBaseFilePersisted::ExtendMetadataBlockDescriptor 的功能后发现【1】处的校验用于检查添加的扇区数乘扇区大小后不会溢出，且加上原元数据块大小后也不能溢出。在【1】处的校验通过后会在【2】处将现元数据块大小与扇区大小对齐，【2】处的对齐操作在原元数据块大小是已经与扇区大小对齐的情况下没有什么问题，可是在原元数据块未与扇区大小对齐的情况下此对齐操作就可能存在整数溢出，从而导致对齐后的现元数据块小于原元数据块大小并在后面的元数据块扩展时崩溃。

扩展元数据块。

POC 开发

元数据块在存储到文件时理应是与扇区大小对齐的，但是除了控制块元数据块的大小外其他两种元数据块的大小我们是可以通过操作日志文件中存储的数据来控制的。这样当我们控制 CLFS_CONTROL_RECORD->eExtendState、CLFS_CONTROL_RECORD->iExtendBlock、CLFS_CONTROL_RECORD->iFlushBlock 使流程来到 CClfsBaseFilePersisted::ExtendMetadataBlockDescriptor 函数时，只需将相应的元数据块设置为一个非对齐的大小且将要添加的扇区数设置的足够大时便为产生整数溢出。

整体代码如下：

BSOD

1: kd> k
 # Child-SP          RetAddr               Call Site
00 ffffb98e`089902e8 fffff807`72b162c2     nt!DbgBreakPointWithStatus
01 ffffb98e`089902f0 fffff807`72b158a6     nt!KiBugCheckDebugBreak+0x12
02 ffffb98e`08990350 fffff807`729fc1c7     nt!KeBugCheck2+0x946
03 ffffb98e`08990a60 fffff807`72a4b2f5     nt!KeBugCheckEx+0x107
04 ffffb98e`08990aa0 fffff807`7286e7b0     nt!MiSystemFault+0x1b2905
05 ffffb98e`08990ba0 fffff807`72a0bbd8     nt!MmAccessFault+0x400
06 ffffb98e`08990d40 fffff807`71becfe4     nt!KiPageFault+0x358
07 ffffb98e`08990ed8 fffff807`71c3169f     CLFS!memset+0xa4
08 ffffb98e`08990ee0 fffff807`71c3128e     CLFS!CClfsBaseFilePersisted::ExtendMetadataBlockDescriptor+0x1ff
09 ffffb98e`08990f90 fffff807`71c19dc4     CLFS!CClfsBaseFilePersisted::ExtendMetadataBlock+0x40e
0a ffffb98e`08991060 fffff807`71be1dba     CLFS!CClfsBaseFilePersisted::OpenImage+0x418
0b ffffb98e`089910e0 fffff807`71c107a2     CLFS!CClfsLogFcbPhysical::Initialize+0x326
0c ffffb98e`08991220 fffff807`71c11fab     CLFS!CClfsRequest::Create+0x75e
0d ffffb98e`08991370 fffff807`71c11d77     CLFS!CClfsRequest::Dispatch+0x97
0e ffffb98e`089913c0 fffff807`71c11cc7     CLFS!ClfsDispatchIoRequest+0x87
0f ffffb98e`08991410 fffff807`728113a5     CLFS!CClfsDriver::LogIoDispatch+0x27
10 ffffb98e`08991440 fffff807`7280d964     nt!IofCallDriver+0x55
11 ffffb98e`08991480 fffff807`72bffabb     nt!IoCallDriverWithTracing+0x34
12 ffffb98e`089914d0 fffff807`72c1571e     nt!IopParseDevice+0x11bb
13 ffffb98e`08991640 fffff807`72c0d3ea     nt!ObpLookupObjectName+0x3fe
14 ffffb98e`08991810 fffff807`72bfd5db     nt!ObOpenObjectByNameEx+0x1fa
15 ffffb98e`08991940 fffff807`72bfc299     nt!IopCreateFile+0x132b
16 ffffb98e`08991a00 fffff807`72a0f8f5     nt!NtCreateFile+0x79
17 ffffb98e`08991a90 00007fff`af24da84     nt!KiSystemServiceCopyEnd+0x25
18 000000af`893cf928 00007fff`9a742199     0x00007fff`af24da84
19 000000af`893cf930 00000000`00000000     0x00007fff`9a742199