原文链接：https://mp.weixin.qq.com/s/mkLjAyalo55PmdLbzMnX9g

注：以下所有涉及的数据结构根据参考资料整理得到，由于没有官方文档，所以可能存在未知或同名字段，但不影响此次漏洞分析。

CLFS(Common Log File System) 是一个日志框架，其他应用程序可以通过 CLFS 创建、保存和读取日志数据。“日志(log)”既可以表示一个抽象的概念，也可以表示一个物理上的文件，CLFS 对一条日志以及保存它的物理存储空间做了区分，因此物理空间的管理和日志的管理是分开的。CLFS 通过使用流(stream)和容器(container)在 NTFS 之上构建了一个虚拟的抽象层。

一个 CLFS 日志的存储由两部分组成：

包含元数据(metadata)的 base log file(BLF)
BLF文件大小通常为 64KB，但是可以根据需要增长，其中包含了日志存储所需的一些元信息，例如日志的起始位置、容器的大小和路径、日志名称、客户端信息等。考虑到日志恢复的需要，BLF 文件中包含了一份元数据的拷贝，使用 dump count 参数来识别哪份信息是最新的。

最多 1023 个包含真正数据的容器文件
容器是一个活动的日志流在空间上的基础分配单元，同一日志中的容器大小一致，是 512KB（一个扇区的大小）的倍数，最大为 4GB。CLFS 客户端通过增加和删除容器实现日志流的扩大和缩小。在实现时，CLFS 把容器当作 BLF 所在卷上的一个连续文件，通过在逻辑上将多个容器串在一起，形成包含一条日志的单个逻辑顺序磁盘区。初始化的时候一条日志至少要分配两个容器。

可以把整个日志存储看作是文件系统中一个卷的概念

CLFS 使用日志块对记录进行组织管理，每个日志块由多个 512 字节的扇区组成，之后对日志数据的读取和写入操作都在日志块上进行。

每个日志块的开头有一个 _CLFS_LOG_BLOCK_HEADER ：

当日志写入硬盘的时候，日志块会进行编码，编码状态的日志块中，每个扇区结尾处有一个 2 字节的扇区签名(sector signature)：

由于在编码阶段每个扇区的最后两个字节被改写成了扇区签名，因此需要对原始数据进行备份。日志块的最后一个扇区结尾处，有一个签名数组，这个数组中就保存了原始数据，由 _CLFS_LOG_BLOCK_HEADER 中的 SignaturesOffset 表示。

在写入日志的时候，可以比较每个扇区结尾签名位置的数据是否和签名数组中的数据一致来判断写入是否成功。

BLF 由六种不同的元数据块组成，每种元数据块只包含对应类型的数据，其中 shadow block 中保存的是对应元数据块的备份，同样使用 dump count 参数说明数据块的新旧。

Control Block：包含了有关布局(layout)、扩展(extend)区域以及截断(truncate)区域的信息

Base Block：包含了符号表信息，其中包括该BLF有关的客户端、容器和安全上下文信息

Truncate Block：包含了因为截断操作而需要对扇区进行更改的客户端信息，以及具体更改的扇区字节

Control Block Shadow

Base Block Shadow

Truncate Block Shadow

这里主要关注其中的 Control Block，这个日志块中的记录遵循以下数据结构：

其中的 cBlocks 表示整个文件中包含的日志块数量：

rgBlocks 中保存了每个日志块的大小信息：

对比 clfy.sys 文件发现只有 CClfsBaseFilePersisted::ReadImage 函数存在不同，仔细检查代码，发现修改主要位于 cBlocks > 6 的情况：

修复之后，如果 BLF 文件中 cBlocks 数值大于 6，ReadImage 函数会直接出错返回。

根据补丁分析结果，我们生成一个 BLF 文件，并手动将 cBlocks 修改成一个较大值 0x19（后期调试发现大于等于 0x20 无法通过检查），加载 BLF 文件后，系统崩溃（需要多次测试）。

查看此时的函数调用栈：

可以看到异常发生在 CLFS!ClfsEncodeBlockPrivate 函数中，在 IDA 中查看该函数：

合理猜测，clfs.sys 在通过 BLF 文件获取到 Block 的数量之后并没有进行验证，而是直接使用该值对后面的空间进行读取。

为验证该猜测，我们跟随函数调用栈到达函数 CClfsBaseFileSnapshot::CopyImage ，从代码看这里在对堆块进行循环编码：

在这个函数设置断点并重新开始调试，当代码执行到循环判断时：

这里在获取保存的 cBlocks 数值，可以看到系统在通过 ReadImage 读取 BLF 文件中存储的 cBlocks 数值之后，该数值并没有发生过更改，并直接在 CopyImage 中被使用。

现在已知漏洞是由于没有对 cBlocks 进行验证，但对于发生堆越界写时，写入的位置和内容还不清楚。

如果继续向下调试，到达获取 blockHeader 地址的位置：

可以看到地址 0xffffe60fc7415030 的位置存储了一个列表，根据数据内容判断，保存的就是 rgBlocks 信息。

在 CClfsBaseFilePersisted::ReadImage 函数中，如果 cBlocks 大于6，修复之前的函数会继续向下执行：

代码根据新的 cBlocks 数值分配了两个空间，大小为 24 x cBlocks 和 2 x cBlocks ，并分别放在了*(this+6)和*(this+7)的位置，除此之外还将 cBlocks 保存到了*(this+20)。之后将 BLF 文件中的 rgBlocks 列表复制到 pool1 所在空间，此时 pbImage 字段为 0。

但是 pool1 的地址并不是崩溃发生时 rgBlocks 列表所在的地址 0xffffe60fc7415030 ，因此在 ReadImage 中，this 指针指向的是一个 CClfsBaseFilePersisted 结构，而崩溃发生时，this 指针指向的是一个 CClfsBaseFileSnapshot 结构，*(this+6)中存储的空间地址并不相同。

根据结构名，找到函数 CClfsBaseFileSnapshot::InitializeSnapshot ，这里的 this 指针指向的同样是 CClfsBaseFileSnapshot 结构，同时发现了相同结构的一段代码：

这里根据对应日志块的 cbImage 循环分配了 cBlocks 个空间，由于 cBlocks 比实际值大，且 BLF 文件除 cBlocks 值之外没有做任何修改，因此系统认为后续 19 个日志块的大小为 0，ExAllocatePoolWithTag 分配了大小为 0 的空间，memmove 复制了大小为 0 的数据，最终保存到 pbImage 字段的地址是堆中一个未初始化空间的地址。

因此在系统执行到 ClfsEncodeBlockPrivate 时，blockHeader 指向的实际上是一块未初始化且大小为 0 的空间。

通过调试获取到分配的13 个日志块地址（剩余的 12 个日志块地址重复）：

其中前三个是正常的日志块，我们主要看后 10 个日志块的地址，使用 !pool 命令查看堆块情况，截取部分输出：

可以看到，虽然调用时请求分配的空间大小是 0，但实际上分配的是大小为 32 字节（包含头部）的堆块，且堆块都位于连续的一块空间中，且堆块头部数据相对固定：

也就是说，当相对于 blockHeader 进行取值时，如果偏移范围在 0x10-0x1F、0x30-0x3F、0x50-0x5F...，那么取到的数据就来自相对固定的头部数据，否则就来自未初始化的数据空间。

再次回到发生崩溃的函数，看一下涉及到的数据来源：

注：以下代码删除了一些细节，主要关注相对于blockHeader的偏移量

越界写的位置是 signatureArray - 2，主要受到偏移 0x68 位置的 signatureOffset 的影响；越界写的数据是 *(curSectorSize + blockHeader+ 0x1FE)，主要受到偏移 0x4 位置的 nSector 的影响，就是因为这里的数值太大才导致了崩溃的发生。

还有一些偏移位置的数据会影响程序流程，这里暂时不关注。

总结：

写入位置：blockHeader + *(blockHeader+0x68) + idx * 2

写入数据：*(blockHeader + idx*0x200 + 0x1FE)

根据上面对于堆块结构的分析，如果 blockHeader+【offset】 中 offset % 16 的结果是奇数，那么数据来源就是相对固定的堆块头部，否则数据来源就是未初始化的数据空间。

所以如果不考虑超出这块内存空间（即内部全部是0x10堆块的空间）的情况：写入数据所在的位置正位于堆块头部偏移 0x0E 的位置，该位置的数据绝大部分情况下均为 0x0000 ；写入位置可以通过类似堆喷射的方式进行控制。

通过以上分析可知，CVE-2022-30220 漏洞是由于对保存在堆块头部中的 cBlocks 字段的检查不够充分造成的，通过修改 BLF 文件中该字段数值，可以导致堆越界写的发生。由于堆空间结构的限制，越界写的位置与写入数据受到限制，如果想要进行漏洞利用，可能需要对堆空间结构更详细的分析，并通过修改BLF文件内容以及类似堆喷射的方式对数据进行控制。

CLFS Internals

https://github.com/libyal/libfsclfs/blob/main/documenation/Common%20Log%20File%20System%20(CLFS).asciidoc

Windows Internal editon 6th

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！