假若你一经据说过了 CVE-2022-21894 罅隙而且实时下载了本年 5 月 9 日的 Windows 太平更新（KB5025885），你可能通过下述办法来启用内里包罗的修复实质：

　　正在 Windows 中装置 2023 年 5 月 9 日或之后的太平更新，并重启电脑。

　　此时假若你可能正在 Windows 事项查看器中找到 ID 为 1035 和 276 的事项，阐发手动启用更新凯旋。

　　（可选）假若你正正在利用少许启动介质（外接体系盘、Win To Go、U 盘、DVD 等等），正在重启后的 Windows 中对举办它们更新或者重装，省得展现正在更新过的摆设上无法启动的情景；假若你举办了体系备份，该当从新举办一次扫数备份，因为同上。

　　必要细心的是，正在手动启用此次更新之后，悉数没有正在新体系中更新过的启动介质、官方 ISO 镜像、厂商重装盘、PE 启动器等等将十足失效，无法开机。

　　试思一下，一个措施从你按下电源键的那一刻便一经启动，随后寂然的凝睇着每一个子措施的启动和运转，直到你进入了 Windows 、种种默认启动的软件先导运转之后，它仍旧正在寂然的合心着和担任着你悉数的数据化新闻。

　　这个自始至终寂然睁着眼睛的措施，叫做 Secure Boot（太平启发），是 Windows 启动流程中不成或缺的一环。它会正在操作体系的启动历程中认真反省每一项被叫醒的措施和驱动，而且会连接运转到进入操作体系的初期阶段，以制止那些心怀鬼胎的措施从启动伊始暗暗接受少许主要过程，挖穿 Windows 的墙角。

　　而 Secure Boot 的运转情况，则被称作 UEFI（团结可扩展固件接口），从 Windows 8 时期先导被微软逐渐推行，用以代替也曾没有图形界面、交互不简单的 BIOS 形式。

　　举动连续 Windows 与计划机硬件的桥梁，UEFI 自己就像是一个袖珍的操作体系相似，正在初始化阶段会递次加载启动分区上的种种 UEFI 运用（UEFI Applications）并最终进入 Windows Boot Manager 、由它来天生启动情况（boot environment），进而依据情景拔取进入迥殊形式依旧主体系。

　　正在寻常的体系启动历程中，Secure Boot 效用会通过加密验证每一个启动合头正在出厂时就写入的数字署名来确保它们的太平性，而且直到主体系实现启动并先导加载种种驱动和运用时都正在连接使命着。按理说云云主动且强势的介入形式该当可能杜绝绝群众半的恶意启动项了，然而 Baton Drop 罅隙却指出了一条极端希奇的道途。

　　Secure Boot 效用得以运转并将恶意措施防备于未然的条件，自然是它正在每一个运用启动之前就对它们举办反省，这就请求正在 UEFI 运转时，Secure Boot 的联系代码被优先从内存中提取出来运转、随后才是某个特定的 UEFI 运用。

　　那么若何让 Secure Boot 战术的代码最优先呢？自然便是让它们所正在的内存所在尽不妨的「低」了——你可能将内存所在设思成一个笔直堆叠的构造，正在这个构造中，电脑的运转逻辑会依照从下往上的次序举办读取，是以内存所在越低的代码会先于所在高的代码实行。为了包管 Secure Boot 的太平性，微软默认便原则了将它分派正在了尽不妨低的所在上，优先于任何 UEFI 运用的代码。

　　而 Baton Drop 罅隙指出 Secure Boot 可能被绕过的道理，恰是出正在它的内存所在分派上。

　　举动电脑启动的基础过程，每个 UEFI 运用也具有肯定的自立权，它们可能通过启动设备数据（Boot Configuration Data， BCD）调理计划机的硬件，个中一个名为 turncatememory 的 BCD 会将特定所在以外的内存照射外中的代码根除掉，用于给下一个 UEFI 运用腾出内存空间。

　　但若何让正本「趴低」的 Secure Boot 代码被 turncatememory 击中呢？自然便是让它的代码被从新分派到更高所在的内存上了。对待一个恶意的 UEFI 运用来说，它可能通过人工窜改后的 BitLocker 元数据来为本人的 BCD 伪制一个具有极高可托度的起原，当 Secure Boot 的代码识别到这个高可托度的起原后就会同意本人的内存所在被从新分派。

　　这时，借助另一条名为 avoidlowmemory 的 BCD ，一个不怀好意的 UEFI 运用就有权利请求 Secure Boot 战术（正在字面道理上）避开低所在、蜕变到更高的内存所在上了。

　　至此，一个不怀好意的 UEFI 运用通过伪制的高可托度的 BCD 起原，让正本最优先实行的 Secure Boot 战术毫不勉强地「发迹让座」。

　　因为 Baton Drop 株连到了优先度和太平级别极高的 Secure Boot ，微软封堵罅隙的宗旨重要借助了 UEFI 的黑名单机制。举动 Secure Boot 以外的另一道太平门径，UEFI 会预制一份名为 UEFI Forbidden Signature Key（简称为 DBX）的黑名单，每当 UEFI 正在运转中识别到了某一个 UEFI 运用的二进制数字署名与 DBX 相配合，就会直接禁止这个运用的运转。

　　然则因为 Windows 自身繁复的发售形式，这些二进制数字署名既不妨来自微软，也不妨来自发售电脑或者主板的 OEM 厂商，或者是显卡、网卡等等硬件的驱动措施署名，而 DBX 得到实时更新的独一形式便是 Windows 升级或者 OEM 厂商供给的固件升级。为了应对 Baton Drop 这种位于 UEFI 层级的罅隙，微软目前能做的便是将确认具有罅隙的数字署名增加到 DBX 内里，再通过 Windows 更新推送给环球的用户。

　　这时，一个「船浩劫掉头」的题目就出来了：第三方厂商们修复罅隙推出更新的速率七零八落，微软不行一次性就把悉数带罅隙的数字署名十足增加到 DBX 内里，由于一朝云云做了，DBX 更新后的用户只须还正在利用着没有更新 UEFI 固件的主板或者硬件，就必定会境遇 UEFI 无法完好的实行、进而导致无法开机的题目。

　　居然，不久之后，这个没有所有堵上的穴洞就引来了狼群—— 2022 年 10 月 6 日，有人先导正在黑客论坛上以每份 5000 美元的价值兜销一款号称可能绕过 Secure Boot 而且具有 Ring0 级别内核固化的 bootkit ，最终举动 HTTP 加载器让威胁者实行 C&C（Command and Control，号令与局限）攻击。

　　这份只要 80kB 的 bootkit 便是目前展现的第一款可能攻破最新版 UEFI Secure Boot 的恶意启动固件——「黑莲花」。

　　随后，由捷克斯洛伐克的搜集太平公司 ESET 主导，「黑莲花」的整体运转逻辑被解包了出来。从道理上讲，它的使命历程与 HIV 有些好似，HIV 的重要攻击倾向是人的免疫体系、后续的致病致死往往是免疫体系瘫痪后种种熏染惹起的；「黑莲花」则是绕过和禁用 Windows 中的种种太平组件，例如 Secure Boot、BitLocker、代码完好性反省（HVCI）等等，正在体系所有启动后通过启发 HTTP 长途局限的加载来对倾向摆设举办攻击或者偷取：

　　简化后的「黑莲花」攻击流程，其重要行使的仍旧是一年前的 CVE-2022-21894｜ESET

　　简略来说，正在行使 Baton Drop 罅隙绕过 Secure Boot 之后，「黑莲花」就可能正在 NVRAM 内里正本只读的 MokList 列外中列入一份来自攻击者的机主密钥（Machine Owners Key， MOK）实行提权和罅隙固化。再次重启后，「黑莲花」的「假大旗」玩成了「真皋比」，Windows 正本的寻常启动措施就会读取到这份来自攻击者的 MOK ，一齐绿灯地加载「黑莲花」自署名的启动用具 grubx64。efi 和来自攻击者的内核驱动，接踵禁用种种 Windows 太平用具直至主体系启动，最终导致 C&C 攻击。

　　之是以「黑莲花」可能正在微软针对 Baton Drop 揭橥补丁后泰半年才横空诞生，恰是因为 UEFI 内里这份不行一次性更新完的 DBX 列外。正在这个空档里，「黑莲花」通过自带罅隙驱动（Bring Your Own Vulnerable Driver， BYOVD）的形式，借助权且没有被列入黑名单但具有罅隙的二进制文献举办自署名，进而让本人的 UEFI 运用（也便是上面的 grubx64 ）可能被顺遂的运转。

　　环球商场拥有率最高的操作体系被曝出了云云底层的罅隙，微软当然要殷切动手举办修复，早正在客岁一月就推送了 Patch Tuesday 更新揭晓修复了 Baton Drop 罅隙。但借着 CVE-2022-21894 兴风作浪的「黑莲花」还没有消停，另一个本质附近的 UEFI 罅隙就被接踵开采出来，这一次是合于 Windows Boot Manager 的 CVE-2023-24932 罅隙。最终，正在本年 5 月 9 号的一则博文中，微软揭晓了针对此次底层罅隙的跨度靠拢一年的修复预备：

　　2023 年 5 月 9 日的 CVE-2023-24932 补丁中，将会包罗一份默认不启用的修复措施，用户必要参考微软供给的指南本人更新目前利用的启动引子并增加具有针对性的 DBX 列外。

　　2024 年第一季度的更新中会默认启用针对 CVE-2023-24932 的修复，并强制运用新的 DBX 列外来阻断此前具有罅隙的启动形式。

　　至于为什么要采纳云云分阶段的形式来实施一个事合简直悉数 Windows 用户的巨大更新，因为正如前文所述，无论是 Baton Drop 依旧 Windows Boot Manager ，思要彻底处理题目就必需把悉数此前有罅隙的 UEFI 固件给「拉黑」，用更新后的 DBX 列外核验启动时加载的每一个 UEFI 运用，从而劝止「黑莲花」云云的恶意 bootkit 混入个中。

　　然则，此前带有罅隙的 UEFI 固件存正在于来自微软的简直悉数 Windows 官方镜像，涵盖周围从 Windows 11 到 Windows 10，乃至早至 2008 版的 Windows Server ——换句话说，简直悉数你之前下载的 。iso 镜像文献，或者是以此灌装的装置盘、Windows To Go 启动器、种种 Win PE 装置器、公司 IT 部分用来排障或者搜集分发的启动镜像，乃至是扫数备份文献，正在补丁更新之后的电脑大将通通不行启动。

　　而且别忘了，戴尔、联思等等 OEM 厂商，以及微星、华硕之类的主板厂商们利用的同样是来自微软的镜像或者固件（更不消提微星正在蒲月的一次绑架软件攻击中一经透露了本人的署名密钥），是以假若你买的电脑自带收复盘的话，正在运用了 Windows Boot Manager 修复之后的呆板上也将所有失效。

　　是以南宫28在线注册，正在偏向于避免导致大周围启动题目的条件下，微软最终拔取了云云一个循序渐进的处理计划。固然现正在还不行说效果明显，然则面临当下愈发经常的针对 EFI 体系分区（EFI System Partition， ESP）的攻击，尽不妨主动的门径依旧须要的。

　　运气的是，无论是「黑莲花」依旧其他尚未浮出水面的针对 ESP 的攻击门径，它们素质上都正在以仙逝荫藏性的门径来换取加倍便捷的计划。正在 ESET 的分解中可能看到，借助「黑莲花」举办 C&C 攻击的扫数条件是必要正在倾向摆设上实行「黑莲花」的装置措施，这便必要攻击者与倾向举办物理接触、或者通过垂钓邮件之类的形式赢得统制员权限——事故方今便又回到了守旧的搜集太平攻防周围中。

　　除此以外，假使「黑莲花」运转正在咱们看不到的体系启动前流程里，然则它的运转仍旧会正在主体系里留下可能追寻的陈迹。假若你猜忌本人或者团队中所利用的摆设受到了「黑莲花」的攻击，可能参考微软太平博客正在本年四月揭橥的考核攻击指南[1]来排查和收复。

　　而对待正正在利用着 Windows 体系的你我他她来说，咱们现正在能做的便是维系杰出的上钩习俗……而且尽量装置一下近期的 Windows 太平更新吧。