SGX可能遇到的攻擊

在前幾篇文章中，我介紹了SGX的內部和外部組件的構成，分析了SGX的安全特性，今天我們就來說說SGX可能遇到的攻擊。

邊信道攻擊（Side-channel Attack）

邊信道攻擊是一種對密碼演算法實現的有效的攻擊，英特爾SGX多年來一直因其缺乏對各種邊信道攻擊的防禦而被批評。雖然英特爾總是警告用戶，必須以防止邊信道攻擊的方式編寫enclave，但是一種完全安全的技術是不會對enclave開發人員施加這樣的額外要求的。下面總結了對英特爾SGX的一些攻擊，以便你可以了解到執行此類攻擊所需的各種環境，以及執行這些攻擊可以竊取哪些設備及系統信息。

英特爾SGX上的緩存攻擊

為了在英特爾SGX enclave上執行緩存計時攻擊，攻擊者將兩個內核線程固定到兩個共享相同物理內核和L1緩存的邏輯內核（參見下圖）。此時，受害者線程運行的演算法版本容易受到enclave內部的緩存攻擊。使用RDPMC指令完成對高速緩存行的探測，該指令要求計數器以管理員模式啟動，這完全在SGX的安全模型中。

使用共享內存而不是ECALL / OCALL執行與enclave的通信，則不必從正在運行的enclave切換上下文，這就是攻擊可能發生的環境。而ECALL / OCALL則會導致整個緩存被清除，從而阻止攻擊的進行。

另外，攻擊線程必須處於同一進程中，因為進程上下文切換需要更新頁表（Page Table ，PT），因此必須更改包含PR的基址的CR3寄存器，這會觸發TLB和L1緩存被刷新。

而SGX SDK的AES實現後，就不容易受到這種邊信道攻擊。

AsyncShock攻擊：利用英特爾SGX Enclave中的同步漏洞

AsyncShock攻擊的原理就是充分利用enclave內現有的同步錯誤，特別是，它有助於利用Use After Free（UAF）漏洞和Time Of Check Time Of Use（TOCTOU）漏洞。控制該平台的攻擊者（在英特爾SGX的攻擊模型中）可以隨時中斷enclave線程。

使用mprotect系統調用來中斷線程，然後刪除頁面上的讀取和執行許可權。因為要在檢查是否允許訪問EPC頁面之前執行傳統的頁面遍歷，所以應用程序可以清除知道enclave訪問了哪些內存頁面（即使它無法查看頁面包含的內容）。當線程退出enclave時，執行將在不受信任環境中的程序中恢復。

此時，應用程序啟動允許執行的第一個線程，從包含free(3)函數的代碼頁中刪除讀取和執行許可權。當線程調用free(3)函數時，發生訪問衝突事件，導致應用程序捕獲AEX和segmentation fault （即段錯誤,一般都是出現了非法的地址寫法操作導致的）。在允許線程繼續之前，將為此頁面恢復許可權，不過只刪除包含調用指令的頁面的許可權。當下一個標記的頁面被點擊，則會導致另一個AEX和segmentation fault，此時會發出free(3)函數返回的信號。在信號處理程序中，許可權被再次恢復。此時，第一個線程停止，第二個線程啟動並進入enclave。此樣本的代碼可以在下面找到：

// Thread 1 enters the enclave

...

free(pointer);

// Thread 1 is interrupted, exits the enclave

pointer = NULL;

...

// Thread 2 enters the enclave

...

if (pointer != NULL) {

// Thread 2 uses a pointer to freed memory

}

...

結合結構內部的函數指針和為新分配重用已釋放內存的內存分配器，這些類型的漏洞有可能會允許攻擊者實施遠程執行代碼（RCE）。TOCTOU漏洞可能允許在enclave中使用不正確的參數，這也可能具有巨大的安全隱患。這可以從以下的樣本中看出：

...

/* 1 */ static int g_index = 0;

/* 2 */ static int g_value = 0;

/* 3 */ static int g_array[256];

/* 4 */

/* 5 */ void ocall_set_index(int index) {

/* 6 */ g_index = g_index;

/* 7 */ }

/* 8 */

/* 9 */ void ocall_set_value(int value) {

/* 10 */ if (g_index

/* 11 */ g_array[g_index] = value;

/* 12 */ }

/* 13 */ }

...

可能看起來無法使用無效的g_index訪問g_array，因為第一個線程可以執行ocall_set_value函數的第9行和第10行，然後被中斷。然後，第二個線程可以執行ocall_set_index的第5到第7行，以在第一個線程檢查之後更改g_index的值。這樣第一個線程就可以被恢復，並且將使用第二個線程設置的g_index的值完成第11行執行的訪問，這就可以導致Out Of Bounds（OOB）訪問。

不過這類攻擊需要完全控制平台，知道enclave內運行的代碼，並在其中發現同步漏洞。防止這種攻擊的最佳方法是在enclave內禁用多線程，但這顯然會妨礙程序的性能。另一種解決方案是加密enclave的代碼，並使用遠程認證過程為enclave提供解密其代碼所需的密鑰。

用分支追蹤辦法（Branch Shadowing）推斷SGX enclave內部的詳細控制流程

我們把進行分支預測的硬體稱為Branch Predictor，也稱之為Branch Prediction Unit(BPU)。BPU的主要作用是預測接下來執行的指令分支，也就是說BPU作用於pipeline的前端(front-end)。

在CPU內部，BPU使用Branch Target Buffer（BTB）來記錄對分支預測有用的信息。這導致需要大容量的Branch Target Buffer（BTB）來存儲這些數據，不過實際上BTB的容量是有限的。雖然對分支預測有用的信息僅在處理器內部使用，但英特爾SGX在enclave模式切換期間不會清除其分支預測的歷史記錄信息。這就允許在enclave內獲取（或不獲取）的分支影響enclave外部的分支的預測。因為，我們就開發了一種被稱為分支追蹤辦法（Branch Shadowing）的技術來推斷正在運行的enclave控制流程。

分支追蹤辦法的原理就是在不受信任的環境中複製enclave程序的控制流程，然後仔細的選擇映射此新代碼的地址，以便在BTB內部引入衝突事件。首先在enclave代碼內執行分支，然後在被跟蹤的代碼中執行分支，此時第二個分支的預測將受到第一個分支的結果的影響。要知道CPU預測的內容，最後一個分支記錄（ Last Branch Record，LBR）只能在不受信任的環境中使用，因為它對於enclave來說是禁用的。

為了使此攻擊生效，必須儘可能頻繁的中斷enclave執行，以執行必要的安全檢測，進而推斷出enclave的控制流程。APIC定時器每隔50個周期就回去中斷執行，如果需要更精確的數據，則禁用CPU緩存，這樣APIC定時器每隔5個周期就回去中斷執行。

以下就是在enclave內發生的條件分支的檢測結果（綠色表示採用分支的情況，紅色表示沒有採用分支的情況）：

1.如果執行enclave的條件分支指令（ conditional branch instruction），則相應的信息就會存儲在BTB內。由於這是在enclave內發生的，因此LBR不會報告此信息；

2.APIC計時器中斷了enclave執行，並由操作系統獲得控制權；

3.操作系統啟用LBR並執行追蹤代碼；

4.如果佔用了enclave中的分支，則BPU會精確地預測所佔用的分支，即使目標地址無效，也可做到這一點，因為它位於enclave內。如果沒有佔用enclave中的分支，則BPU就無法會精確的預測所佔用的分支。

5.通過禁用和檢索LBR內容，操作系統可以通過檢查被追蹤的條件分支是否被正確預測來了解enclave分支是否被佔用。

另外，我們提出的檢測無條件分支和間接分支（目標地址無法通過攻擊恢復）也大體是這個原理。此攻擊需要完全控制平台，並了解在enclave內執行的代碼。另外，它還引入了enclave可能能夠檢測到的顯著運行減速（但它並不像執行RDTSC那麼簡單，因為在enclave內部不允許這樣做）。

對SGX安全性的擔憂

SGX用戶擔憂的第一個問題是，他們必須也不得不無條件地信任英特爾。值得注意的是，英特爾表示，它不會在每個CPU晶元的生產設備上重新設計 Root Provisioning Key。如果真像他們所說，則安全性將得不到保障。此外，由英特爾簽名的enclave也獲得了特殊的許可權，比如被允許執行的Launch Enclave (LE)可以決定哪些enclave允許執行白名單。開發人員需要註冊英特爾程序，才能簽名發布版本的enclave。

第二個問題是，惡意軟體可能會在enclave內執行其惡意代碼，基本上沒有任何約束。不過，enclave內的代碼沒有I/O，它完全依賴於其附帶的訪問網路、文件系統等應用程序等。因此，從技術上講，分析應用程序可以告訴你關於enclave對系統影響的很多事情，減輕你的這個擔憂。另一方面，缺乏可信I/O，也會導致用戶信息保護乏力，不過因特爾並且已經在這個主題上下了一些功夫，設計了一個專有的解決方案，如受保護的音頻視頻路徑（Protected Audio Video Path ，PAVP）和像SGXIO這樣的方案。

第三個問題是關於Meltdown和Spectre對SGX enclave的影響。雖然不容易受到Meltdown的影響，但卻很容易受到Spectre變體的影響，允許讀取enclave內存和寄存器值。這使得平台的Seal Key能夠恢復，進而導致認證密鑰被恢復，這就有效地繞過了SGX提供的整體安全性措施。英特爾發布了代碼更新補丁以防止這些攻擊，並且根據安全版本號（SVN），用戶還能夠確保這些補丁是否已經被應用。2018年7月，加州大學河濱分校的研究人員發表了一篇論文，公布了命名為SpectreRSB的新Spectre漏洞。和已披露的其它Spectre漏洞類似，SpectreRSB利用了預測執行功能——這是所有現代CPU都包含的功能，通過提前計算操作和拋棄不需要的數據來改進性能。與其它Spectre漏洞不同的是，SpectreRSB利用了返回堆棧緩衝（Return Stack Buffer，RSB），能從預測執行中恢複數據。研究人員表示他們使用SpectreRSB恢復了其它進程的數據，甚至欺騙RSB泄露SGX的秘密。該攻擊適用於英特爾、AMD和ARM的處理器。

總結

雖然目前還有很多問題，但英特爾SGX是一項很有前景的技術，必定它才處於起步階段。它滿足了計算受信的安全需求，不僅允許enclave受到保護，免受平台上其他軟體的攻擊，而且還以特殊的方式避免運算性能的影響。它在執行安全保護的同時，給平台所有者一定程度的執行控制許可權，以允許必要的資源管理。認證過程會以安全加密的形式發送到enclave，藉助附加的SDK，開發支持SGX的應用程序就變得非常容易。

然而，目前的Intel SGX版本仍然存在一些問題。不幸的是，由於邊信道攻擊，使得平台的安全性受到了限制，這就迫使開發人員採用必要的措施，以確保他們的程序不能被攻擊。而最理想的狀態是，開發人員不需要擔心這些攻擊，SGX應該確保這些攻擊是不可能發生的。因為，通過加密enclave的代碼並通過遠程認證認證密鑰，就能防止這些攻擊，但這個過程太麻煩了。

最後，我要說的是應該對Intel SGX抱有極大的信心。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！