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

近日微软终于修复了自2013年以来一直潜伏在系统中的安全启动Secure Boot绕过漏洞。安全研究人员指出此次事件暴露出的核心问题并非漏洞本身而是那些带有数字签名却缺乏有效追踪管理的老旧组件。微软修复潜伏十余年的安全启动绕过漏洞 旧组件成最大隐患这一长期存在的安全隐患源于一个简单的管理疏漏过时的组件从未被正式吊销。知名安全厂商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总结道“最终的结果是存在大量除了微软之外无人知晓的带有签名且能绕过安全启动的组件——其中一些被用来引导其他程序并且它们同时带有常规的安全漏洞和其他错误这意味着它们几乎可以用来引导任何东西。整个生态系统在某种程度上已经支离破碎亟需一次彻底的重启。”