一

简介

红雨滴团队的《CVE-2023-28252在野提权漏洞样本分析》文章详细的分析了恶意文件并定位到漏洞触发点，但由于文章的主要目的是分析恶意文件而非讲解漏洞成因，因此漏洞成因方面的内容偏少。该文的主要内容是分析clfs.sys内的函数，以了解漏洞触发过程。由于笔者刚入门，如果文章出现错误，请多多包涵。

二

实验环境

◆Windows 10 22H2

◆IDA

三

CLFS

简述

通用日志文件系统（Common Log File System，缩写CLFS）是一个通用目的的日志文件系统，它可以从内核模式或用户模式的应用程序访问，用以构建一个高性能的事务日志。

文件格式

文件格式的类型定义可以参考ionescu007的文章，下面进行简单介绍。
元数据块类型为6种，其中Shadow块为备份块，当主块存在异常时，会使用Shadow块。类型定义如下：

typedef enum _CLFS_METADATA_BLOCK_TYPE
{
    ClfsMetaBlockControl,
    ClfsMetaBlockControlShadow,
    ClfsMetaBlockGeneral,
    ClfsMetaBlockGeneralShadow,
    ClfsMetaBlockScratch,
    ClfsMetaBlockScratchShadow
} CLFS_METADATA_BLOCK_TYPE, *PCLFS_METADATA_BLOCK_TYPE;

每个元数据块都以CLFS_LOG_BLOCK_HEADER结构起始，后面跟着元数据块特有的结构与数据，简单示意图如下：

该漏洞涉及ClfsMetaBlockControl和ClfsMetaBlockGeneral块，其涉及的主要类型定义如下：

typedef struct _CLFS_LOG_BLOCK_HEADER
{
    UCHAR MajorVersion;
    UCHAR MinorVersion;
    UCHAR Usn;
    CLFS_CLIENT_ID ClientId;
    USHORT TotalSectorCount;
    USHORT ValidSectorCount;
    ULONG Padding;
    ULONG Checksum;
    ULONG Flags;
    CLFS_LSN CurrentLsn;
    CLFS_LSN NextLsn;
    ULONG RecordOffsets[16];
    ULONG SignaturesOffset;
} CLFS_LOG_BLOCK_HEADER, *PCLFS_LOG_BLOCK_HEADER;

typedef struct _CLFS_CONTROL_RECORD
{
    CLFS_METADATA_RECORD_HEADER hdrControlRecord;
    ULONGLONG ullMagicValue;
    UCHAR Version;
    CLFS_EXTEND_STATE eExtendState;
    USHORT iExtendBlock;
    USHORT iFlushBlock;
    ULONG cNewBlockSectors;
    ULONG cExtendStartSectors;
    ULONG cExtendSectors;
    CLFS_TRUNCATE_CONTEXT cxTruncate;
    USHORT cBlocks;
    ULONG cReserved;
    CLFS_METADATA_BLOCK rgBlocks[ANYSIZE_ARRAY];
} CLFS_CONTROL_RECORD, *PCLFS_CONTROL_RECORD;

typedef struct _CLFS_BASE_RECORD_HEADER
{
    CLFS_METADATA_RECORD_HEADER hdrBaseRecord;
    CLFS_LOG_ID cidLog;
    ULONGLONG rgClientSymTbl[CLIENT_SYMTBL_SIZE];
    ULONGLONG rgContainerSymTbl[CONTAINER_SYMTBL_SIZE];
    ULONGLONG rgSecuritySymTbl[SHARED_SECURITY_SYMTBL_SIZE];
    ULONG cNextContainer;
    CLFS_CLIENT_ID cNextClient;
    ULONG cFreeContainers;
    ULONG cActiveContainers;
    ULONG cbFreeContainers;
    ULONG cbBusyContainers;
    ULONG rgClients[MAX_CLIENTS_DEFAULT];
    ULONG rgContainers[MAX_CONTAINERS_DEFAULT];
    ULONG cbSymbolZone;
    ULONG cbSector;
    USHORT bUnused;
    CLFS_LOG_STATE eLogState;
    UCHAR cUsn;
    UCHAR cClients;
} CLFS_BASE_RECORD_HEADER, *PCLFS_BASE_RECORD_HEADER;

其中ClfsMetaBlockGeneral块包含容器类型，且容器的pContainer成员为内核对象指针，因此如果可以控制该成员，则将为执行任意代码打下基础。其结构定义如下：

typedef struct _CLFS_CONTAINER_CONTEXT
{
    CLFS_NODE_ID cidNode;
    ULONGLONG cbContainer;
    CLFS_CONTAINER_ID cidContainer;
    CLFS_CONTAINER_ID cidQueue;   //队列标识符
    union
    {
        CClfsContainer* pContainer;   //指向描述容器类的内核对象
        ULONGLONG ullAlignment;
    };
    CLFS_USN usnCurrent;
    CLFS_CONTAINER_STATE eState;
    ULONG cbPrevOffset;
    ULONG cbNextOffset;
} CLFS_CONTAINER_CONTEXT, *PCLFS_CONTAINER_CONTEXT;

之前在CVE-2022-24521漏洞复现过程中，简单编写了一个010 Editor的模板，可以简单解析日志文件(.blf格式文件)，便于了解文件结构布局，后续可在附件中下载。

四

漏洞利用分析

漏洞通过 CreateLogFile和AddLogContainer 函数进行触发，接下来将根据构造的日志文件内容梳理这两个函数的执行流程。为了便于理解clfs.sys的函数，首先将ionescu007文章中的CLFS相关结构体整理成了头文件，并加载到IDA中。

CreateLogFile处理流程

《CVE-2022-37969 技术分析》中说到当在用户空间调用CreateLogFile函数时，CLFS!CClfsRequest::Create负责处理这个请求。当使用 CreateLogFile 函数打开现有基本日志文件时，将在 CLFS.sys 中调用函数CClfsLogFcbPhysical::Initialize ，并随后调用CClfsBaseFilePersisted::OpenImage。接下来将从OpenImage函数开始进行分析。

OpenImage首先进行初始化操作，如申请内存。

图：OpenImage部分代码

OpenImage中调用了CClfsBaseFilePersisted::ReadImage函数，这里提前说明下函数做了哪些后续要关注的工作。26行将this+0x28赋值为6，27行为this+0x30 申请内存空间，45行调用CClfsBaseFile::GetControlRecord获取控制记录的地址。控制记录为_CLFS_CONTROL_RECORD结构，为ClfsMetaBlockControl块的第二个结构体。

图：ReadImage部分代码

随后OpenImage函数的131行调用CClfsBaseFilePersisted::ReadImage函数加载日志文件，获取控制记录结构地址，加载成功后从142行代码开始执行。146行调用CClfsBaseFile::GetBaseLogRecord函数获取基本日志记录地址，该返回值为_CLFS_BASE_RECORD_HEADER指针，指向ClfsMetaBlockGeneral块的第二个结构体，随后在149-157行使用基本日志记录初始化数据。当控制记录的eExtendState不为0，iExtendBlock小于4，iFlushBlock小于6且大于等于iExtendBlock，cExtendStartSectors小于文件扇区总数量，cNewBlockSectors小于扩展元数据块的扇区总数量加上（iExtendBlock/2）时，将在179行调用CClfsBaseFilePersisted::ExtendMetadataBlock函数。

图：OpenImage部分代码

ExtendMetadataBlock函数98行根据参数2（iExtendBlock）加载元数据块，然后获取控制记录指针。当控制记录的eExtendState成员值为2时，跳转到LABEL_41。

图：ExtendMetadataBlock部分代码

192行检测eExtendState值是否为2，不为2则退出循环。随后在208行使用iFlushBlock作为参数2调用CClfsBaseFilePersisted::WriteMetadataBlock函数（本次调用该函数时，参数2被指定为了4，用于扩展ClfsMetaBlockScratch块，这一过程只是为了过渡到FlushControlRecord函数的调用）。随后209行检测iFlushBlock与iExtendBlock值是否相同，相同则v12复制为0，从而在下次for循环时，从192行的检测中退出循环。循环最后调用了CClfsBaseFilePersisted::FlushControlRecord，这个函数需要重点关注。

图：ExtendMetadataBlock部分代码

FlushControlRecord函数在处理部分数据后，于23行调用了CClfsBaseFilePersisted::WriteMetadataBlock。

图：FlushControlRecord代码

WriteMetadataBlock函数在31行根据参数2获取指定元数据块的地址，然后进行了部分数据的更新，此时更新的元数据块是iFlushBlock字段指定的。61行调用了ClfsEncodeBlock处理块数据，并在67行调用CClfsContainer::WriteSector将写入块数据，这两个函数是漏洞利用的关键前置步骤。需要注意的是，ClfsEncodeBlock和WriteSector操作的是参数2指定的元数据块，本次参数2为0，即操作的是ClfsMetaBlockControl块。

图：WriteMetadataBlock部分代码

ClfsEncodeBlock先将_CLFS_LOG_BLOCK_HEADER的Checksum 成员值置为0，然后调用ClfsEncodeBlockPrivate函数进行下一步处理。当ClfsEncodeBlockPrivate返回结果为负数时，则不会重新计算校验和并返回。

图：ClfsEncodeBlock代码

ClfsEncodeBlockPrivate检测_CLFS_LOG_BLOCK_HEADER的ValidSectorCount是否小于TotalSectorCount，如果小于则返回错误码0xC01A000A。

图：ClfsEncodeBlockPrivate部分代码

回顾WriteMetadataBlock函数的61行代码，可以发现并没有对ClfsEncodeBlock的返回值进行判断，而是直接调用WriteSector函数将更新数据。假设ValidSectorCount小于TotalSectorCount，执行ClfsEncodeBlock时则首先将校验和置为0，然后ClfsEncodeBlockPrivate检测到异常，返回错误码0xC01A000A，因此ClfsEncodeBlock不会更新校验和。随后直接调用WriteSector函数将指定元数据块的校验和的值更新为了0。

图：WriteMetadataBlock部分代码

将校验和值更新为0的目的在于绕过OpenImage中的检测。OpenImage的163~173行，检测了iFlushBlock和iExtendBlock的值是否大于6，当大于6时则会返回错误码0xC01A000D。简介文件格式时，提到过shadow块为备份块，当主块的校验和值为0时，则会检测失败，从而使用shadow块的数据，因此shadow块数据可以为大于6的数据，然后通过构造特定字段值，执行上述流程使校验和为0，下次获取元数据块则使用shadow块，下一部分内容会说明替换逻辑。

图：OpenImage部分代码

AddLogContainer处理流程

《样本分析》中指出WIN32API AddLogContainer对应内核中的CLFS!CClfsLogFcbPhysical::AllocContainer函数，下面将从AllocContainer函数入手分析。

AllocContainer函数的69行调用了CClfsBaseFilePersisted::AddContainer函数。

图：AllocContainer部分代码

AllocContainer函数的44行调用了CClfsBaseFilePersisted::AddSymbol函数。

图：AddContainer部分代码

AddSymbol函数中当v16 值为 0xC0000023时，会在26行调用CClfsBaseFilePersisted::ExtendMetadataBlock函数。v16为CClfsBaseFile::FindSymbol函数的返回值，因此关注FindSymbol函数。

图：AddSymbol代码

FindSymbol函数中没有发现0xC0000023错误码，但124行调用了虚函数，并且返回值为负数时将通过LABEL_26标记返回。使用windbg设置断点调试，最终确定该虚函数为CLFS!CClfsBaseFilePersisted::AllocSymbol()。

图：FindSymbol部分代码

在AllocSymbol中的25行发现了错误码0xC0000023，其触发条件为当前容器的结束地址大于签名缓冲区地址。当前容器的结束地址根据_CLFS_BASE_RECORD_HEADER结构的cbSymbolZone成员值计算得到，因此可以修改cbSymbolZone值使其满足条件返回错误码0xC0000023，从而在AddSymbol中调用ExtendMetadataBlock函数。

图：AllocSymbol代码

此时执行流程为：
AllocContainer -> AddContainer -> AddSymbol -> FindSymbol -> AllocSymbol //返回错误码0xC0000023
AllocContainer -> AddContainer -> AddSymbol -> ExtendMetadataBlock //根据错误码0xC0000023，调用ExtendMetadataBlock函数

ExtendMetadataBlock函数105行调用CClfsBaseFile::GetControlRecord获取控制记录地址（_CLFS_CONTROL_RECORD），控制记录存在于ClfsMetaBlockControl块中。在CreateLogFile执行过程中，通过构造特定的字段使的CreateLogFile校验和为0，因此本次获取的控制记录实则为ClfsMetaBlockControlShadow块的。下面分析GetControlRecord函数，查看控制记录是如何被替换的。

图：ExtendMetadataBlock部分代码

GetControlRecord函数18行调用CClfsBaseFile::AcquireMetadataBlock函数加载ClfsMetaBlockControl块，随后进行一系列检查，最终将ClfsMetaBlockControl中CLFS_CONTROL_RECORD的地址写入到参数2。

图：GetControlRecord代码

AcquireMetadataBlock中调用了一个虚函数，在windbg中跟踪为CClfsBaseFilePersisted::ReadMetadataBlock函数。

图：AcquireMetadataBlock代码

ReadMetadataBlock函数31至52行代码读取参数2指定的元数据块到分配的池内存，随后在58行调用ClfsDecodeBlock函数进行解码（因为CreateLogFile函数处理流程中ClfsMetaBlockControl校验置为了0，因此该函数会返回错误码）。73行代码再次调用ReadMetadataBlock函数，加载当前元数据块的shadow块。随后通过一系列检查到达75行，此时v8小于0，将跳转到117行代码开始执行。117~122代码，释放了ReadMetadataBlock为当前元数据块申请的池空间，然后使用其shadow块地址代替当前元数据块。

图：ReadMetadataBlock部分代码

图：ReadMetadataBlock部分代码

ClfsDecodeBlock函数先判断校验和是否为0，这里为0然后跳转到16行继续判断。通过ReadMetadataBlock的函数调用可知a4值为0x10，然后MajorVersion值为0xF，因此该检测失败，直接返回错误代码 0xC01A000A。至此ReadMetadataBlock函数使用ClfsMetaBlockControlShadow块替换了ClfsMetaBlockControl块。

图：ClfsDecodeBlock代码

图：默认MajorVersion值

回到ExtendMetadataBlock函数，可以得知105行代码获取的实际为ClfsMetaBlockControlShadow块。随后通过检测，跳转到LABEL_41处。

图：ExtendMetadataBlock部分代码

跳转到LABEL_41后，在208行调用了CClfsBaseFilePersisted::WriteMetadataBlock函数。需要注意的是ClfsMetaBlockControlShadow块中的iFlushBlock值为0x13，即WriteMetadataBlock的参数2值为0x13。

图：ExtendMetadataBlock部分代码

此时查看WriteMetadataBlock处理逻辑。31行代码使用24乘以参数2作为this+0x30的偏移，随后取得数据。在ReadImage中可以得知this+0x30的内存空间为0x90，而24*0x13结果为0x1C8，已经超出了0x90，从而取得了错误的地址。然后从错误地址的0x28偏移取得偏移B，然后将错误地址的偏移B的数据进行+1。此时通过漏洞已经触发，实现了数据自增1。

图：WriteMetadataBlock部分代码

任意函数执行

《样本分析》中指出CreateLogFile函数会调用CClfsBaseFilePersisted::CheckSecureAccess函数。CheckSecureAccess函数的55行起会遍历容器，然后64行获取pContainer值，并在69行和78行调用二次虚函数。因此可以创建一个日志文件，其包含了精心构造的容器，然后利用该漏洞修改容器的偏移，使其再次调用CreateLogFile时，遍历的容器为构造的容器，然后pContainer值指向用户空间中构造虚函数布局，这样调用虚函数时便可以执行我们想要执行的函数。由此构造函数利用链（函数利用链可以查看《CVE-2022-37969 技术分析》，该文章详细的介绍了相关内容），实现权限提升。

图：CheckSecureAccess部分代码

权限提升思路

权限提升过程涉及到池空间分配、利用管道属性实现任意地址写入等操作，这里仅简单介绍下思路，不在详细展开，具体过程可以查看《样本分析》。

1.创建一个包含容器的日志文件A，然后容器地址偏移0x100处构造一个pContainer成员有值的容器。

2.通过NtQuerySystemInformation查询0x7A00大小的CLFS数据池。

3.调用CreateLogFile函数将日志文件A加载到内核。

4.通过NtQuerySystemInformation查询0x7A00大小的CLFS数据池，查询到新增的池地址，这个地址为日志文件A的ClfsMetaBlockGeneral块地址（该块的大小为0x7A00）。

5.创建多个漏洞利用日志文件B，构造文件数据，使其最终可以在WriteMetadataBlock中实现越界数据访问，并进行数据自增。

6.构造池布局空间。申请大量的匿名管道，然后将13个日志文件A的ClfsMetaBlockGeneral块地址写入到管道，使其申请0x90的池空间。

7.关闭匿名管道，释放池空间，然后调用CreateLogFile函数将多个日志文件B加载到内核，然后在将13个日志文件A的ClfsMetaBlockGeneral块地址写入到管道，这样在日志文件B的clsfhelp（this+0x30）的周围就是构造的日志文件A的ClfsMetaBlockGeneral块地址。

8.构造函数执行内存布局。

9.调用AddLogContainer函数触发漏洞，修改日志文件A的ClfsMetaBlockGeneral块中rgContainer数据，使其容器偏移增加0x100。增加0x100的原因是利用漏洞增加的是后24位的数据，因此自增1，等于增加了0x100偏移。

10.调用CreateLogFile函数再次加载日志文件A，随后通过CheckSecureAccess函数利用构造的容器，然后根据函数执行内存布局利用管道属性，实现任意数据写入，然后替换了进程的TOKEN从而实现提权。

五

漏洞修复

根据上面分析可以得知触发漏洞是由于WriteMetadataBlock的ClfsEncodeBlock函数将校验和置为了0，然后在触发错误时，仍更新了ClfsMetaBlockControl块数据，从而导致下一次加载ClfsMetaBlockControl块时使用了导致越界访问的ClfsMetaBlockControlShadow块。因此修复后的WriteMetadataBlock函数在82行对ClfsEncodeBlock的返回值进行了检测，在出现异常时不调用WriteSector函数，从而使得ClfsMetaBlockControlShadow不会被使用。《样本分析》中描述了其他的修复内容，这里就不再重复陈述。

图：修复后的WriteMetadataBlock部分代码

参考

https://mp.weixin.qq.com/s/Qlst6CX_z1A698Tvvx-bIQ（CVE-2023-28252在野提权漏洞样本分析）

https://github.com/ionescu007/clfs-docs/（CLFS格式）

https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part（CVE-2022-37969 技术分析 上）

https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part2-exploit-analysis（CVE-2022-37969技术分析 下）

球分享

球点赞

球在看

原文始发于微信公众号（看雪学苑）：CVE-2023-28252 CLFS 提权漏洞分析