事件

根据github泄漏仓库的时间戳信息，2022年9月30日，一名未确认身份的用户上传了Intel Alder Lake平台的固件整体方案，其中包含参考实现，OEM实现，IBV方案以及相关文档，大小为4.8GB。

2022年10月8日，此次泄漏引起了媒体tom’sHardware的关注和报道，随后泄漏仓库被删除，但安全研究者依然可以时间机器获得泄漏内容。

泄漏的内容

固件供应商	OEM制造商	支持平台	主机固件方案
Insyde	Lenovo	Intel Alder Lake	UEFI

Insyde作为固件整体方案商会持续开发和集成各平台的支持，此次泄漏的内容是Insyde方案的删减版本，仅支持Alder Lake，泄漏的内容有几个比较有趣的内容：

• 由Insyde提供的完整工具链，用于简化OEM厂商的开箱以及BIOS镜像调整工作
• Insyde的定制框架，其封装了兼容EDK2的接口，让ODM/OEM厂商更容易集成平台组件比如Intel FSP
• Intel参考实现以及OEM的实现，这次泄露事件中的OEM主角是Lenovo联想

• Binary blobs：值得注意的是，其中除了各种设备（蓝牙BLE，WiFi，以太网等）所需要的binary blobs外，也包含了三种不同的用于安全特性的ACM：BiosGuard，BootGuard以及TXT

另外，一个值得关注的点是BootGuard开箱所用的密钥堆也在泄漏内容中：

x86启动的前半部的ACM是由Intel签名，后半部则是OEM厂商控制:

让我们祈祷Lenovo并没有将它们用于生产环境，请证明我们是错的！

此次泄漏对用户的风险评估

UEFI原本对高于操作系统权限的SMM（系统管理模式）高度依赖的特性和固件供应链的复杂性导致了较高的安全风险，已经披露的大规模利用的恶意固件和未公开披露的攻击都成为个人用户和数据中心的风险。此次的泄漏内容我们并没有完整的review，但如果其OEM相关实现被真正用于生产环境那势必会缩短攻击者找到漏洞的时间，即使OEM实现并不完整，攻击者也可以通过Insyde定制框架的研究来帮助理解逆向工程的内容，这些因素累加在一起会让用户面临长期的高风险。

开源固件项目可以受益于泄漏内容吗

很遗憾，不能或者非常少。这些材料理论上可以帮助两类人：

* 没有资格获得Intel CNDA的个人或者机构，比如开源固件项目的维护者，这里请注意开源固件项目不可能直接受益于泄漏的内容因为有法律风险
* 尝试理解复杂供应链的研究者

谁对此次事件负责

为数不多的信息来自git log，但依然无法确认其泄漏者：

因为泄漏的是Insyde方案（Insyde框架集成了Intel的资源），或许Insyde会知道更多的内容。

数据中心应该如何应对

由于此次直接影响的机型并没有服务器，但介于服务器固件和桌面有共享部分code base，所以数据中心应该考虑：

• 短期方案：

  • 安全团队和补丁团队合作，保证关键设备升级到最新。
  • 安全运营团队加大对操作系统提权行为的监控和防护
  • 针对现有固件进行威胁检测和审计

• 长期方案：

  • 使用基于coreboot/oreboot的下一代固件框架替换UEFI
  • 配合安全载荷（比如VaultBoot，LinuxBoot等）实现芯片安全特性开箱