Intel ME (管理引擎) 风险评估

VaultBoot支线任务之暗影之环：Intel ME（管理引擎）风险评估

背景

2021年5月12日，美国政府发布了关于改善国家网络安全的行政命令 （EO 14028），以应对多个重要议题，SBOM（软件物料清单）就是其中之一，它试图通过要求供应商提供更多有关其产品/解决方案组件的信息来改善软件供应链的安全性。几周后，网络安全和基础设施安全局 （CISA）为了回应EO 14028，在 RSA 2021会议正式公布VBOS计划 ， 即 "操作系统更底层的漏洞"， 以促进 SBOM 扩展到固件级别，请记住固件也是一种软件，只是比较特殊的软件。虽然过去的20年中，主流信息安全社区都尝试忽略掉操作系统以下层级的安全风险，但随着隐蔽战争对抗的升级让行业无法回避这个安全领域的“硬骨头”。

Intel ME安全简介

”复杂性“的概念本身就过于复杂难以简单的解释，而安全领域的从业者则每天都在和"复杂性"打交道，有些威胁和风险相对容易理解和找出已知风险的应对之策，虽然这通常会很耗时，但有些风险并不是那么容易理解，要制定防护措施的难度更甚，Intel ME属于这一类 。早在2008年，Intel就将ME（管理引擎）引入芯片组，它比操作系统具有更高的特权，这意味着操作系统级别的安全检测方案对ME几乎是无效的，更重要的是，绝大部分用户都不知道他们的计算机中有一个独立的“小电脑”存在（请翻阅HardenedVault白皮书中图灵完备性的章节）。安全研究方面，2009 年 Alexander Tereshkin和 Rafal Wojtczuk证明了植入Ring -3 rootkit的可能性（注：在此上下文下“Ring”的概念为，应用：Ring 3，Linux 内核：Ring 0，虚拟化：Ring -1，BIOS/UEFI/SMM：Ring -2，Intel ME：Ring -3）。

另外一项有趣的研究Patrick Stewin于2014年发布的DAGGER，遗憾的是，大多数人在过去10多年中都不知道ME的存在之广泛直到Google决定在部分机器上干掉ME。Intel在KabyLake这一代处理和芯片组发布时给ME有了新的命名：CSME (Converged Security and Management Engine) ，这或许是因为同代芯片组把TXT和BootGuard这两个安全特性绑定在一起的原因。ME/CSME通常是指x86桌面平台的PCH中的一个独立IP，运行过程中也会使用到其他PCH中的IP：

TXE和SPS（Server Platform Service）分别是嵌入式和服务器平台的实现。ME/CSME的发展中其硬件和软件都经过了不断的变化和更新：

威胁模型和攻击面

从攻击面的角度，按照赛博堡垒白皮书中所提及的常规TC（漏洞）和 Maclious TC（后门）的上下文，大体有两种极端的攻击路径：

1）从主机（Host）CPU运行的系统上构建打击链深入到Intel CSME并且植入持久化，这是一个很长的攻击链条：

* Ring 3的漏洞利用（webshell或者应用程序的远程利用）获得普通执行权限

* 利用Ring 0内核漏洞进行提权，这里值得注意的是虽然操作系统内核早已经不是2007年”Attacking the CORE”上下文的那个”CORE“但依旧非常重要，因为内核是通向更底层的入口，这也是赛博堡垒花费大力气打造VED（Vault Exploit Defense）以及基于PaX/GRsecurity完成场景化加固的原因。

* 从目前攻击样本来看不需要过多关注Ring -1虚拟化层。

* 通过绕过芯片组防护机制或者物理攻击攻陷Ring -2的固件，比如coreboot/UEFI/SMM，以达到获得写SPI flash的能力。

* 触发Ring -3（CSME）早期启动阶段（RBE，kernel等在>=CSMEv11版本中无法关闭的模块）或者CSME代码模块的0day或者已知漏洞（比如SA-00086）以获得CSME完整控制权，攻击者可以使用CSME作为跳板开启VISA访问PCH的内部接口。

2）从CSME攻击主机（Host）系统，攻击场景如下：

* 攻击者具备1)的能力前提下，可以直接替换厂商固件并在IOMMU开启前具备执行RS1 DMA操作的能力，这等同于给了CSME上帝模式可以任意读写主机侧操作系统（Linux，Windows，OSX等）内存。

* OEM厂商在固件中有意或者无意的错误配置PSF（Primary Scalable Fabric）以辅助CSME拥有上帝模式。

* CSME使用IMRs直接绕过IOMMU/VT-d进入上帝模式。

值得企业用户注意的是，以上不论哪种攻击场景发生后会给取证工作带来巨大的麻烦，这也是从一开始就需要关注固件安全的原因。

警告：安全研究者们，小心调试和测试你的PoC，任何CSME相关的测试和微调都可能导致PCH烧毁。

ME制造模式

ME制造模式（Manufacturing mode）是CSME一种给OEM厂商维护的运行模式，这种模式下操作系统运行时可以读写CSME区段，值得所有CSO和安全工程师重视的是有一些厂商的服务器主板上有ME制造模式的跳线，即使对于已经有多信任基（比如VaultBoot方案）依然具有一定程度的风险，赛博堡垒在开发和生产Vault 111加固服务器的时候曾经遇到过此类情况，当时联系了其中一家厂商：

我们预期是找到固件层面的解决方案而不是重新设计PCB：

遗憾的是，硬件和固件厂商对于这个领域对整体安全的重要程度的理解过于欠缺，以上对话只是这个行业的冰山一角，这个领域需要更多人的关注。

应该关掉CSME吗?

这个问题的答案不可能直接说Yes or No，你是否信任Intel？或者说Intel和OEM厂商谁植入后门的概率更高？有一些用户非常重视隐私和数字自由的权利，他们愿意承受比普通用户更高的成本去干掉CSME，而大多数用户对Intel依然持有”信仰的飞跃“，这里我们不讨论后门的议题。从CSO和安全工程师的角度，漏洞的问题是每天都会遇到的，那有两个因素你就得考虑了：

* CSME的自身防护能力

从赛博堡垒的角度，第一个因素相对容易量化：

NX（不可执行的栈）最早出现于2000年的PaX中，SMEP是让攻击者在漏洞利用过程中没办法直接在内核中执行用户空间的代码，CET是一种TigerLake开始引入的硬件CFI（代码流完整性），Intel在v15/SPSv6的硬件平台中也加入了支持。

* 有多少CSME提供的安全特性是企业整体方案必须的，CBnT可以用于构建信任根，SGX可以提供飞地计算方案，如果关掉了CSME那你会失去这些安全特性。当然，可以通过其他信任基和加强数据中心重要机型的物理防护管理来进行弥补。

可以关掉CSME吗?

这个问题同样没有标准答案，有一些存在的选项：

值得注意的是以上方法对于关闭SPSv5是无效的，SPSv5由于增加了VFS（虚拟文件系统）导致所有的开源实现的解析器都失效了，赛博堡垒可以提供一种在1U服务器的SPSv5系统中关闭CSME和ME制造模式的方案，但代价同样是失去CSME提供的安全特性：

AMD平台有类似问题吗？

有，AMD有一个类似CSME的实现叫PSP（Platform Security Processor）。

飞地方案SGX/SEV会受到CSME风险困扰吗？

这里罗列三个已知风险：

* 飞地计算本身并非安全，即使没有CSME，侧信道攻击（Meltdown/Spectre及其变种）依然威胁现代x86处理器，比如L1TF。

* 飞地计算的基石MEE可被CSME访问

* AMD SEV相比SGX和CSME的关系，更加依赖PSP固件，所以SEV的威胁模型和SGX不同。

有CSME的开源实现替代吗？

没有，Intel CSME是一个无法被全面审计的黑盒，黑客和安全研究者一直通过对部分代码模块的逆向找到一些有趣的发现，比如架构综述，NSA的隐藏开关，IDLM模块等。开源带来的透明度并不等同于安全，没有源代码的情况下依然可以进行更为耗时的二进制审计。另一方面，闭源也并不代表安全，通常闭源软件的质量差于开源软件，但CSME则是一个例外，CSMEv15引入了更多防护机制的同时也把模糊测试加入了开发流程，不论开源还是闭源软件都会受益于这些技术。

工具

结论

固件领域的防护没有任何银弹可言，几乎都是近身肉搏，和其他安全领域一样，“知己知彼”依然是第一优先级，只有理解了整体架构和攻击方法才能制定出相应的防护方案。从攻击的角度，如果攻击者有能力攻击一个高价值目标，不论你是否有感知都会遭受攻击，这是一场长期的对抗，从企业安全的角度，未来如何取决于今天的安全工程师和CSO的智慧。

赛博堡垒花费了大量的时间处理CSME带来的硬币两面的问题，CSME是VaultBoot方案的一小部分，但却是不可回避的部分，这个层面出现的任何问题都可能让整个纵深防御体系轻易的瓦解，罗马不是一天建成的，但刚铎却可能一天就被毁灭。更重要的是，这么重要的计算机组件并未引起足够的重视，最可怕的不是敌人的强大，而是你并没有认知到敌人的存在。

“因我们并不是与属血气的争战，乃是与那些执政的、掌权的、管辖这幽暗世界的，以及天空属灵气的恶魔争战。” --- 以弗所书6:12

声明：本文来自赛博堡垒，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。