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

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

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

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

在本周微软的补丁“蓝屏事件”中，BitLocker的再现角色从“反串”晋升到了主角。事件起因是大规微软在修复BitLocker安全漏洞的过程中，由于固件兼容性问题导致部分设备进入BitLocker恢复模式（下图），蓝屏事件导致大量用户必须输入恢复密钥才能正常启动系统。IT技术网这迫使微软撤回该补丁并建议用户实施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恢复模式。云南idc服务商而在2023年4月，微软再次修复了另一个导致BitLocker加密错误的问题，该问题在一些管理环境中被标记为报告错误，但并未影响驱动器加密本身。

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

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

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

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

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

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

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

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

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

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

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

最新评论