簡介

《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等多個開源項目。

相關工作

相關工作如DarkROP、Guard‘s Dilemma更關注在Enclave內利用傳統內存安全漏洞（的技巧）。

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

Boomerang關注TrustZone平臺下Enclave內使用的指向Enclave外的指針的消毒缺陷。本文關注指向Enclave內的指針的消毒缺陷，與Boomerang正交。

Practical enclave malware with Intel SGX關注Enclave內惡意軟件的危害（$?$攻擊者可依次攻陷遠程服務Enclave $\to$ Enclave’s Host）

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

ABI層攻擊向量

攻擊向量1：Status Flag Registers

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

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

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

攻擊向量2：調用棧

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

SGX-LKL 新生線程可通過signal handler cmd進入Enclave，從未初始化內存中錯誤地恢復上下文。

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

攻擊向量3：Register State

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

該攻擊向量的利用情況：

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

API層攻擊向量

主要關注Sanitization層指針、變長緩沖區的處理。

攻擊向量4：指針

跨越Enclave安全邊界的指針應該恰當地指向預期的共享內存區域。

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

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

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

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

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

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

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

攻擊向量5：String

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

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

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

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

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

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

攻擊向量6：整數溢出

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

Fortanix Rust-EDP 如Listing4所示，is_user_range()驗證UserSafe Type（Rust Type System）時，變長Buffer的end可能出現整數溢出繞過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參數和返回值，它只在進入Enclave時檢查Host棧指針嚴格落在Enclave外，OCALLOC可能讓Host棧溢出進入ELRANGE（Enclave所占用的虛擬地址空間）但未對此檢查，讀寫存放OCALL參數返回值的內存（可能在Enclave內）會導致信息泄漏或內存破壞。

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

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

攻擊向量8：Double Fetch

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

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

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

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

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

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()等系統調用可以返回惡意的長度值，將Enclave外內容以任意長度寫進Enclave內。
$\to$ SGX-LKL中，未檢查mmap()系統調用返回值完全落在Enclave外，未檢查write()系統調用返回的不可信長度值。后者能導致Enclave內存被越界地拷貝到Enclave外。
$\to$ Google Asylo存在未檢查write syscall返回長度。

Keystone，能利用write()系統調用構建Iago，類似于SGX-LKL POC。

攻擊向量10：Uninitialized Padding

除了關注Pointer和Size參數，結構體中的（編譯器自動添加的）未初始化填充部分也可能泄漏信息。

對此可能的措施是使用memset安全初始化output，或聲明結構體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開發者正確實施接口驗證解決上述問題是一個挑戰，我們需要更根本的解決方法來緩解這些漏洞。

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

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

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

結論

TEE運行時的保護責任尚未被清晰認識，安全問題頻出。在8個TEE運行時找到35個接口消毒問題，歸結為10類漏洞。需要更根本的接口消毒策略。后續可通過靜態分析工具和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	信息泄露、提權或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	側信道方式信息泄露	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);

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。