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

1 概述

????????北京時間2020年8月7日，瑞士軟件工程師蒂爾·科特曼（Till Kottmann）發(fā)布了英特爾內(nèi)部文件被泄露的信息[1]。約有20GB的被泄露文件已上傳至文件共享網(wǎng)站MEGA，其中部分文件帶有“機密”或“受限制的機密”字樣的標(biāo)記。據(jù)蒂爾·科特曼稱，該信息是由一位匿名黑客提供，此次泄露的文件是一系列文件中的第一部分。這些文件包含各種CPU芯片的設(shè)計數(shù)據(jù)，以及與各種芯片組（可追溯至2016年的CPU的技術(shù)規(guī)格）的內(nèi)部設(shè)計有關(guān)的英特爾知識產(chǎn)權(quán)（設(shè)計資料）、產(chǎn)品指南和手冊[2]。據(jù)TillieKottmann的Twitter配圖顯示，一處源碼的注釋中有“backdoor”字樣，再次引發(fā)了對Intel芯片是否存在后門問題的關(guān)注。

針對此次數(shù)據(jù)泄露事件，安天CERT第一時間取得該數(shù)據(jù)，對相關(guān)文件進行了梳理與分析。

2 泄露文件梳理

????????以下是提供的部分泄露文件夾或文件描述和截圖，詳細文件夾或文件描述見附錄一：

????????? 英特爾ME Bringup指南 + 工具 + 各平臺示例

????????? Kabylake（Purley平臺）BIOS參考代碼和示例代碼+初始化代碼

????????? 英特爾CEDFK（消費電子固件開發(fā)套件）

????????? 適用于各種平臺的芯片/ FSP源代碼包

????????? 各種英特爾開發(fā)和調(diào)試工具

????????? 針對Rocket Lake S和其他平臺的Simics仿真器

????????? 各種路線圖和其他文件

????????? 英特爾為SpaceX制造的相機驅(qū)動程序的二進制文件

????????? 未發(fā)布的Tiger Lake平臺的原理圖、文檔、工具+固件

????????? Kabylake FDK培訓(xùn)視頻

????????? 適用于各種Intel ME版本的Intel Trace Hub +解碼器文件

????????? Elkhart Lake芯片參考和平臺示例代碼

????????? 各種Xeon平臺的Verilog內(nèi)容

????????? 用于各種平臺的BIOS/TXE調(diào)試工具

????????? Bootguard SDK（加密zip壓縮包）

????????? 英特爾Snowridge/Snowfish進程模擬器ADK

????????? 各種原理圖

????????? 英特爾營銷材料模板（InDesign）

3 帶有“backdoor”字樣注釋的文件的初步分析

????????相關(guān)泄露數(shù)據(jù)被解壓縮后，在文件Intel Restricted Secret\purleyrefresh_rc_.zip中存在一個git存儲庫dcpae_uefi_firmware-purley.git。在該庫存儲的文件中，“Svos.aslc”和“MemoryRas.c”中都出現(xiàn)了backdoor的字樣，如下圖所示：

3.1 Svos.aslc分析

????????相關(guān)文件中的注釋內(nèi)容為“Save the RAS backdoor requeset pointer to IOH SR 17”，直譯為“將RAS后門請求集指針保存到IOH SR 17”。RAS三個字母容易被聯(lián)想到RSA算法，但安天工程師從場景和經(jīng)驗判斷，此處的RAS更可能是Reliability、Availability和 Serviceability三個單詞的首字母，意為“可靠性、可用性、可服務(wù)性”。

?由于該結(jié)構(gòu)體在泄露的文件中并未被使用，并且該結(jié)構(gòu)體沒有給出控制函數(shù)，只給出成員函數(shù)ReferenceAcpiTable用于返回成員變量?？晒┓治龅淖糇C較少，暫時沒有明確指向。

3.2 MemoryRas.c分析

????????相關(guān)文件中的注釋內(nèi)容為“This file contains a structure definition for the SVOS backdoor mechanism”，直譯為“此文件包含SVOS后門機制的結(jié)構(gòu)定義”。MemRas模塊提供的接口為內(nèi)存熱添加/刪除實現(xiàn)內(nèi)存RAS流控制。注釋“backdoor”涉及語句作用是存儲結(jié)構(gòu)BIOS_ACPI_PARAM的一個成員變量，存儲變量Data32未發(fā)現(xiàn)在隨后進行使用。

表 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是否存在后門問題，一直有廣泛的猜測，特別是其強化了固件系統(tǒng)（包括提供了遠程管理的支持）后，但本次泄露數(shù)據(jù)是否能形成實證，從相關(guān)分析來看，支撐力尚不足。

????????“backdoor”一詞在網(wǎng)絡(luò)安全領(lǐng)域被定義為“可被用于未經(jīng)授權(quán)地秘密訪問數(shù)據(jù)的計算機功能或缺陷”，其來源包括主觀惡意預(yù)設(shè)、調(diào)試接口在正式產(chǎn)品未關(guān)閉等情況，但預(yù)設(shè)后門是應(yīng)謀求高度隱蔽和難以發(fā)現(xiàn)的。根據(jù)目前網(wǎng)絡(luò)上未經(jīng)證實的討論信息，相關(guān)泄露數(shù)據(jù)英特爾對核心生態(tài)伙伴在簽訂了保密協(xié)議后，是可以獲得分享的。在定向?qū)ν夤蚕淼馁Y料中，把后門用注釋形式標(biāo)識出來，是不太符合邏輯的。從另一角度看，但在硬件領(lǐng)域、包括UEFI/BIOS相關(guān)領(lǐng)域中“backdoor”一詞與網(wǎng)絡(luò)安全中的含義并不完全一致，如UVM用戶指南中有提到寄存器讀寫“后門”機制[4]，對應(yīng)也存在“前門”（frontdoor）機制。如下圖所示：

另外，在Svos.aslc文件的數(shù)據(jù)結(jié)構(gòu)定義中，對于SVOS_SMI_SERVICE_ID字段的注釋文字出現(xiàn)了“Door Bell”（門鈴）的字樣。由于時間關(guān)系，我們尚未跟進分析。

4 初步判斷和關(guān)聯(lián)風(fēng)險建議

????????從目前對于帶有“backdoor”字樣注釋的兩個文件代碼分析來看，尚不能形成指向Intel存在后門的實證。通過領(lǐng)域內(nèi)文獻檢索和相關(guān)功能對比來看，存在相關(guān)代碼是一種正常的工作機制，但注釋內(nèi)容帶來了歧義和質(zhì)疑的可能性。由于相關(guān)內(nèi)容信息量極為龐大，加之芯片本身依然黑箱化，還需要更進一步的大量分析工作，才能形成謹慎、負責(zé)的判斷。同時，作為全球最大的芯片提供者，作為全球IT產(chǎn)業(yè)鏈的最核心上游企業(yè)之一，英特爾公司有義務(wù)作出負責(zé)任的信息說明，來面對相關(guān)質(zhì)疑。此事也說明了核心芯片和外圍機制的機理復(fù)雜性和驗證安全性的難度，更從安全性的角度，說明了避免核心技術(shù)受制于人的關(guān)鍵意義。

????????這一事件可能引發(fā)關(guān)聯(lián)風(fēng)險和次生災(zāi)害。相關(guān)信息快速擴張了全球攻擊組織對Intel芯片的研究分析能力，一些未公開接口和僅在核心開發(fā)生態(tài)中使用的接口會暴露在攻擊者面前，導(dǎo)致一些底層漏洞、機制缺陷被發(fā)現(xiàn)，其內(nèi)置的測試證書也可能被攻擊者用于固件預(yù)置，從而導(dǎo)致更具有隱蔽性的Rootkit、UEFIkit甚至芯片固件級木馬出現(xiàn)，包括可能導(dǎo)致一些更富有想象力的新型攻擊方式。從攻擊側(cè)，核心軟硬件源碼或核心技術(shù)泄露，都會導(dǎo)致一個漫長的多方機會窗口期。這種風(fēng)險影響預(yù)計會長期存在，需要相關(guān)機構(gòu)、客戶、安全廠商予以持續(xù)關(guān)注，需要極度的提升重視。

????????從企業(yè)核心知識資產(chǎn)風(fēng)險到信息資產(chǎn)泄露形成大面積次生災(zāi)害角度看，這一事件為國內(nèi)核心軟硬件和高科技產(chǎn)品研發(fā)生產(chǎn)方面提供了前車之鑒。

附錄一：泄露文件梳理

附錄一：泄露文件梳理

? ? ? ??[1] Twitter：英特爾機密的Lake Platform版本泄露20GB版本

????????https://twitter.com/deletescape/status/1291405688204402689

????????[2] ZDNet：英特爾調(diào)查20GB內(nèi)部文件在線泄露后的違規(guī)行為

????????https://www.zdnet.com/article/intel-investigating-breach-after-20gb-of-internal-documents-leak-online/

????????[3] BIOS_ACPI_PARAM

????????https://www.mail-archive.com/devel@edk2.groups.io/msg10771.html

????????[4] UVM用戶指南中關(guān)于寄存器讀寫"后門"機制

????????https://www.accellera.org/images/downloads/standards/uvm/uvm_users_guide_1.2.pdf

????????[5] uvm設(shè)計分析

????????https://www.cnblogs.com/-9-8/p/8534430.html

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