微软修复潜伏十余年的安全启动绕过漏洞 旧组件成最大隐患

这一长期存在的安全隐患源于一个简单的管理疏漏：过时的组件从未被正式吊销。知名安全厂商ESET的研究人员发现，一组存在漏洞的UEFI“shim”引导加载程序（部分甚至可以追溯到2013年）在漏洞曝光多年后，依然被微软系统视为受信任组件。这意味着，攻击者可以毫不费力地绕过Windows和Linux设备上的安全启动机制。据悉，该问题共涉及11个shim二进制文件，这些文件仍持有有效签名并被执行安全启动的系统所接受。由于签名是允许代码在启动过程中运行的关键凭证，一旦受信任组件被攻破，后续的所有启动环节都将受到波及。

ESET研究员Martin Smolár强调：“这些旧版shim的危险之处不在于采用了什么新型漏洞，而是绕过UEFI安全启动根本不需要新漏洞。攻击者无需复杂的漏洞利用手段，只要拥有一份陈旧但仍受信任且未被吊销的shim二进制文件副本，并具备关于UEFI shim运作方式的基础知识，就足以绕过这一至关重要的安全防线。”在实际攻击场景中，黑客可以利用这些shim在操作系统启动之前加载恶意固件。这类恶意软件具有极强的隐蔽性和顽固性，即使重装操作系统甚至更换硬盘等硬件设备，也难以将其彻底清除。

安全启动机制于2012年首次引入，其初衷正是为了防范此类底层攻击。该机制要求启动链条中的每一段代码都必须获得受信任机构的数字签名。微软作为该系统中的信任根，负责签署自家的引导加载程序以及Linux等其他软件所使用的shim。实际上，shim是一种折中方案，它使得非微软软件也能在安全启动环境中正常运行。一旦微软为一个shim提供了签名，该shim就可以使用其内嵌的证书来批准后续的其他组件。

然而，这套机制有效运行的前提是：一旦发现某个shim存在漏洞，必须立刻将其吊销。但在本次事件中，这一阻断机制完全失效了。受影响的shim来源广泛，涵盖了Red Hat、openSUSE和Oracle等Linux发行商，以及部分第三方工具。其中一些组件在SBAT和MOK拒绝名单等新型保护机制问世前就已经存在；另一些则自身带有代码缺陷，或者会允许加载已知存在漏洞的组件。ESET特别指出了一个Oracle的shim，它允许运行带有CVE-2015-5381漏洞的二进制文件，而且利用该漏洞的技术门槛相当低。

问题的另一部分原因在于安全启动机制日益复杂。该系统目前依赖多个层级来决定哪些代码可以运行，包括受信任签名数据库、吊销列表，以及如SBAT等基于版本控制的新型机制。其中每一个环节都需要进行精确的更新与维护。正如Smolár所解释的那样，dbx负责吊销特定的二进制文件，而SBAT和微软的Secure Boot SVN则负责吊销特定的版本。每个启动组件都包含带有版本号的元数据，系统理应拦截所有低于设定阈值的组件。但这完全依赖于阈值数据的及时更新。值得注意的是，即使是用于签署这些shim的微软证书过期，也未能自动阻止它们运行，这充分暴露了整个系统过于依赖主动吊销，而非内置的过期失效机制。

目前，已经安装最新更新的Windows系统不再受此漏洞威胁；对于Linux用户，专家建议向相应的发行版官方进行核实，或使用fwupd等工具确认系统是否已获得保护。

然而，引发业界更深层担忧的是这套信任体系的脆弱现状。在众多组件、供应商和频繁的更新之间管理信任关系，已被证明是一项极其艰巨的任务。runZero首席执行官兼创始人HD Moore在接受采访时直言：“这是对整个安全启动模型的严厉痛批。”他指出，有太多带有签名的组件缺乏有效追踪，并且仍然可以被用于非预期的危险用途。Moore总结道：“最终的结果是，存在大量（除了微软之外无人知晓的）带有签名且能绕过安全启动的组件——其中一些被用来引导其他程序，并且它们同时带有常规的安全漏洞和其他错误，这意味着它们几乎可以用来引导任何东西。整个生态系统在某种程度上已经支离破碎，亟需一次彻底的重启。”