本周三，CrowdStrike 公司在修复指南中新增了一份初步的事后审查报告。该公司从自身角度出发分析了导致850万台 Windows 设备蓝屏死机的原因。报告在开头部分详细说明了 CrowdStrike Falcon Sensor 附带的“传感器内容”，称它用于控制和定义其威胁检测引擎的能力。Falcon Sensor 是基于行为的软件，CrowdStrike 公司为其更新了“快速响应内容”，即通过传感器内容来检测和处理具体的新兴恶意软件和其它不必要的系统活动。该“快速响应内容”通过这些天所了解到的那些Channel File交付给用户。

基本的传感器内容包括所谓的“模板类型”。这些模板类型是可自定义的代码块，可供快速响应内容识别系统中的恶意内容。因此，这些快速响应更新被称为“模板实例”，因为它们是“既定模板类型的实例”。

因此，”传感器内容”定义了一堆代码模板，而“快速响应内容”则定制了这些模板的操作，以便传感器软件能够检测、观察和阻止特定的系统活动。正如 CrowdStrike 所述，模板实例配置了模板类型在运行时的操作方式。

2024年2月，CrowdStrike 为“快速响应内容”推出并分发了一个新的“进程间通信 (inter-process-communication, IPC) 模板类型”，旨在检测“滥用 Named Pipes 的新兴攻击技术”。该IPC 模板类型在3月5日通过了测试，CrowdStrike 还发布了一个快速响应模板实例以使用该IPC模板。

在4月8日至4月24日期间，CrowdStrike 又部署了三个 IPC 模板实例。所有这些实例都运行良好，并未导致850万台 Windows 机器崩溃，尽管如之前报道的那样，在5月份和6月份期间某些 Linux 机器因为 Falcon 平台而产生问题。

7月19日，CrowdStrike 又推出了两个IPC模板实例。其中一个模板虽然包括“有问题的内容数据”，但却被用于生产环境中，因为CrowdStrike 将其描述为“内容验证器中的一个bug”。虽然 CrowdStrike 在文章中并未详细说明该内容验证器所承担的角色；但顾名思义，我们假设它可能是以自动化的方式做出预期行为。

不管该验证器的作用是什么或应该发挥什么样的作用，它确实并未阻止向客户发布7月19日的这个可疑的可视为无用的模板实例。该测试软件本应检测到内容更新已损坏，但由于验证器存在bug，于是还是通过了。

CrowdStrike 公司因此认为7月19日的 Channel File 发布应该是没问题的；毕竟这些测试通过了3月份发布的 IPC 模板类型，随后通过了相关的 IPC 模板实例，而这些都没有在Windows上触发故障。

历史告诉我们，这个假设非常糟糕。正如我们之前的分析，Falcon 加载并解析了新内容并受已损坏模板实例的困扰，导致在 CrowdStrike 的 Windows 驱动层代码中造成“界外内存读进而触发异常”，从而导致整个系统崩溃。

Falcon 套件在重启后会再次启动并崩溃。因为Falcon套件在操作系统级别运行，因此它的威胁检测操作具有良好的可见性。然而，当内容解释器被误导访问本不应访问的内存，就可能拖垮整个操作系统并运行应用程序。

CrowdStrike 团队表示，“这种意外异常无法被恰当地处理，因此导致 Windows 操作系统“在850万台机器上“崩溃”。

该事件报告包括诸多承诺，如未来更加严格地测试未来的“快速响应内容”、错开发布、让用户对部署时间有更多的控制，并提供发行说明。

是的，你没看错：发行说明。别激动，冷静、冷静.txt。

CrowdStrike公司还在该报告中承诺完成调查后发布完整的根因分析文章。

想对 CrowdStrike 说：别急，慢慢来。我们有些人还在重构被你搞崩溃的机器呢。

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。

    觉得不错，就点个 “在看” 或 "赞” 吧~