微软全球蓝屏致391亿损失!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 x 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