【转载】包含“Backdoor”字样的英特尔泄露代码的初步分析

2020-08-13 10:40 作者:合天网安实验室 0人读过 | 我要投稿

原文来自：安天：https://www.antiy.cn/research/notice&report/research_report/20200808.html

1 概述

北京时间2020年8月7日，瑞士软件工程师蒂尔·科特曼（Till Kottmann）发布了英特尔内部文件被泄露的信息[1]。约有20GB的被泄露文件已上传至文件共享网站MEGA，其中部分文件带有“机密”或“受限制的机密”字样的标记。据蒂尔·科特曼称，该信息是由一位匿名黑客提供，此次泄露的文件是一系列文件中的第一部分。这些文件包含各种CPU芯片的设计数据，以及与各种芯片组（可追溯至2016年的CPU的技术规格）的内部设计有关的英特尔知识产权（设计资料）、产品指南和手册[2]。据TillieKottmann的Twitter配图显示，一处源码的注释中有“backdoor”字样，再次引发了对Intel芯片是否存在后门问题的关注。

针对此次数据泄露事件，安天CERT第一时间取得该数据，对相关文件进行了梳理与分析。

2 泄露文件梳理

以下是提供的部分泄露文件夹或文件描述和截图，详细文件夹或文件描述见附录一：

➢ 英特尔ME Bringup指南 + 工具 + 各平台示例

➢ Kabylake（Purley平台）BIOS参考代码和示例代码+初始化代码

➢ 英特尔CEDFK（消费电子固件开发套件）

➢ 适用于各种平台的芯片/ FSP源代码包

➢ 各种英特尔开发和调试工具

➢ 针对Rocket Lake S和其他平台的Simics仿真器

➢ 各种路线图和其他文件

➢ 英特尔为SpaceX制造的相机驱动程序的二进制文件

➢ 未发布的Tiger Lake平台的原理图、文档、工具+固件

➢ Kabylake FDK培训视频

➢ 适用于各种Intel ME版本的Intel Trace Hub +解码器文件

➢ Elkhart Lake芯片参考和平台示例代码

➢ 各种Xeon平台的Verilog内容

➢ 用于各种平台的BIOS/TXE调试工具

➢ Bootguard SDK（加密zip压缩包）

➢ 英特尔Snowridge/Snowfish进程模拟器ADK

➢ 各种原理图

➢ 英特尔营销材料模板（InDesign）

3 带有“backdoor”字样注释的文件的初步分析

相关泄露数据被解压缩后，在文件Intel Restricted Secret\purleyrefresh_rc_.zip中存在一个git存储库dcpae_uefi_firmware-purley.git。在该库存储的文件中，“Svos.aslc”和“MemoryRas.c”中都出现了backdoor的字样，如下图所示：

3.1 Svos.aslc分析

相关文件中的注释内容为“Save the RAS backdoor requeset pointer to IOH SR 17”，直译为“将RAS后门请求集指针保存到IOH SR 17”。RAS三个字母容易被联想到RSA算法，但安天工程师从场景和经验判断，此处的RAS更可能是Reliability、Availability和 Serviceability三个单词的首字母，意为“可靠性、可用性、可服务性”。

由于该结构体在泄露的文件中并未被使用，并且该结构体没有给出控制函数，只给出成员函数ReferenceAcpiTable用于返回成员变量。可供分析的佐证较少，暂时没有明确指向。

3.2 MemoryRas.c分析

相关文件中的注释内容为“This file contains a structure definition for the SVOS backdoor mechanism”，直译为“此文件包含SVOS后门机制的结构定义”。MemRas模块提供的接口为内存热添加/删除实现内存RAS流控制。注释“backdoor”涉及语句作用是存储结构BIOS_ACPI_PARAM的一个成员变量，存储变量Data32未发现在随后进行使用。

表 1 BIOS_ACPI_PARAM[3]

typedef struct {

// IOAPIC Start

UINT32 PlatformId;

UINT32 IoApicEnable;

UINT8 ApicIdOverrided :1;

UINT8 RES0 :7;

// IOAPIC End

// Power Management Start

UINT8 Rsvd_Pms_0 :1;

UINT8 CStateEnable :1;

UINT8 C3Enable :1;

UINT8 C6Enable :1;

UINT8 C7Enable :1;

UINT8 MonitorMwaitEnable :1;

UINT8 PStateEnable :1;

UINT8 EmcaEn :1;

UINT8 HWAllEnable :2;

UINT8 KBPresent :1;

UINT8 MousePresent :1;

UINT8 TStateEnable :1;

UINT8 TStateFineGrained: 1;

UINT8 OSCX :1;

UINT8 RESX :1;

// Power Management End

// RAS Start

UINT8 CpuChangeMask;

UINT8 IioChangeMask;

UINT64 IioPresentBitMask;

UINT32 SocketBitMask; //make sure this is at 4byte boundary

UINT32 ProcessorApicIdBase[8];

UINT64 ProcessorBitMask[8];

UINT16 MemoryBoardBitMask;

UINT16 MemoryBoardChgEvent;

UINT32 MmCfg;

UINT32 TsegSize;

UINT64 MemoryBoardBase[8];

UINT64 MemoryBoardRange[8];

UINT32 SmiRequestParam[4];

UINT32 SciRequestParam[4];

UINT64 MigrationActionRegionAddress;

UINT8 Cpu0Uuid[16];

UINT8 Cpu1Uuid[16];

UINT8 Cpu2Uuid[16];

UINT8 Cpu3Uuid[16];

UINT8 Cpu4Uuid[16];

UINT8 Cpu5Uuid[16];

UINT8 Cpu6Uuid[16];

UINT8 Cpu7Uuid[16];

UINT8 CpuSpareMask;

UINT8 Mem0Uuid[16];

UINT8 Mem1Uuid[16];

UINT8 Mem2Uuid[16];

UINT8 Mem3Uuid[16];

UINT8 Mem4Uuid[16];

UINT8 Mem5Uuid[16];

UINT8 Mem6Uuid[16];

UINT8 Mem7Uuid[16];

UINT8 Mem8Uuid[16];

UINT8 Mem9Uuid[16];

UINT8 Mem10Uuid[16];

UINT8 Mem11Uuid[16];

UINT8 Mem12Uuid[16];

UINT8 Mem13Uuid[16];

UINT8 Mem14Uuid[16];

UINT8 Mem15Uuid[16];

UINT16 MemSpareMask;

UINT64 EmcaL1DirAddr;

UINT32 ProcessorId;

UINT8 PcieAcpiHotPlugEnable;

// RAS End

// VTD Start

UINT64 DrhdAddr[3];

UINT64 AtsrAddr[3];

UINT64 RhsaAddr[3];

// VTD End

// BIOS Guard Start

UINT8 CpuSkuNumOfBitShift;

// BIOS Guard End

// USB3 Start

UINT8 XhciMode;

UINT8 HostAlertVector1;

UINT8 HostAlertVector2;

// USB3 End

// HWPM Start

UINT8 HWPMEnable:2; //HWPM

UINT8 AutoCstate:1; //HWPM

UINT8 HwpInterrupt:1; //HWP Interrupt

UINT8 RES1:4; //reserved bits

// HWPM End

// PCIe Multi-Seg Start

// for 8S support needs max 32 IIO IOxAPIC being enabled!

UINT8 BusBase[48]; // MAX_SOCKET * MAX_IIO_STACK. Note: hardcode

due to ASL constraint.

UINT8 PCIe_MultiSeg_Support; // Enable /Disable switch

// for 8S support needs matching to MAX_SOCKET!

UINT8 PcieSegNum[8]; // Segment number array. Must match

MAX_SOCKET. Note: hardcode due to ASL constraint.

// PCIe Multi-seg end

// Performance Start

UINT8 SncAnd2Cluster; //1=SncEn and NumCluster=2, otherwise 0

// Performance End

} BIOS_ACPI_PARAM;

3.3 “backdoor”的初步猜测

对于Intel CPU是否存在后门问题，一直有广泛的猜测，特别是其强化了固件系统（包括提供了远程管理的支持）后，但本次泄露数据是否能形成实证，从相关分析来看，支撑力尚不足。

“backdoor”一词在网络安全领域被定义为“可被用于未经授权地秘密访问数据的计算机功能或缺陷”，其来源包括主观恶意预设、调试接口在正式产品未关闭等情况，但预设后门是应谋求高度隐蔽和难以发现的。根据目前网络上未经证实的讨论信息，相关泄露数据英特尔对核心生态伙伴在签订了保密协议后，是可以获得分享的。在定向对外共享的资料中，把后门用注释形式标识出来，是不太符合逻辑的。从另一角度看，但在硬件领域、包括UEFI/BIOS相关领域中“backdoor”一词与网络安全中的含义并不完全一致，如UVM用户指南中有提到寄存器读写“后门”机制[4]，对应也存在“前门”（frontdoor）机制。如下图所示：

另外，在Svos.aslc文件的数据结构定义中，对于SVOS_SMI_SERVICE_ID字段的注释文字出现了“Door Bell”（门铃）的字样。由于时间关系，我们尚未跟进分析。

4 初步判断和关联风险建议

从目前对于带有“backdoor”字样注释的两个文件代码分析来看，尚不能形成指向Intel存在后门的实证。通过领域内文献检索和相关功能对比来看，存在相关代码是一种正常的工作机制，但注释内容带来了歧义和质疑的可能性。由于相关内容信息量极为庞大，加之芯片本身依然黑箱化，还需要更进一步的大量分析工作，才能形成谨慎、负责的判断。同时，作为全球最大的芯片提供者，作为全球IT产业链的最核心上游企业之一，英特尔公司有义务作出负责任的信息说明，来面对相关质疑。此事也说明了核心芯片和外围机制的机理复杂性和验证安全性的难度，更从安全性的角度，说明了避免核心技术受制于人的关键意义。

这一事件可能引发关联风险和次生灾害。相关信息快速扩张了全球攻击组织对Intel芯片的研究分析能力，一些未公开接口和仅在核心开发生态中使用的接口会暴露在攻击者面前，导致一些底层漏洞、机制缺陷被发现，其内置的测试证书也可能被攻击者用于固件预置，从而导致更具有隐蔽性的Rootkit、UEFIkit甚至芯片固件级木马出现，包括可能导致一些更富有想象力的新型攻击方式。从攻击侧，核心软硬件源码或核心技术泄露，都会导致一个漫长的多方机会窗口期。这种风险影响预计会长期存在，需要相关机构、客户、安全厂商予以持续关注，需要极度的提升重视。

从企业核心知识资产风险到信息资产泄露形成大面积次生灾害角度看，这一事件为国内核心软硬件和高科技产品研发生产方面提供了前车之鉴。