.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
我們將在本文中詳細討論在可信平台模塊(TPM) 2.0參考實現代碼中發現的兩個漏洞。這兩個漏洞，即越界寫入（CVE-2023-1017）和越界讀取（CVE-2013-1018），影響了多個TPM 2.0軟件實現（如虛擬化軟件使用的軟件）以及多個硬件TPM。
介紹2021年10月，微軟發布了Windows 11。其中一個突出的安裝需求是需要可信平台模塊(TPM) 2.0。這一需求的含義是，為了能夠在虛擬機中運行Windows 11，虛擬化軟件必須通過對主機上的硬件TPM進行傳遞或通過向其提供虛擬TPM來向VM提供TPM。
我們發現這是一個有趣的漏洞研究主題，因為添加虛擬TPM意味著可以從客戶內部訪問虛擬化軟件的擴展攻擊面，因此它可能用於虛擬機逃逸。作為研究工作的結果，我們發現了兩個安全問題：一個被標識為CVE-2023-1017的越界寫入，另一個被識別為CVE-203-1018的越界讀取。它們可以從用戶模式應用程序通過發送帶有加密參數的惡意TPM 2.0命令來觸發。有趣的是，這兩個漏洞的影響比我們最初想像的要大，鑑於它們源自Trusted Computing Group（簡稱TCG，發布和維護TPM規範的非營利組織）發布的參考實現代碼，這些安全漏洞不僅影響到我們測試的每個虛擬化軟件，也包括硬件實現。
請注意，這篇文章中的大多數評估(例如關於可利用性、影響或受影響的平台)都是基於我們對基於軟件的虛擬TPM的分析，因為我們可以用一種簡單的方式調試它們來執行動態分析，因為調試Hyper-V的虛擬TPM更難，因為它作為一個IUM進程運行。相反，在沒有調試接口的單獨芯片中運行的TPM固件中，了解運行時發生的事情是一個完全不同的問題。事實證明，即使對硬件TPM的固件進行靜態分析也很困難，因為我們試圖分析的少數TPM固件更新碰巧是加密的。因此，缺乏對硬件TPM的具體評估並不意味著它們不受影響，而是由於缺乏可觀察性，我們無法評估它們中的大多數是如何受到影響的。但是，使用本文中發布的概念驗證代碼，至少會驗證一些TPM芯片是易受攻擊的。在嘗試OOB寫入後，芯片將停止響應（即不再識別命令），並需要重新啟動計算機才能再次運行，從而確認其易受攻擊狀態。
受影響的平台以下是受影響的軟件和硬件平台的簡單列表。其中列出的產品，是我們可以藉助本文中提供的PoC證明存在漏洞的產品，但其他TPM（無論是虛擬的還是物理的）也很可能存在漏洞。
在我們進行研究時，易受攻擊的代碼存在於TPM 2.0參考實現的最新可用版本：Trusted Platform Module Library Specification, Family '2.0', Level 00, Revision 01.59 – November 2019；
Windows 10上的Microsoft Hyper-V(受影響模塊:TPMEngUM.dll版本10.0.19041.1415);
VMware Workstation 版本16.2.4 構建-20089737(受影響模塊:tpm2emu.exe -可執行文件中沒有版本信息)；
Qemu和VirtualBox使用的Libtpms/SWTPM (從主分支編譯，提交520a2fa27d27a4ab18f4cf1c597662c6a468565f);
Nuvoton硬件TPM(固件版本：1.3.0.1);
通常，所有固件基於可信計算組參考實現代碼的TPM 2.0都會受到影響。
對雲計算的威脅當前幾乎所有主要的雲計算提供商都提供帶有虛擬TPM的實例，這使得攻擊者可能試圖利用虛擬TPM中的這些漏洞，以繞過虛擬機並破壞主機系統。
亞馬遜AWS已配備了NitroTPM，Nitro TPM：Trusted Platform Module (TPM) 2.0，是一項安全性和兼容性功能，可讓客戶更輕鬆地在其EC2實例中使用依賴於TPM的應用程序和操作系統功能。它符合TPM 2.0規範，可以輕鬆將使用TPM功能的現有本地工作負載遷移到EC2；
Microsoft Azure提供虛擬TPM作為可信啟動的一部分；
谷歌云提供虛擬TPM作為屏蔽虛擬機的部分功能；
Oracle Cloud Infrastructure提供虛擬TPM作為屏蔽實例的一部分。
那些使用基於TCG參考實現的虛擬TPM的提供商預計很容易受到攻擊。以Google Cloud為例，他們的虛擬TPM的核心來自IBM發布的代碼，該代碼自動從TPM 2.0規範的完整源代碼中提取，CryptParameterDecryption函數中的漏洞存在於其中。以微軟Azure為例，他們的虛擬TPM“符合TPM 2.0規範”，我們已經驗證了Windows 10上可用的Hyper-V版本中包含的虛擬TPM確實非常易受攻擊。
關於亞馬遜AWS和Oracle雲基礎設施，除了知道“符合TPM 2.0規範”並鏈接到TCG網站外，我們沒有太多關於他們的信息。
修復參考實例(Reference Implementation)可信計算組織（Trusted Computing Group，TCG）發布了TCG可信平台模塊庫的勘誤表1.4版，並對這兩個漏洞提出了修復建議。
軟件產品微軟在2023年3月的安全更新中修復了Hyper-V中的漏洞。他們對TPM 2.0在Azure的Pluton/HCL/Overlake/Manticore標準服務器上的OOB寫入影響的評估很低，因為只有2個字節覆蓋，目前該團隊還沒有一種易於實現的方法來獲得僅2個字節的EoP或RCE。
微軟還通過提交9bdd9f0aaba5e54b3c314cfff02cf532281a067e修復了他們的開源參考實現。
VMware預計將於2023年4月發布這些漏洞的修復程序。
Libtpms修復了提交324dbb4c27ae789c73b69dbf4611242267919dd4中的漏洞。
Chromium OS修復了提交3b87ed233acb4c76c27872e1ac0b74dc032199f1漏洞。
IBM在提交102893a5f45dbb0b0ecc0eb52a8dd4defe559f92中修復了他們的開源實現。
硬件產品Nuvoton為其NPCT65x TPM芯片發布了安全諮詢SA-003。
聯想發布了關於使用上述Nuvoton TPM的受影響產品的安全諮詢LEN-118320。
查看計算機製造商的網站以獲取TPM固件更新。
技術細節關於TPM加密參數的入門教程如Trusted Platform Module Library Specification，Family 2.0，Part 1：Architecture 第21節“基於會話的加密”中所描述的那樣，一些TPM 2.0命令具有可能需要加密的參數，這些參數可能需要去往TPM或通過TPM進行加密。可以使用基於會話的加密來確保這些參數的機密性。引用規範如下：
並非所有命令都支持參數加密。如果允許基於會話的加密，只有請求或響應的參數區域中的第一個參數可以被加密。參數必須有明顯的大小字段。只有參數的數據部分被加密。 TPM應該支持使用XOR模糊處理的基於會話的加密。對使用CFB模式的分組密碼的支持是特定於平台的。這兩種加密方法（XOR和CFB）不需要填充數據進行加密，因此加密數據大小和純文本數據大小相同。
基於會話的加密使用會話啟動時建立的算法參數以及從特定於會話的sessionKey派生的值。
如果sessionAttributes.decrypt在命令的會話中為SET，並且該命令的第一個參數是一個大小為緩衝區的參數，則使用會話的加密參數對該參數進行加密。
帶有加密參數的TPM 2.0命令由基本命令標頭、handleArea和sessionArea組成，最後是加密的參數parameterArea。結構如下：
如下圖所示，在TPM 2.0參考實現中，ExecCommand.c中的ExecuteCommand函數檢查sessionArea的authorizationSize字段是否至少為9（[1]）。之後，在[2]中，它計算parameterArea的開始（位於sessionArea之後），並將其保存到parmBufferStart變量中。在[3]中，它計算parameterArea的大小，並將其保存到parmBufferSize變量中。然後它調用ParseSessionBuffer()([3])，傳遞parmBufferStart和parmBufferSize作為參數([5], [6])。
SessionProcess.c中的函數ParseSessionBuffer解析命令的sessionArea。如果會話具有Decrypt屬性集（[1]），並且命令代碼允許參數加密，則ParseSessionBuffer調用CryptParameterDecryption()([2])，傳播parmBufferSize([3])和parmBufferStart([4])參數:
CryptParameterDecryption函數中存在的漏洞CryptUtil.c中的函數CryptParameterDecryption對加密的命令參數執行就地解密。
此函數中出現的兩個安全漏洞漏洞1：OOB read(CVE-2023-1018):在[1]中，函數使用BYTE_ARRAY_TO_UINT16宏從parmBufferStart指向的緩衝區中讀取16位字段(cipherSize)，而不檢查是否有任何參數數據超過會話區域。之前在函數ExecuteCommand中執行了唯一的長度檢查，但該檢查只驗證了命令的sessionArea至少有9個字節。因此，如果格式錯誤的命令不包含越過sessionArea的parameterArea，它將觸發越界內存讀取，使TPM在命令結束後訪問內存。
請注意，BYTE_ARRAY_TO_INT16宏不執行任何邊界檢查：
應該使用UINT16_Unmarshal函數來代替，它在從給定的緩衝區讀取之前執行適當的大小檢查。
漏洞2：OOB寫入(CVE-2023-1017):如果提供了適當的parameterArea(避免出現漏洞1)，則parameterArea的前兩個字節將被解釋為要解密的數據的大小（[1]處的cipherSize變量）。在讀取了cipherSize之後，在[2]處，緩衝區指針向前移動2。在[3]中有一個健全性檢查，如果cipherSize值大於實際緩衝區大小，那麼它將被釋放，但這裡有一個問題，在讀取cipherSize 16位字段並將緩衝區指針向前移動2之後，函數會忘記從bufferSize減去2，忽略已經處理的兩個字節。因此，使用比剩餘數據實際大小大2的cipherSize值成功地通過[3]的完整性檢查是可能的。這樣，當調用CryptXORObfuscation()或ParmDecryptSym()函數(分別在[4]和[5]處)來實際解密cipherSize字段後面的parameterArea中的數據時，TPM最終會在緩衝區末尾寫入2個字節，從而導致越界寫入。
一個只有2個字節的OOB寫入一開始可能看起來不是一個非常強大的原語，但去年已有研究人員通過一個值為0x01的單字節OOB寫入，成功地在谷歌Titan M芯片上執行了代碼。
影響1.OOB讀取：CryptUtil.c中的函數CryptParameterDecryption可以讀取接收到的TPM命令結束後的2個字節。如果受影響的TPM沒有將接收到的命令之間的命令緩衝區清零，則可能導致受影響的函數讀取先前命令中已經存在的任意16位值。這取決於實現過程：例如，VMware不會清除請求之間的命令緩衝區，因此OOB讀取可以訪問上一個命令中已經存在的任何值，相反，Hyper-V的虛擬TPM在每次接收到請求時都會用零填充命令緩衝區中未使用的字節，因此OOB訪問最終只讀取零
2.OOB寫入：CryptUtil.c中的函數CryptXORObfuscity/ParmDecryptSym（從CryptParameterDecryption調用）可以在命令緩衝區結束後寫入2個字節，從而導致內存損壞。
第二個漏洞無疑是最有趣的一個。能夠覆蓋有用內容的可能性取決於每個實現如何分配接收TPM命令的緩衝區。例如：
VMware使用大小為0x10000的超大緩衝區，遠遠大於通常的最大TPM命令大小0x1000字節；
Hyper-V使用一個大小為0x1000的靜態變量作為命令緩衝區;
SWTPM使用malloc()分配大小為0x1008的命令緩衝區(8字節用於發送命令前綴，可用於修改位置，加上0x1000字節用於最大TPM命令大小)。
因此，在命令緩衝區附近有一些有用的東西(我們可以用OOB寫入來覆蓋)的可能性實際上取決於實現。上面提到的三個虛擬TPM都使用完全不同的方法來分配命令緩衝區。類似地，在給定硬件TPM的固件的命令緩衝區之後覆蓋一些有用內容的可能性完全取決於特定硬件供應商如何分配用於保存傳入命令的緩衝區。
觸發漏洞為了再現上述2個漏洞中的一個，有必要向目標TPM發送2個命令。在這兩種情況下，第一個命令必須是TPM2_StartAuthSession命令，以啟動授權會話。為簡單起見，我們可以指定TPM_ALG_XOR作為要使用的對稱算法。結果，我們得到一個包含會話句柄的TPM響應。
之後，我們需要發送一個支持參數加密的命令。我們使用了tpm2_creatprimary，儘管其他一些命令可能也能運行。我們在tpm2_creatprimary命令的sessionArea中傳遞上一步中獲得的會話句柄，並在sessionAttributes字段中設置Decrypt標誌。然後:
1.為了再現漏洞1(OOB讀取)，我們發送具有最小有效sessionArea的TPM2_CreatePrimary命令，之後沒有數據，即缺少parameterArea。
2.為了再現漏洞2 (OOB寫入)，我們發送tpm2_creatprimary命令，其總大小等於支持的最大TPM命令大小(0x1000字節)。在本例中，我們確實包含了一個parameterArea，其中cipherSize字段設置為0xfe5 (0x1000 - sizeof(command_base_header) - sizeof(handleArea) - sizeof(sessionArea))，後面跟著0xfe3字節的任意值(填充加密參數的位置)，以完成整個tpm2_creatprimary命令的0x1000字節。
概念驗證.zip文件包含PoC的Python版本(用於在Linux系統上運行)和C版本(用於在Windows機器上運行)。
總結在TPM 2.0參考實現的代碼中發現了兩個安全漏洞：越界讀取和越界寫入。因此，其固件基於可信計算組發布的參考代碼的每個TPM(軟件或硬件實現)都將受到影響。
有趣的是，儘管所有受影響的TPM共享完全相同的易受攻擊的功能，但成功利用的可能性取決於命令緩衝區的實現方式，這部分取決於每個實現。從上述示例可以看到，每個人似乎都以不同的方式處理它：一些人在接收到的請求之間清除命令緩衝區，但另一些人不會；有些通過malloc()在堆中分配命令緩衝區，而另一些則使用全局變量。
本文已經驗證這些漏洞存在於主要桌面虛擬化解決方案(如VMware Workstation、Microsoft Hyper-V和Qemu)中包含的軟件TPM中。最大的雲計算提供商提供的虛擬TPM也可能受到影響。例如，Google Cloud使用IBM發布的代碼自動從TCG參考實現中提取，並且IBM提供的代碼中存在的漏洞也被驗證了。以微軟Azure為例，我們已經提到Windows 10上的Hyper-V受到了影響，由於Azure虛擬機監控程序是基於Hyper-V的，我們預計這兩個漏洞也會出現在Microsoft的雲平台上。
我們預計大多數TPM硬件供應商也會受到影響。由於缺乏調試設置來查看TPM固件在運行時發生的情況，因此很難確認物理芯片中是否存在漏洞。靜態分析可以作為評估硬件TPM是否易受攻擊的替代方法，但在我們設法獲得的少數TPM固件更新中，這些更新是加密的。