微软蓝屏内幕：来自周五的空指针部署

1

   

发生了什么？

2024 年 7 月 19 日 04:09 UTC，作为持续运营的一部分，CrowdStrike 向 Windows 系统发布了传感器配置更新。传感器配置更新是 Falcon 平台保护机制的持续组成部分。此配置更新触发了逻辑错误，导致受影响的系统崩溃和蓝屏 (BSOD)。

导致系统崩溃的传感器配置更新已于 2024 年 7 月 19 日星期五 05:27 UTC 修复。

此问题不是网络攻击的结果，也不与网络攻击有关。

2

   

影响

Windows 7.11 及更高版本的 Falcon 传感器的客户可能会受到影响（这些客户在 2024 年 7 月 19 日星期五 04:09 UTC 至 2024 年 7 月 19 日星期五 05:27 UTC 期间在线。  ）

运行适用于 Windows 7.11 及更高版本的 Falcon 传感器的系统，如果在 UTC 时间 04:09 至 UTC 时间 05:27 之间下载了更新的配置，则容易发生系统崩溃。

3

   

配置文件入门

上述配置文件称为“通道文件 ( https://supportportal.crowdstrike.com/s/article/ka16T000000wuddQAA )”，是 Falcon 传感器使用的行为保护机制的一部分。通道文件的更新是传感器操作的正常部分，每天进行几次，以响应 CrowdStrike 发现的新策略、技术和程序。这不是一个新过程；该架构自 Falcon 成立之初就已存在。

4

   

技术细节

在 Windows 系统上，频道文件位于以下目录中：

C:WindowsSystem32driversCrowdStrike\

并且文件名以“ C-”开头。每个通道文件都分配有一个数字作为唯一标识符。此事件中受影响的通道文件为 291，文件名以“ C-00000291-”开头并以扩展名结尾.sys。虽然通道文件以 SYS 扩展名结尾，但它们不是内核驱动程序。

通道文件 291 控制 Falcon 如何评估 Windows 系统上的命名管道 1 执行。命名管道用于 Windows 中的正常、进程间或系统间通信。

UTC 时间 04:09 发生的更新旨在针对新发现的常见 C2 框架在网络攻击中使用的恶意命名管道。配置更新触发了逻辑错误，导致操作系统崩溃。

5

   

通道文件 291

CrowdStrike 已通过更新通道文件 291 中的内容纠正了逻辑错误。除了更新后的逻辑之外，不会对通道文件 291 进行任何其他更改。Falcon 仍在评估和防止滥用命名管道。 

这与通道文件 291 或任何其他通道文件中包含的空字节无关。

6

   

补救措施

我们了解一些客户可能有特定的支持需求，我们要求他们直接联系我们。

目前未受影响的系统将继续按预期运行，继续提供保护，并且不会在未来遭遇此事件的风险。

运行 Linux 或 macOS 的系统不使用通道文件 291，因此不受影响。

7

   

根本原因分析

频道文件可能包含空字节

7.1

   

上下文

CrowdStrike 在内部和现场观察到磁盘上一个或多个通道文件的内容全为零（“NULL 字节”）的情况。在机器崩溃前不久将通道文件写入磁盘的背景下，已经观察到这种情况。

在所有这些情况下，CrowdStrike Falcon® 传感器在机器崩溃之前将有效（非零）数据写入文件。重启后观察到的零内容是 Windows 操作系统管理磁盘上的文件以满足其安全设计的方式的结果。

现代 Windows 操作系统（例如 Windows Vista 及更高版本）基于 Microsoft 在 20 世纪 80 年代末开发的 Windows NT 核心构建，以满足对与 Windows 应用程序兼容、具有弹性、可扩展且安全的系统架构日益增长的需求。作为这些要求的一部分，Microsoft 选择遵循当时最开放、最严格的一套要求。

在这些标准中，在 Microsoft 力求达到的分区级别 (C) 中，C2 级（受控访问保护）提出了一项要求 (2.2.1.2)，标记为“对象重用”。作为其中的一部分，软件组件（在本例中为操作系统的文件系统堆栈）必须保证没有先前的信息（在本例中为磁盘上的现有扇区数据）可供新参与者使用。通俗地说，对于文件系统场景，这意味着尽管磁盘在即将写入新数据的特定扇区中可能包含先前使用的数据，但必须先擦除这些数据，然后才能将缓冲区释放给用户以供进一步写入。

换句话说，每次您创建一个新文件来写入数据时，Windows 文件系统都会首先擦除与此新文件位置匹配的磁盘上所有已分配扇区。为了简化问题，Windows 缓存控制器（“缓存管理器”）实现了一个名为 CcZeroData 的线程，旨在用于此目的。出于安全原因，只要尝试在脏数据（以前使用过的数据）上进行写入，就会同步执行此操作。

相反，出于性能原因，Windows（与许多其他操作系统一样）将延迟写入磁盘，无论是在文件系统还是物理磁盘层。这就是为什么 Windows 总是建议您在从计算机中移除 USB 密钥之前通过用户界面“弹出”它。

虽然我们许多人在强行移除外部媒体时都经历过这种情况，但当内部媒体也被“强行移除”时，也会发生同样的情况——例如所谓的“蓝屏死机”（BSOD）。在这种情况下，文件系统和存储驱动程序的刷新代码可能没有运行（在某些情况下，硬盘驱动器可能有自己的基于固件的延迟写入机制），因此没有字节会写入磁盘。

尽管人们可能认为不存在任何文件（或存在部分文件，或存在充满“垃圾”（脏数据）的文件），但实际情况是，受控访问保护要求（后来被 ISO 下的通用标准指南取代）将强制文件首先同步填充零（NULL 字节），这样由于内核崩溃而错过的任何延迟文件写入都会导致文件被清零。

重要的是要意识到，虽然磁盘上的文件可能尚未写入，但 Windows 应用程序和/或驱动程序认为它们已完成的“写入”仍将对任何读取器可见，因为缓存管理器将保存数据在内存 (RAM) 中。这会导致以下常规 Windows 场景，对于 Falcon 传感器来说，这意味着预期的通道文件已下载并解析，但操作系统在完全写入持久存储之前崩溃了：

这个也就是空字节导致的蓝屏问题。希望该问题能为你带来一定启发。

8

   

如何避免此类问题

不要存在任何侥幸心理，每改一行代码，特别对于那种面向 C 端用户的代码，一定要做到：可灰度、可回滚、可监控，我们可以看到虽然此问题影响比较大，但是 CrowdStrike 解决速度还是非常之快，基本在 1 个小时恢复了故障。整个问题的根源是，前期缺乏充分的测试，上线过程中没有按照灰度的思想，先部分、后整体，尽可能减少变更造成的影响。

随手关注或者”在看“，诚挚感谢！