克雷西 发自 凹非寺量子位 | 公众号 QbitAI
波及全球的微软蓝屏事件，至今还有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，还是微软的竞争对手。
但是其他网友指出，这是为了符合欧盟的监管要求，因为微软自己的安全软件有内核级操作，所以公平起见，也得开放给第三方。
![]()
但这句话只说对了一半，欧盟并未要求微软将内核操作开放给第三方，他们还可以选择把自己的安全产品也移出内核。
![]()
当然，如果只从技术角度分析，网友们的观点还是比较一致的，都认为内核级操作还是开放的越少越好。
微软的报告中也提到，今后会联合安全软件生态，尽可能减少内核操作对重要安全数据的访问需要。
One More Thing
最后再说说直接造成此次事件的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
— 完 —
量子位年度AI主题策划正在征集中！
欢迎投稿专题 一千零一个AI应用，365行AI落地方案
或与我们分享你在寻找的AI产品，或发现的AI新动向
![]()
点这里👇关注我，记得标星哦～
一键三连「分享」、「点赞」和「在看」
科技前沿进展日日相见 ~
![]()
波及全球的微软蓝屏事件，至今还有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，还是微软的竞争对手。
但是其他网友指出，这是为了符合欧盟的监管要求，因为微软自己的安全软件有内核级操作，所以公平起见，也得开放给第三方。
但这句话只说对了一半，欧盟并未要求微软将内核操作开放给第三方，他们还可以选择把自己的安全产品也移出内核。
当然，如果只从技术角度分析，网友们的观点还是比较一致的，都认为内核级操作还是开放的越少越好。
微软的报告中也提到，今后会联合安全软件生态，尽可能减少内核操作对重要安全数据的访问需要。
One More Thing
最后再说说直接造成此次事件的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
— 完 —
量子位年度AI主题策划正在征集中！
欢迎投稿专题 一千零一个AI应用，365行AI落地方案
或与我们分享你在寻找的AI产品，或发现的AI新动向
点这里👇关注我，记得标星哦～
一键三连「分享」、「点赞」和「在看」
科技前沿进展日日相见 ~