前言

本文分析一个去年出现在 refs.sys 的 Windows 内核漏洞: CVE-2024-49093. 测试环境基于Windows 11 24H2（Build 26100）。

背景知识

ReFS（Resilient File System）：是 Microsoft 开发的新一代文件系统，目标是最大化数据可用性、在多样化工作负载下高效扩展海量数据，并通过校验与修复增强数据完整性和抗损坏能力。ReFS 旨在解决不断扩展的存储需求，并为后续功能创新奠定基础。

在 ReFS 中，大多数对象以键值表的形式组织；其内部实现为 B+ 树，Microsoft 将该实现称为 MinStore B+。数据写入 ReFS 时不做就地更新，而是采取写时复制（Copy-on-Write，COW）：有效载荷保存在叶节点，修改时生成新的叶节点承接旧数据再应用变更，并自底向上以 COW 方式更新父节点指针直至根。

常驻 / 非常驻（resident / non-resident）：ReFS 将文件的名称、数据、ACL 等都抽象为“属性（attribute）”。当某个属性的数据较小即可内联存储于记录时称为 resident；否则切换为 non-resident，由一张 VCN→LCN 的运行列表（runlist）描述其落盘范围。

漏洞定位

官方公告：91cK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6E0M7%4u0U0i4K6u0W2L8h3W2U0M7X3!0K6L8$3k6@1i4K6u0W2j5$3!0E0i4K6u0r3N6i4m8V1j5i4c8W2i4K6u0V1k6%4g2A6k6r3g2Q4x3V1k6$3N6h3I4F1k6i4u0S2j5X3W2D9K9i4c8&6i4K6u0r3b7#2k6q4i4K6u0V1x3U0l9J5y4q4)9J5k6o6b7&6x3o6V1K6
根据公告可以知道补丁后的版本为10.0.26100.2605，定位到补丁：KB5048667。
借助993K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6E0M7%4u0U0i4K6u0W2L8h3W2U0M7X3!0K6L8$3k6@1i4K6u0W2j5$3!0E0i4K6u0r3N6i4m8V1j5i4c8W2i4K6u0V1k6%4g2A6k6r3g2Q4x3V1k6$3N6h3I4F1k6i4u0S2j5X3W2D9K9i4c8&6i4K6u0r3b7#2k6q4i4K6u0V1x3U0l9J5y4q4)9J5k6o6b7&6x3o6V1K6这个网站，搜索过滤条件为10.0.26100：

可见 10.0.26100.2454 大概就是修复前的累积版本。将补丁前后 refs.sys 比较（bindiff）：

补丁版仅新增两个函数，模式特征符合 WIL（Windows Implementation Library） 风格的“特性开关”检测。微软通过加开关而非直接改旧逻辑的方式修复，便于回滚与分阶段放量。
通过交叉引用，定位到被开关管控的函数：RefsAddAllocationForResidentWrite

漏洞成因分析

官方描述为 CWE-681: Incorrect Conversion between Numeric Types（数值类型转换不当）。
观察漏洞函数相关的反汇编代码：

通过动态调试，可以分析出第四个参数的结构体字段含义；分别是 WriteFile 写入时的偏移、偏移+写入长度指向的末尾、写入的长度。

漏洞函数分析

这个函数作用是什么？我们只分析 ReFS 版本 ≥ 3.11 的情况

函数处理驻留（resident）数据流的写入路径；阈值为 0x800（2 KiB）

当写入末端 ranges->end 未超过常驻阈值时：通过扩驻留满足写入。

当写入末端 超过常驻阈值时：把流从驻留转换为非驻留，返回 True，随后由 RefsAddAllocationForNonResidentWrite 执行真正的非驻留扩展。

代码中的 ccb 某字段（((WORD)ccb + 41)）用于在短时间多次写入时做指数式增长（最多+4），再以 0x20000 做上限收敛；这属于写入放大控制的实现细节，对我们分析这个漏洞没有太大影响。

漏洞分析

分析补丁前后的两个代码分支，可以很明显地看到差异点：对 end 使用 64 位（QuadPart）还是误用 32 位（LowPart）。
存在补丁的分支：

没有补丁（存在漏洞）分支：

也就是说，漏洞路径把本应 64 位的写入末端 end 截断成了 32 位 LowPart，然后用这个截断值去做阈值判断和尺寸更新，导致与实际数据范围不一致的问题。这与官方描述的 “数字类型之间的转换不正确” 吻合。

PoC

使用 ReFS 文件系统可能需要升级到工作站版，升级完毕后，需要创建一个 ReFS 格式的R盘。
依据上一步的漏洞分析，要触发漏洞我们只需要保证下面的两个条件：
(size + offset) 的 高 32 位不为 0（即写入末端跨过 4 GiB 边界）；
(size + offset) 的 低 32 位 < 0x800（让阈值判断落入“驻留仍可扩”的错误分支）。
可以非常容易写出下面的PoC代码：

崩溃栈：

但是错误码0x34的crash并不是由内存破坏导致的，而是触发了文件缓存管理器的断言检查（缓存路径在尺寸不一致时会触发断言），导致快速I/O失败，并不能用于漏洞利用。因此 PoC 需要在 CreateFileW 时加上 FILE_FLAG_NO_BUFFERING 走非缓存 I/O。
非缓存 I/O 在ReadFile/WriteFile时，长度和偏移需要满足下面的对齐条件：
传输长度必须是卷扇区大小的整数倍（如 512/4096）；
文件偏移必须从扇区对齐的偏移开始。
使用FILE_FLAG_NO_BUFFERING标志重新编写PoC代码：

我们可以通过打印数据流的信息观察到漏洞造成的效果（分配大小≪文件大小）：

复现时建议关闭 EDR/安全中心的“驱动器保护”，否则其后台扫描会触发大范围读取，导致越界访问后蓝屏。

漏洞利用

本文仅分析到如何在内核池中实现越界读/写为止。

越界读

之前的 PoC 已将文件的数据流保持为 resident，仅分配 0x200 字节，同时把文件的 EndOfFile 扩大到 0x100000200，制造了 AllocationSize ≪ FileSize 的不一致状态：真实可用数据区远小于文件声明的大小。
那么很自然地可以想到如果使用ReadFile读取一个大于0x200字节长度的数据，是否就能直接越界读了？

下面以读取 0x1000 为例。先写入 0x200 个 'A'，随后读 0x1000。如果 bytesRead == 0x1000，且 hexdump 打印中 0x200 之后仍有非零数据，即说明越界读成功。

打印结果：

可以看到确实越界读出了数据，那么这些数据从哪来、落在哪个内核池里？
调用栈：

下面分析RefsNonCachedResidentRead函数

该函数大致做了以下：
1.绑定事务并构造键（由 RefsInitializeScbAttributeKey 生成），用于在 MinStore B+ 表中定位常驻属性行；
2.MsFindRow(..., key, outRow) 搜索记录，并将页内行通过 CmsRowWithBuffer::CopyRow 拷贝到 outRow；
3.从inited 上获取拷贝的源指针Buffer，随后将 [valueOffset + a4->Offset, 长度 a4->Length] 直接 memmove 到用户缓冲。

但是从IDA的反汇编代码来看，MsInitRowWithBuffer只是把 inited 清零并让它的 storage 指向 0x20 字节的内联缓冲；为什么 MsFindRow 之后 inited->val_ptr 就成为一段可读的记录值？

这要结合调用约定和汇编看实参位置：

将初始化后的inited指针写到了[rsp+0x20h]，然后调用MsFindRow
MsFindRow:

在MsFindRow首先调整栈指针，然后将[rsp+70h]的值作为第四个参数，通过计算0x70 - 0x48 - 8 = 0x20，可以发现实际上MsFindRow的第四个变量其实就对应RefsNonCachedResidentRead函数的[rsp+0x20]，也就是inited指针。

继续分析MsFindRow，MsFindRow 仅仅是把参数原封不动传给 CmsTable::FindRow，而后者会 PinInIndex 找到页上对应的记录，再调用 CmsTable::OutputRow 生成一个 _CmsRow 视图，最终交给：

继续分析CmsRowWithBuffer::CopyRow函数：

直接从函数名来看CmsRowWithBuffer::CopyRow 函数的作用就是把 _CmsRow复制进 CmsRowWithBuffer.

初始时storage指针指向inline_storage数组，capacity为0x20。
CmsRowWithBuffer::CopyRow其中有很多计算key_ptr和val_ptr重叠和间隙的代码，这里暂不分析其作用；

现在主要分析if ( v12 > cmsBuffer->capacity )里的代码，前面提到每个CmsRowWithBuffer里面都有0x20字节的内联，如果val_len大于capacity，那么就会尝试从池内存新开辟一段内存，然后替换掉原来的storage指针，并更新capacity，flags用于标记之前是否已经申请过池内存了，如果为1，则还需要释放掉原先申请的池内存。

以之前PoC代码为例，第一步WriteFile写入的数据流长度为0x200，加上0x3C的头长度，8字节向上取整以后，由此ExAllocatePoolWithTag会在池中分配 0x250 字节。

最后CmsRowWithBuffer::CopyRow 会调用memmove将之前的数据拷贝到新的内存上，完成对cmsBuffer的拷贝，并返回给RefsNonCachedResidentRead；
RefsNonCachedResidentRead从cmsBuffer取出val_ptr指针，也就是CmsRowWithBuffer::CopyRow申请的池内存作为memove的src指针，拷贝的长度为ReadFile指针的size。

总结：我们可以利用漏洞制造一个AllocationSize ≪ FileSize 的不一致状态的文件，然后读取一个超过写入长度的数据造成OOB read。
由于非缓存I/O的限制WriteFile的size必须是扇区大小的倍数，且要小于常驻阈值0x800，因此能够申请的长度为0x200、0x400、0x600，那么能够越界读的池长度为0x260、0x460、0x660；

越界写

WriteFile能否像ReadFile那样直接进行越界写？下面分析写入时最关键的函数：

这里和读路径类似，RefsResidentWrite也是先由 RefsInitializeScbAttributeKey 构造行键；
这个函数同样有之前的IDA反汇编问题，实际上还封装了写入的范围__int64 v20[2]作为MsUpdateMetaRow的第五个参数，这俩个值分别为offset + scb->AttributeHdrLength和BytesToWrite。
之后调用MsUpdateMetaRow进行更新。

真正的数据写入位于CmsBPlusTable::UpdateInIndex，但在此之前会做一个边界检查：if ( *v6 + v13 > (unsigned __int64)(unsigned int)v23.row.key.ptr->RecordSizeBytes )，可以将其写为：

v23.row.key.ptr->RecordSizeBytes 来自当前常驻记录的“记录总大小”字段。
RecordSizeBytes 就是当前 resident 记录的总大小（约 = 0x3C + DataLen，再综合 8 字节对齐）。这行检查的含义为：WriteFile的范围是否落在这条 resident 记录的边界内？
正常情况下，比如在第一次写 0x200 后，内核会在第二次更大写入前对 resident 记录做预扩容（本质上是把记录重写一份更大的 COW 版本）。比如第二次要写的 0x400，则新的 RecordSizeBytes = 0x3C + 0x400 = 0x43C，因此检查能够通过。
但是在利用漏洞的情况下，我们绕过了常驻阈值并错误更新了 AllocationSize，没有触发 resident 记录的预扩容，于是 RecordSizeBytes 仍然是 0x23C（= 0x3C + 0x200）。此时第二次写 0x400，因此0x400 + 0 + 0x3C > 0x23C分支成立，因此检查未通过，WriteFile会报错The request is not supported.所以我们无法直接用WriteFile进行越界写。

我们现在重新回顾RefsAddAllocationForResidentWrite漏洞所造成的效果：通过64位截断绕过了常驻阈值的检查，然后用32位值去更新scb的AllocationSize；经过调试发现即使WriteFile返回了错误，AllocationSize也没有被回滚。
同时注意到当写入超过常驻阈值时，ReFS 会调用 RefsConvertToNonResident 把数据流从 resident 切换到 non-resident：

这个函数做的事情很直接：超过常驻阈值后，将常驻属性转换为非常驻。过程中它会按卷的扇区大小重新计算/对齐一个目标大小，为非常驻数据区开辟新内存，然后把原本常驻里的有效数据拷贝到这块新空间里，最后将文件数据流切换为非常驻表示。

基于此，可以尝试以下的利用链：
1.先写入一段准备越界写的数据（长度 < 0x800，确保 resident）；
2.通过漏洞将AllocationSize篡改为0
3.随后再发起一次较大写入，触发 RefsConvertToNonResident。

RefsConvertToNonResident 在为非常驻数据区计算目标长度/对齐时得到0，导致实际在池里只分到很小的块（0x20）。但拷贝逻辑仍然无条件把先前 resident 的有效负载拷贝到这块新空间——于是完成了OOB write。
下面是写入0x700长度的调试结果：
申请0 size的池内存：

向该pool拷贝0x700长度的数据，造成越界写

最终我们可以通过RefsConvertToNonResident非常驻内存转换实现了在0x20的池内存上进行最多0x800-0x10长度的OOB write。

总结

本文简要回顾了 ReFS 的基础（MinStore B+ 与 COW）、resident 与 non-resident 的差异，并通过补丁对比定位并分析了 CVE-2024-49093 的根因：把 64 位写入末端误按 32 位处理，导致常驻阈值绕过与文件尺寸状态不一致。

漏洞利用上：

越界读：制造 AllocationSize ≪ FileSize 后，RefsNonCachedResidentRead 会把 resident 记录复制到池块上再 memmove 给用户，请求长度超过真实数据就能在内核池上OOB read。

越界写：由于 MsUpdateMetaRow 的边界检查，直接 OOB 写行不通；但通过将AllocationSize截断到0并触发 RefsConvertToNonResident，在“常驻→非常驻”的迁移阶段可以在小池块上形成 OOB write。

后续更进一步的稳定利用需要结合池风水、对象布局等。

Reference

de3K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2K6j5$3W2W2L8X3y4W2k6r3W2J5k6h3y4@1i4K6u0W2j5$3!0E0i4K6u0r3M7$3y4A6k6h3&6U0k6g2)9J5c8X3q4J5N6r3W2U0L8r3g2Q4x3V1k6H3K9h3W2Q4x3V1k6e0x3U0j5$3y4U0t1^5x3e0M7J5x3o6x3H3x3o6p5H3h3l9`.`.

4cdK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6D9K9h3u0&6j5h3I4Q4x3V1k6D9K9h3u0X3M7%4u0W2k6Y4y4Q4x3V1k6T1L8r3!0T1i4K6u0r3L8h3q4A6L8W2)9J5c8X3c8G2j5%4g2E0k6h3&6@1j5i4c8A6L8$3&6Q4x3V1k6d9k6i4y4A6L8r3W2W2L8Y4c8Q4x3U0f1J5x3p5k6A6L8r3g2Q4x3U0f1J5x3q4y4&6M7%4c8W2L8g2)9J5y4e0t1H3i4K6t1^5f1X3g2r3f1#2)9J5z5g2)9J5k6h3q4K6j5$3W2A6k6r3!0U0

30eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1i4K6u0V1L8X3u0Q4x3X3g2A6L8X3k6G2i4K6u0r3x3e0t1H3x3e0f1#2x3e0j5J5y4g2)9J5c8U0x3@1

[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！