微软全球蓝屏致391亿损失！25万台设备仍未恢复

导语：据估计，崩溃的设备多达850万台，到目前为止已经恢复了97%，但剩下的3%仍有25万台之多。

波及全球的微软蓝屏事件，至今还有25万台设备没完全恢复！

另据估计，崩溃的设备多达850万台，到目前为止已经恢复了97%，虽然看似修复效率很高，但剩下的3%仍有25万台之多。

与此同时微软也发布了一份全面调查报告，提供了根本原因的技术概述，解释了为什么安全产品使用内核模式驱动程序，以及未来如何增强安全产品的可扩展性。

该事件影响范围几乎覆盖全球，涉及了涵盖航空公司、电视广播、医疗机构、银行金融等众多行业，甚至连奥运会也受到了影响。

仅在航空业，就有5000多架次航班被迫取消，占了全球定期航线的4.6%，美国一家航空公司甚至连续三天都出现了航班取消的情况。

经济损失也是数以十亿计，据数据分析机构Parametrix的估计，单是对于财富500强企业，这次事件带来的损失就高达54亿美元（约合391.8亿人民币）。

还有不法分子趁火打劫，冒充Crowdstrike的名义，假借发布“修复工具”之名，公然散播恶意软件。

*** 安全专家Troy Hunt称之为“史上更大规模的IT中断事件”。

抓马的是，Crowdstrike在此次事件之后，给帮助修复问题的员工和合作伙伴发放了10美元的外卖代金券作为感谢，结果被外卖平台标记为了“欺诈”。

收到优惠券的人在准备使用时发现券已被取消，导致Crowdstrike本已经受到巨大影响的口碑又进一步下滑。

微软的调查报告，确认了Crowdstrike初步报告中提及的驱动文件正是造成此次事件的罪魁祸首。

进一步分析结果表明，该文件对内存的越界读取，是导致事故的直接原因。

随着研究的深入，第三方安全软件到底该不该被授予了内核级的操作权限，也引发了广泛讨论。

核心原因：越权读取内存

通过分析大量的崩溃报告，微软发现这些记录都指向了CrowdStrike的驱动程序csagent.sys。

通过调阅故障时系统留下的崩溃转储，微软再现了崩溃发生时的场景——

首先查看崩溃线程的Trap Frame后，发现引发异常的指令是一条针对R8寄存器、指向内存的读操作。

进一步观察Trap Frame附近的指令，又发现在该读操作之前，有一个对R8的空值检查，检查失败才会继续执行后续的读操作。

但是检查R8指向的虚拟地址后，微软发现它指向了一个非法地址，导致内核访问违规，从而引发了此次崩溃。

另外，Crowdstrike也解释了流程层面的原因——在上线前的测试过程中，未能检测到更新中的“有问题的内容数据”。

事件发生后，微软和Crowdstrike都紧急应对，Crowdstrike发动了全部技术人员，微软也派出了5000多名技术人员7×24小时应对此事。

经过两家合作研究，主要得出了两种该问题的解决方案——

之一种简单粗暴，就是重启，以便在错误的文件启动之前获取更新并将其覆盖。

修复方案还提到，如果重启一次不管用就多试几次，按微软的说法，最多可能要15次。

如果无法通过重启获取更新，微软还提供了通过 *** 或USB设备的启动工具，以便能够删除问题文件。

针对后续工作，两家也分别做出表态：

微软表示，将计划与反恶意软件生态系统合作，减少对内核驱动的依赖；

Crowdstrike则承诺，正在对其测试和部署流程进行更改，以防止类似情况再次发生。

该不该开放内核级操作？

引起此次崩溃的csagent.sys，正是一个内核级的驱动程序。

具体来说，csagent.sys被注册为一个文件系统筛选驱动，用于接收文件操作事件。

所以在这次事件之后，到底应不应该把系统的内核级操作权限开放给第三方，也引发了广泛讨论。

在微软的报告中，也解释了一些使用内核驱动程序进行安全防御的原因：

可见性和执行力：内核驱动可以全系统范围内可见，并能够在启动早期加载，以检测 bootkit和rootkit；

性能：某些高吞吐量的数据采集和分析场景，使用内核驱动可以带来性能优势；

防篡改：即便管理员权限也难以禁用处于内核模式的驱动，因为Windows提供了早期加载（ELAM）等机制，让驱动能尽早运行。

但同时微软也指出，驱动运行在更高权限，一旦出问题难以隔离和恢复，因此驱动代码必须经过严格测试。

不过在HackerNews上，网友们并不认同内核级别的运行方式，并指出苹果和Linux早就禁用内核级操作，改为用户级操作了。

按这位网友的说法，虽然直接原因是由Crowdstrike导致，但微软不禁用内核操作给了问题程序运行的土壤，所以也难辞其咎。

其实微软也不是没试过禁用，甚至这次事件中的Crowdstrike，还是微软的竞争对手。

但是其他网友指出，这是为了符合欧盟的监管要求，因为微软自己的安全软件有内核级操作，所以公平起见，也得开放给第三方。

但这句话只说对了一半，欧盟并未要求微软将内核操作开放给第三方，他们还可以选择把自己的安全产品也移出内核。

当然，如果只从技术角度分析，网友们的观点还是比较一致的，都认为内核级操作还是开放的越少越好。

微软的报告中也提到，今后会联合安全软件生态，尽可能减少内核操作对重要安全数据的访问需要。

最后再说说直接造成此次事件的Crowdstrike。

实际上，这已经不是这家公司的Falcon程序之一次把操作系统搞崩了。

从今年四月开始到现在这四个月，Falcon每个月都会把操作系统搞崩一次。

前三次的受害者都是Linux内核的操作系统，不过影响范围和受关注程度都和这次事件无法相提并论：

4月19日晚，Crowdstrike发布了一个有缺陷的软件更新，导致运行Debian 的计算机崩溃且无法正常重启；

5月13日，安装CrowdStrike软件的服务器在升级到Rocky Linux 9.4后可能会冻结（freeze）；

6月，Red Hat在启动了Crowdstrike的falcon-sensor进程后，也观察到了内核恐慌（Kernel Panic）。

参考链接：

[1]https://www.microsoft.com/en-us/security/blog/2024/07/27/windows-security-best-practices-for-integrating-and-managing-security-tools/

[2]https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/

[3]https://news.ycombinator.com/item?id=41095530