电脑教程

微软官方安全补丁再现大规模“蓝屏事件”

时间:2010-12-5 17:23:32  作者:电脑教程   来源:网络安全  查看:  评论:0
内容摘要:当CrowdStrike正忙于应付“全球最大规模蓝屏事件”的客户集体诉讼时,微软公司本周发布的一个BitLocker安全补丁再次触发“蓝屏”事件。不过这次“蓝屏”不是“蓝屏死机”,而是重启到Bitlo

当CrowdStrike正忙于应付“全球最大规模蓝屏事件”的蓝屏事件客户集体诉讼时 ,微软公司本周发布的微软一个BitLocker安全补丁再次触发“蓝屏”事件 。不过这次“蓝屏”不是官方“蓝屏死机”,而是安全重启到Bitlocker的蓝色恢复界面。

对于很多刚刚经历CrowdStrike事件惊魂未定的补丁CIO和CISO们来说 ,微软官方“蓝屏补丁”事件不仅仅是再现伤口上撒盐 ,更可能是大规彻底摧毁对IT服务商信心的“最后一根稻草”。

“官方蓝屏补丁”

微软的源码库蓝屏事件Windows驱动器加密工具BitLocker在两次“蓝屏事件”中都扮演了重要角色 。在CrowdStrike的微软安全更新导致的全球最大规模IT系统崩溃事件中,使用BitLocker加密驱动器的官方用户在恢复系统时需要手动输入BitLocker密钥 ,这大大拖延了系统恢复的安全时间 。

在本周微软的补丁“蓝屏事件”中,BitLocker的再现角色从“反串”晋升到了主角。事件起因是大规微软在修复BitLocker安全漏洞的过程中 ,由于固件兼容性问题导致部分设备进入BitLocker恢复模式(下图),亿华云蓝屏事件导致大量用户必须输入恢复密钥才能正常启动系统。这迫使微软撤回该补丁并建议用户实施BitLocker安全漏洞的手动缓解措施。

微软安全更新导致设备重启到Bitlocker恢复界面

BitLocker是Windows的一个安全功能,通过加密存储驱动器来防止数据泄露或被盗。通常情况下 ,只有在用户更换硬件或TPM(受信任平台模块)更新等事件后,系统才会进入BitLocker恢复模式。而此次微软补丁导致触发恢复模式,显然属于程序bug而非“功能特色” ,并迅速引起了业界广泛关注。

该“蓝屏补丁”影响多个Windows客户端和服务器平台,涵盖Windows 10、Windows 11以及多版本的云计算Windows Server,具体如下:

客户端系统:Windows 11 23H2 、22H2、21H2;Windows 10 22H2、21H2。

服务器系统:Windows Server 2022 、2019 、2016、2012 R2 、2012、2008 R2 、2008

此前已发生多次安全更新事故

类似的的安全更新问题在2022年8月的KB5012170更新中也曾出现,当时Secure Boot DBX(禁止签名数据库)的模板下载更新触发了0x800f0922错误 ,导致部分设备进入BitLocker恢复模式 。而在2023年4月,微软再次修复了另一个导致BitLocker加密错误的问题,该问题在一些管理环境中被标记为报告错误,但并未影响驱动器加密本身。

在本月的补丁星期二 ,微软还修复了7月Windows安全更新引发的BitLocker恢复问题 。然而 ,微软并未透露导致该问题的根本原因  ,也未详细说明是如何修复的高防服务器。

不可撤销的缓解措施

由于补丁与设备固件不兼容导致部分设备进入BitLocker恢复模式 ,微软最终决定撤回该修复补丁(CVE-2024-38058) 。

但由于该漏洞极为严重(攻击者可能通过物理访问目标设备绕过BitLocker设备加密功能 ,从而访问加密数据),微软在8月的安全更新中正式禁用了该补丁 ,并建议用户通过KB5025885公告中的手动缓解措施保护系统和数据。

微软给出的手动缓解措施包括一个四阶段的操作流程,需要重启设备多次。需要格外留神的是免费模板  ,应用这些缓解措施后 ,启用了安全启动(Secure Boot)的设备将无法移除该缓解措施 ,即使重新格式化磁盘也无济于事。

微软提醒用户  ,在实施这些缓解措施之前,应充分测试并了解所有可能的影响,因为一旦实施 ,撤销将变得非常困难 。

安全补丁不可随意“敏捷”

虽然微软总是建议用户安装最新更新  ,但此次“蓝屏事件”再次提醒我们,安全补丁的兼容性和系统恢复问题仍是未来安全更新中的一大挑战。

对于企业和用户来说 ,最重要的是及时了解和跟进安全更新,同时在部署补丁和实施缓解措施时,不可盲目置信(即便是主流厂商) ,必须进行充分的测试和评估 ,以确保系统稳定性与安全性的平衡。

此外,CrowdStrike和微软相继曝出“蓝屏事件”,表明在网络安全产品的QA和测试环节生搬硬套敏捷方法往往会产生严重的安全隐患  。

正如一位安全人士对该事件的点评 :

“这就是所谓的敏捷 。微软的产品曾经很成功,因为他们有更多的QA而不是开发。然后,他们在开发Bing时改变了QA方法,并认为找到了最佳实践(将Bing看作成功的衡量标准)”

“将开发和测试结合起来的敏捷方法 ,以“组合工程”的名义(首先在Bing团队中使用)大肆宣传。在Bing ,创建程序化测试的任务被甩给开发人员 ,而不是专门的测试人员 。QA仍然存在并且仍然很重要,但(安全产品)需要执行的是最终用户风格的“真实世界”测试,而不仅仅是程序化自动化测试。”

copyright © 2025 powered by 创站工坊  滇ICP备2023000592号-21sitemap