简介

CLFS全称为Common Log File System，即通用日志文件系统，自 Windows Vista 和 Windows Server 2003 R2中被引入用于构建高性能事务日志以来，使用者可以通过CLFS提供的API对日志进行创建、存储、读取等操作。在过去几年内，CLFS中出现过诸多漏洞，其中不乏有已经被在野利用的漏洞，CVE-2022-24521是微软4月修复的一个CLFS.sys驱动程序中的在野利用漏洞，本文将从介绍CLFS基本结构开始，对CVE-2022-24521漏洞进行分析，希望能够帮助读者了解CLFS以及其带来的不安全性。

01 CLFS前置知识

在分析CLFS漏洞之前需要了解CLFS日志文件的基本数据结构，在此方面笔者更多地得益于ionescu007的精彩分享[1]。用户可通过CreateLogFile函数来创建日志文件，函数执行后会在本地创建一个同名的后缀为.blf的日志文件，CLFS会将文件的数据加载进内存中进行解析处理。每个日志块以日志块头部_CLFS_LOG_BLOCK_HEADER开始，其定义为：

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;

这里重点关注下Checksum、RecordOffsets和SignaturesOffset，Checksum是该日志块数据的校验和，在读取数据时会对该数据进行校验，采用的是CRC32的校验方式，对应函数为CCrc32::ComputeCrc32：

__int64 __fastcall CCrc32::ComputeCrc32(const unsigned __int8 *const data, int size)
{
v2 = 0i64;
v3 = size;
for ( i = -1; v3; --v3 )
{
v5 = data[v2];
v2 = (v2 + 1);
i = (i >> 8) ^ CCrc32::m_rgCrcTable[i ^ v5];
}
return ~i;
}

RecordOffsets保存每一个记录的偏移值，第一个记录与BlockHeader相连，偏移为sizeof(CLFS_LOG_BLOCK_HEADER)，也就是0x70；SignaturesOffset字段保存了一块内存的偏移值，日志在编码时每0x200字节的最后两个字节将被签名所覆盖，被覆盖前的数据将存放在SignaturesOffset字段所计算偏移的内存中：

do
{
DataStore += 2i64;
v16 = 0x20;
v17 = 0x40;
if ( *(record + 4) - 1 != v15 )
v16 = 0;
if ( v15 )
v17 = 0;
v18 = v17 | v16;
v19 = v15 << 9;
LOBYTE(Signatures) = a4 | v18;
++v15;
*(DataStore - 2) = *(v19 + record + 0x1FE);// store previous data
*(v19 + record + 0x1FE) = Signatures;     // write Signatures
}
while ( v15 < v10 );
v12 = *(record + 0x10);

当解码时再将这段内存中保存的数据写回到原来的区域，编码和解码对应的函数分别为ClfsEncodeBlock和ClfsDecodeBlock。

接下来是日志文件的元数据块，在日志文件中有6个不同的元数据块，分别为Control Record、Base Record、Truncate Record以及三个对应的shadow blocks。在每个元数据块开始也会有一个_CLFS_LOG_BLOCK_HEADER用来保存一些基本信息。Control Record的定义为：

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;

其中_CLFS_METADATA_BLOCK定义为：

typedef struct _CLFS_METADATA_BLOCK
{
union
{
PUCHAR pbImage;
ULONGLONG ullAlignment;
};
ULONG cbImage;
ULONG cbOffset;
CLFS_METADATA_BLOCK_TYPE eBlockType;
} CLFS_METADATA_BLOCK, *PCLFS_METADATA_BLOCK;

这里保存了元数据块的大小、偏移、类型等重要数据。

Base 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;

其中cActiveContainers保存了当前活跃的容器数，rgContainers数组则保存容器上下文的偏移值。用户可以使用AddLogContainer函数向日志中添加容器，容器对应的上下文结构为：

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;

重点关注CClfsContainer字段，该字段在内存中指向CClfsContainer类的对象指针，因为这是一个内核指针，所以不会返回给磁盘的日志文件中，以避免信息泄露。当在内存加载时，CClfsBaseFilePersisted::LoadContainerQ函数中会调用容器类构造函数CClfsContainer::CClfsContainer将返回的对象指针赋值给该字段。

02 漏洞分析

CVE-2022-24521漏洞点位于CLFS.sys的CClfsBaseFilePersisted::LoadContainerQ函数中，当容器队列cidQueue值为-1时，会调用CClfsBaseFilePersisted::RemoveContainer函数，而由于CClfsBaseFilePersisted::RemoveContainer内部会引用pContainer字段，为防止用户在磁盘上破坏此数据，系统有意在调用前将pContainer字段置为0：

v41 = v38->cidQueue;
if ( v41 == -1 )
{
v38->pContainer = 0i64;
v20 = CClfsBaseFilePersisted::RemoveContainer(this, v30);
...
}

在CClfsBaseFilePersisted::RemoveContainer经过取值与校验后将调用CClfsBaseFilePersisted::FlushImage函数，而后将调用pContainer对象中存储的函数：

v11 = CClfsBaseFilePersisted::FlushImage(this);
v9 = v11;
v16 = v11;
if ( v11 >= 0 )
{
pContainer = containerContext->pContainer;
if ( pContainer )
{
containerContext->pContainer = 0i64;
ExReleaseResourceForThreadLite(*(this + 4), KeGetCurrentThread());
v4 = 0;
(*(*pContainer + 0x18i64))(pContainer);
(*(*pContainer + 8i64))(pContainer);
v9 = v16;
goto LABEL_20;
}
goto LABEL_19;
}

查看pContainer对象的构造函数CClfsContainer::CClfsContainer，可以看到*pContainer处存放其虚函数表：

*this = &CClfsContainer::`vftable';

查看虚函数表可以看到+0x18，+0x8偏移处分别为CClfsContainer::Remove与CClfsContainer::Release函数。继续跟进CClfsBaseFilePersisted::FlushImage函数，其内部将执行CClfsBaseFilePersisted::WriteMetadataBlock函数，在该函数中，首先会遍历每一个容器上下文，将pContainer先保存后置为0：

for ( i = 0; i < 0x400; ++i )
{
v20 = CClfsBaseFile::AcquireContainerContext(this, i, &containerContext);
v15 = this + 8 * i;
if ( v20 >= 0 )
{
*(v15 + 0x38) = containerContext->pContainer;
containerContext->pContainer = 0i64;
CClfsBaseFile::ReleaseContainerContext(this, &containerContext);
}
else
{
*(v15 + 0x38) = 0i64;
}
}

然后调用ClfsEncodeBlock函数，对数据进行编码，此时记录中每0x200字节的后两个字节将被写入到SignaturesOffset指向的内存中，接着调用CClfsContainer::WriteSector函数，然后调用ClfsDecodeBlock函数对数据进行解码，并将之前保存的pContainer值重新写回：

ClfsEncodeBlock(RecoderHeader, *(RecoderHeader + 4) << 9, *(RecoderHeader + 2), 0x10u, 1u);
v10 = CClfsContainer::WriteSector(
*(this + 0x13),
*(this + 0x14),
0i64,
*(*(this + 6) + 24 * v8),
*(RecoderHeader + 4),
&v23);
if ( v7 )
{
ClfsDecodeBlock(RecoderHeader, *(RecoderHeader + 4), *(RecoderHeader + 2), 0x10u, &v21);
v17 = (this + 0x1C0);
do
{
if ( *v17 && CClfsBaseFile::AcquireContainerContext(this, v6, &containerContext) >= 0 )
{
containerContext->pContainer = *v17;
CClfsBaseFile::ReleaseContainerContext(this, &containerContext);
}
++v6;
++v17;
}
while ( v6 < 0x400 );
}

以上流程看似不存在安全问题，但实际上CClfsBaseFile::AcquireContainerContext函数并不能执行成功，因为在执行CClfsBaseFilePersisted::FlushImage前会将rgcontainer数组中该容器偏移值置0：

CLFS!CClfsBaseFilePersisted::RemoveContainer+0xb9:
fffff807`807b6ef9 4283a4a72803000000 and   dword ptr [rdi+r12*4+328h],0 ds:002b:ffffde8e`b6d12398=00001528

CLFS!CClfsBaseFile::AcquireContainerContext+0x7f:
fffff807`807c245f 8b94b928030000  mov     edx,dword ptr [rcx+rdi*4+328h] ds:002b:ffffde8e`b6d12398=00000000

所以该pContainer指针并不能得到保护，而在调用ClfsEncodeBlock函数编码阶段，由于没有对_CLFS_LOG_BLOCK_HEADER中的SignaturesOffset字段进行合法校验，用户可以提前修改SignaturesOffset使其与_CLFS_CONTAINER_CONTEXT中pContainer指针相交，导致该字段指向的内存在编码时被写回覆盖pContainer指针，当FlushImage函数执行完毕，将调用pContainer的虚函数，攻击者通过对其进行伪造，可以达到任意函数调用的目的。对于漏洞利用，可以查看在虚函数调用过程前后的汇编代码：

mov     rax, [rdi]
mov     rax, [rax+18h]
mov     rcx, rdi
call    cs:__guard_dispatch_icall_fptr
mov     rax, [rdi]
mov     rax, [rax+8]
mov     rcx, rdi
call    cs:__guard_dispatch_icall_fptr

rdi的值为pContainer可以由攻击者通过漏洞进行伪造控制，由于未开启SMAP，系统允许对用户内存空间进行访问，同时可以看到第一个参数rcx为rdi，所以只需要一些耐心寻找到合理的gadget，便可以实现权限提升。

在微软发布的四月补丁中，在CClfsBaseFilePersisted::LoadContainerQ函数执行开始加入了CClfsBaseFile::ValidateRgOffsets函数以此检测SignaturesOffset字段是否与其他上下文相交。

参考

[1] https://github.com/ionescu007/clfs-docs