簡介

《A tale of two worlds: Assessing the vulnerability of enclave shielding runtimes》是CCS 2019的一篇論文，作者是Jo Van Bulck。

本文針對Enclave Interface Sanitization從ABI、API層面尋找漏洞。漏洞涉及Intel SGX-SDK（Edger8r）、Microsoft OpenEnclave(Deep Copy Marshalling)、Google Asylo和Rust Compiler等多個開源項目。

相關(guān)工作

相關(guān)工作如DarkROP、Guard‘s Dilemma更關(guān)注在Enclave內(nèi)利用傳統(tǒng)內(nèi)存安全漏洞（的技巧）。

A Tale of Two Worlds更關(guān)注各個SGX軟件棧的漏洞態(tài)勢及Enclave安全模型下的新型漏洞。在ABI層關(guān)注Enclave線程棧切換、寄存器狀態(tài)清理；在API層關(guān)注pointer和size參數(shù)。即Enclave進(jìn)入及同步退出過程中的Sanitization和Defensive Check。

Boomerang關(guān)注TrustZone平臺下Enclave內(nèi)使用的指向Enclave外的指針的消毒缺陷。本文關(guān)注指向Enclave內(nèi)的指針的消毒缺陷，與Boomerang正交。

Practical enclave malware with Intel SGX關(guān)注Enclave內(nèi)惡意軟件的危害（$?$攻擊者可依次攻陷遠(yuǎn)程服務(wù)Enclave $\to$ Enclave’s Host）

表1枚舉了ABI/API層的漏洞類型/攻擊向量。

ABI層攻擊向量

攻擊向量1：Status Flag Registers

SGX依靠Runtime清理大部分狀態(tài)標(biāo)識寄存器。Sancus只讓Runtime處理Interrupt Flag。TrustZone硬件層將狀態(tài)標(biāo)識寄存器及安全世界棧寄存器都自動清理了。該攻擊向量利用情況：

Direction Flag
$┌$Intel SGX-SDK(CVE-2019-14565)/OpenEnclave(CVE-2019-1370)$┘$
進(jìn)入Enclave時，tRTS未清除Direction Flag，rep指令操作方向被攻擊者控制。
如tRTS Bridge為output動態(tài)分配內(nèi)存并清零，清零過程中，攻擊者置位DF將output前Enclave堆幀（可能保存密鑰）清零，而output內(nèi)存未清零，殘留數(shù)據(jù)泄漏。

Alignment Check Flag
$┌$Intel SGX-SDK$┘$
進(jìn)入Enclave時，tRTS未檢查Alignment Check Flag。攻擊者置位AC標(biāo)識寄存器時，secret=0時訪問AB不觸發(fā)#AC異常，secret=1時訪問BC觸發(fā)#AC（AC清零則允許奇地址訪問16Bit，AC置位時訪問奇地址觸發(fā)#AC異常，AEX返回后仍無法訪問導(dǎo)致程序無法繼續(xù)運(yùn)行，對此可清零對齊掩碼CR0.AM暫時禁用對齊檢查）。此差異可反推secret。（頁/段錯誤側(cè)信道歸因于Enclave內(nèi)依賴OS頁表機(jī)制）。

攻擊向量2：調(diào)用棧

Graphene 新建線程可通過OCALL Ret將線程棧恢復(fù)成其他線程OCALL時保存的上下文（其他線程可能已經(jīng)OCALL Ret $\to$ ECALL Ret，但OCALL Ret并不會刪除OCALL時備份的上下文）。

SGX-LKL 新生線程可通過signal handler cmd進(jìn)入Enclave，從未初始化內(nèi)存中錯誤地恢復(fù)上下文。

Sancus RTS 存在第一項所說的問題（恢復(fù)成OCALL備份的上下文）。此外，其利用jmp指令退出Enclave，跳轉(zhuǎn)地址是程序指定的寄存器值，能夠錯誤地跳轉(zhuǎn)到Enclave內(nèi)其它地方。

攻擊向量3：Register State

退出Enclave時需要保存并徹底清理寄存器狀態(tài)。但EEXIT將清理的任務(wù)交給軟件完成，AEX硬件流程中未對DF進(jìn)行清理（按理說，微碼設(shè)計中肯定是考慮了所有寄存器，畢竟寄存器數(shù)量是固定的，難道是認(rèn)為DF不重要所以沒清理？）。AEX中泄露的DF信息能被側(cè)信道手段用于感知Enclave內(nèi)字符串操作方向。

該攻擊向量的利用情況：

• SGX-LKL利用setjmp/longjmp函數(shù)在Enclave進(jìn)出時簡單地備份和恢復(fù)上下文。但setjmp沒有清理所有CPU狀態(tài)，使得攻擊者在uRTS能夠Dump XMM寄存器。（建議EEXIT前覆寫敏感的寄存器）

API層攻擊向量

主要關(guān)注Sanitization層指針、變長緩沖區(qū)的處理。

攻擊向量4：指針

跨越Enclave安全邊界的指針應(yīng)該恰當(dāng)?shù)刂赶蝾A(yù)期的共享內(nèi)存區(qū)域。

該攻擊向量利用情況如下：

OpenEnclave OEEDGER8R生成的橋函數(shù)(Listing 2)中，檢查傳參指針p_host_args報錯后仍然使用之，當(dāng)p_host_args指向Enclave時，會造成Enclave內(nèi)存覆寫。(Listing 2)(CVE-2019-0876)

Built-in _handle_get_sgx_report() ECALL中缺乏對傳參指針的檢查，導(dǎo)致Enclave內(nèi)存覆寫。

Google Asylo在Intel SGX SDK上增加了新的抽象層，該文找到14個有問題的[user_check]使用實例，發(fā)現(xiàn)Write 0原語等。Listing 8的ecall_dispatch_trusted_call中unmarshall [user_check] buffer之前未進(jìn)行檢查；并且在判斷輸入時錯以為sgx_is_outside_enclave $?$ not sgx_is_within_enclave。

Graphene在Enclave部署LibOS兼容Legacy Binary Application。但未對argv和envp指針進(jìn)行檢查。enclave_ecall_thread_start()沒有檢查傳入的不可信函數(shù)指針，能夠任意地址跳轉(zhuǎn)，構(gòu)成代碼重用攻擊。

SGX-LKL也在Enclave部署LibOS（使用Linux Kernel Library）兼容Legacy Binary Application。但__sgx_init_enclave()未對argv參數(shù)消毒并直接傳給Binary App，最終導(dǎo)致信息泄露。
由于Enclave不支持rdtsc指令會觸發(fā)SIGILL，SGX-LKL從不可信環(huán)境獲取rdtsc結(jié)果，在Enclave內(nèi)信號處理句柄傳參siginfo補(bǔ)足（case SIGILL）。攻擊者控制siginfo指向Enclave內(nèi)任意地址（恰巧siginfo->signum==SIGILL），siginfo->arg被當(dāng)作rdtsc值使用【將Enclave內(nèi)存（即rdtsc值）回顯到不可信環(huán)境，為了輔助攻擊？可能需要復(fù)現(xiàn)代碼來理解】。依據(jù)siginfo - > signum（實為攻擊者指定的任意內(nèi)存）差異，代碼將執(zhí)行不同case分支，分支的時延差異等能用于側(cè)信道反推Enclave內(nèi)存。(Listing 9)

Sancus Listing 10的__sm_handle_input是自動生成的Bridge函數(shù)，用于解密傳入Enclave的輸入，但未檢查payload。當(dāng)payload指向Enclave內(nèi)時，將對Enclave內(nèi)容進(jìn)行解密，造成信息泄露。
此外，Sancus的Trusted Loader Enclave Code未對輸入指針有效性進(jìn)行檢查。

攻擊向量5：String

Intel SGX SDK CHECK_UNIQUE_POINTER檢查操作前的strlen直接對未檢查的_tmp_s進(jìn)行長度測量。攻擊者單步執(zhí)行（利用sgx-step攻擊）strlen函數(shù)，函數(shù)判斷每一個字節(jié)時直到0終止符，會置位Page Access位，如果Access位未置位，推斷此地址（減一）存儲的值為0終止符。(CVE-2018-3626)

圖4說明了攻擊的具體過程。1）線程A調(diào)用ecall_encrpytString，2）在最后一輪AEX時觸發(fā)中斷（通過Dummy Page頁錯誤，或時鐘中斷），3）配置定時器用于周期性觸發(fā)時鐘中斷，4）線程B調(diào)用ECALL中的strlen訪問線程A的SSA中的XMM0，5）在每次定時器觸發(fā)時鐘中斷時，6）檢查并清除Page的Access位，以

算法1揭示了從已知的Sbox(0)（0指側(cè)信道反推出的0終止符）和Cyphertext[ShiftRows(Length)]推出Key[ShiftRows(Length)]密鑰字節(jié)。

下圖給了一個更加形象的例子。

Intel針對該攻擊棄用了[sizefunc]EDL屬性，并要求不可信環(huán)境提供字符串長度，以此長度在Enclave內(nèi)設(shè)置字符串的0終止符。

OpenEnclave 針對strlen側(cè)信道也要求不可信環(huán)境提供字符串長度，但未對字符串添加0終止符，導(dǎo)致Enclave函數(shù)操作一個non-null-terminated字符串。（CVE-2019-0876）

攻擊向量6：整數(shù)溢出

攻擊者如果能操控共享內(nèi)存/Enclave內(nèi)存布局（如傳入一個剛好位于Enclave基地址前的指針），就能更有效的利用此漏洞。對此，運(yùn)行時需要安全地使用不可信環(huán)境提供的size計算變長buffer的結(jié)束地址。

Fortanix Rust-EDP 如Listing4所示，is_user_range()驗證UserSafe Type（Rust Type System）時，變長Buffer的end可能出現(xiàn)整數(shù)溢出繞過Line5的檢查。

Google Asylo 判斷輸入時錯以為$sgx\_is\_outside\_enclave?notsgx\_is\_within\_enclave$，未理解$outside=?inside$。（如Listing 8所示，“攻擊向量4指針”中提到過）

Graphene-SGX 存在第1項、第2項（攻擊向量7）提到的問題。Graphene通過OCALLOC在Enclave外開辟空間存放OCALL參數(shù)和返回值，它只在進(jìn)入Enclave時檢查Host棧指針嚴(yán)格落在Enclave外，OCALLOC可能讓Host棧溢出進(jìn)入ELRANGE（Enclave所占用的虛擬地址空間）但未對此檢查，讀寫存放OCALL參數(shù)返回值的內(nèi)存（可能在Enclave內(nèi)）會導(dǎo)致信息泄漏或內(nèi)存破壞。

Keystone 如Listing 12所示，當(dāng)epm_base=0x82800000且epm_size=100000，addr=0x1且size=0xffffffffffffffff時，Line 4的檢查會因為整數(shù)溢出而被繞過。

Sancus tRTS提供的sancus_is_outside_sm()未能有效檢查跨越Enclave地址空間或整數(shù)溢出環(huán)繞整個16位地址空間的不可信buffer。

攻擊向量8：Double Fetch

前面的攻擊向量關(guān)注不可信指針解引用spatial層面。攻擊向量8關(guān)注temporal層面。

• Graphene-SGX ms指針一直處uRTS（OCALLOC），未被拷貝進(jìn)Enclave，在ms->ms_addr檢查和使用期間，攻擊者可以暫停線程并替換ms->ms_addr指向Enclave內(nèi)，進(jìn)而造成可信內(nèi)存泄漏。（典型的Double Fetch/TOCTOU）
  

攻擊向量9：Iago/OCALL返回值

SGX SDK往往提供較少的內(nèi)建OCALL，但SGX LibOS需要對大量使用的內(nèi)建OCALL的返回值進(jìn)行檢查。

Microsoft Open Enclave SDK oe_get_report_v2()中兩次調(diào)用_oe_get_report_internal()（內(nèi)含_get_quote() OCALL），第一次獲取Quote所需內(nèi)存大小用于分配Enclave內(nèi)存，第二次將Quote寫入Enclave堆。但第二次OCALL被攻擊者返回過大的Size會導(dǎo)致讀/寫越界。

oe_result_t oe_get_report_v2(...) {...result = _oe_get_report_internal(flags,report_data,report_data_size,opt_params,opt_params_size,NULL, // Use NULL to only get Quote Size&tmp_buffer_size);// This func will call OCALL "_get_quote()"...tmp_buffer = oe_calloc(1, tmp_buffer_size);...result = _oe_get_report_internal(flags,report_data,report_data_size,opt_params,opt_params_size,tmp_buffer,&tmp_buffer_size);...return OE_OK; }

LibOS-based runtimes
$\to$ Grphene-SGX中readdir()等系統(tǒng)調(diào)用可以返回惡意的長度值，將Enclave外內(nèi)容以任意長度寫進(jìn)Enclave內(nèi)。
$\to$ SGX-LKL中，未檢查mmap()系統(tǒng)調(diào)用返回值完全落在Enclave外，未檢查write()系統(tǒng)調(diào)用返回的不可信長度值。后者能導(dǎo)致Enclave內(nèi)存被越界地拷貝到Enclave外。
$\to$ Google Asylo存在未檢查write syscall返回長度。

Keystone，能利用write()系統(tǒng)調(diào)用構(gòu)建Iago，類似于SGX-LKL POC。

攻擊向量10：Uninitialized Padding

除了關(guān)注Pointer和Size參數(shù)，結(jié)構(gòu)體中的（編譯器自動添加的）未初始化填充部分也可能泄漏信息。

對此可能的措施是使用memset安全初始化output，或聲明結(jié)構(gòu)體packed避免編譯器引入Padding，但這兩者需要先驗知識。

SDK-based runtimes Intel SGX-SDK/OE/Sancus/Keystone均存在Padding Leakage。

LibOS-based runtimes Rust-EDP無此問題；Graphene-SGX使用#pragma packing指針，無此問題；SGX-LKL有此問題（sigaction和siginfo_t）；Google Asylo較少（struct BridgeSignalHandler）存在此問題。

討論

如何讓對漏洞類型無感的Enclave開發(fā)者正確實施接口驗證解決上述問題是一個挑戰(zhàn)，我們需要更根本的解決方法來緩解這些漏洞。

Code Hardening
在代碼層面進(jìn)行加強(qiáng)。如利用Heap Obfuscation、Address Randomization，針對指針破壞更激進(jìn)地銷毀密碼或檢測指針的惡意企圖。

Hardware-Assisted Solutions
利用處理器提供的細(xì)粒度內(nèi)存保護(hù)（如Tagged Memory、Capability Architecture/Machine），還可以借鑒SMAP等縱深防御機(jī)制來保護(hù)Enclave。

Safe Programming Languages
Rust的Type System能有效地起作用，但不是“銀彈”。運(yùn)行時仍需構(gòu)建預(yù)期的ABI調(diào)用規(guī)范、對不可信指針的正確消毒。此外，出現(xiàn)了EDGER8R的替代品，為Enclave自動生成安全封裝。

結(jié)論

TEE運(yùn)行時的保護(hù)責(zé)任尚未被清晰認(rèn)識，安全問題頻出。在8個TEE運(yùn)行時找到35個接口消毒問題，歸結(jié)為10類漏洞。需要更根本的接口消毒策略。后續(xù)可通過靜態(tài)分析工具和Fuzzing探索攻擊面。

涉及的CVE

current_descriptioncve_idcvss2_scorecwepaperprojectresultreference

Insufficient initialization in Intel? SGX SDK Windows versions 2.4.100.51291 and earlier, and Linux versions 2.6.100.51363 and earlier, may allow an authenticated user to enable information disclosure, escalation of privilege or denial of service via local access.	CVE-2019-14565	4.6 MEDIUM	CWE-665 Improper Initialization	A tale of two worlds: Assessing the vulnerability of enclave shielding runtimes	SGX SDK	信息泄露、提權(quán)或DoS	https://support.f5.com/csp/article/K57201259?utm_source=f5support&utm_medium=RSS ; https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00293.html (Vendor Advisory);
An information disclosure vulnerability exists when affected Open Enclave SDK versions improperly handle objects in memory, aka ‘Open Enclave SDK Information Disclosure Vulnerability’.	CVE-2019-1370	2.1 LOW	CWE-200 Exposure of Sensitive Information to an Unauthorized Actor	A tale of two worlds: Assessing the vulnerability of enclave shielding runtimes	OpenEnclave	信息泄露	https://github.com/openenclave/openenclave/commit/efe75044d215d43c2587ffd79a52074bf838368b (Patch); https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1370 (Patch, Vendor Advisory);
An information disclosure vulnerability exists when affected Open Enclave SDK versions improperly handle objects in memory, aka ‘Open Enclave SDK Information Disclosure Vulnerability’.	CVE-2019-1369	2.1 LOW	CWE-200 Exposure of Sensitive Information to an Unauthorized Actor	A tale of two worlds: Assessing the vulnerability of enclave shielding runtimes	OpenEnclave	信息泄露	https://github.com/openenclave/openenclave/commit/a39476e5de854317a1a74ec3c08257a00c1625d5 (Patch); https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1369 (Patch, Vendor Advisory);
An information disclosure vulnerability exists when affected Open Enclave SDK versions improperly handle objects in memory, aka ‘Open Enclave SDK Information Disclosure Vulnerability’.	CVE-2019-0876	2.1 LOW	NVD-CWE-noinfo Insufficient Information	A tale of two worlds: Assessing the vulnerability of enclave shielding runtimes	OpenEnclave	信息泄露	https://github.com/openenclave/openenclave/commit/d07769bcf73bb8a1b29374be1a50f93bae549f58 (Patch); https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0876 (Patch, Vendor Advisory); http://www.securityfocus.com/bid/107743 (Third Party Advisory, VDB Entry);
Edger8r tool in the Intel SGX SDK before version 2.1.2 (Linux) and 1.9.6 (Windows) may generate code that is susceptible to a side channel potentially allowing a local user to access unauthorized information.	CVE-2018-3626	1.9 LOW	CWE-200 Exposure of Sensitive Information to an Unauthorized Actor	A tale of two worlds: Assessing the vulnerability of enclave shielding runtimes	SGX SDK EDGER8R	側(cè)信道方式信息泄露	http://www.securityfocus.com/bid/103479 (Third Party Advisory, VDB Entry); https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00117&languageid=en-fr (Vendor Advisory);

總結(jié)

以上是生活随笔為你收集整理的《A Tale of Two Worlds (CCS‘19)》笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。