0x01 可信執(zhí)行環(huán)境（TEE）

可信執(zhí)行環(huán)境是為了在 執(zhí)行對敏感任務 （例如：付款、用戶身份驗證、用戶數(shù)據(jù)保護）時提供安全的環(huán)境。 安全環(huán)境與名為富執(zhí)行環(huán)境（REE，Rich Execution Environment）的非安全或不受信任的環(huán)境相互隔離。在我們所分析的案例中，也就是Android OS，在后續(xù)文章中REE可以等價為Android。

TEE操作系統(tǒng)通常由具有較高特權的內核和具有較低特權的多個應用程序（稱為可信應用程序，TA，Trusted Applications）組成。

TA之間彼此隔離，且與TEE內核隔離 。

這樣一來，如果有應用程序被攻陷，它就無法危害到其他應用程序或TEE內核。

簡而言之，一個強大的TEE機制可以實現(xiàn)下述三類隔離：

• 1、TEE與REE之間的隔離；
• 2、TA和TEE內核之間的隔離；
• 3、TA之間的隔離。 為了達到這些安全需求，TEE需要硬件原語的支持，以強制進行隔離。硬件和軟件之間的配合是至關重要的，并且需要持續(xù)配合。

廣義上來說，TEE由多個組件組成，具體包括：

• 1、TEE感知硬件；
• 2、強大的安全啟動（Secure Boot）鏈，用于初始化TEE軟件；
• 3、TEE OS內核，用于管理安全區(qū)域和可信應用程序；
• 4、可信應用程序，用于向TEE提供功能。

在我們的系列文章中，將聚焦在1、3和4上面， 并且我們假設平臺已經正確實施了安全啟動 。我們假設 攻擊者已經控制REE ，從而可以與TEE進行通信，其攻擊目標是完整攻陷TEE。

TEE內核通常僅向Android OS暴露非常有限的接口，大多數(shù)功能都是由TA實現(xiàn)的。

所以我們的計劃是首先在TA中找到可以利用的漏洞，然后提升權限到內核。但是，在進入到反匯編程序之前，我們首先要看一下用于實現(xiàn)TEE的ARM擴展——TrustZone。

0x02 ARM的TrustZone

rustZone技術是ARM開發(fā)的一種硬件體系結構，它允許軟件在安全與非安全的兩個域中執(zhí)行。

這是使用“NS”位來進行標識的，這一位可以指示master是在安全模式下還是非安全模式下運行。這里所說的master可以是CPU內核，也可以是硬件外設（例如DMA或加密引擎）。

master是否安全，可以在設計中通過硬連線來定義，也可以通過配置定義。例如，可以通過調用SMC指令（稍后詳細介紹）或切換SCR寄存器中的NS位來切換CPU內核的安全狀態(tài)。

為了定義slave（例如外圍設備或內存）的訪問限制，TrustZone通常包括兩個組件，分別是TrustZone地址空間控制器（TZASC）和TrustZone保護控制器（TZPC）。

TZASC可以用于定義DRAM中的安全范圍。ARM提供了兩種不同的實現(xiàn)方式，最新的是TZC-400。下圖概述了其通常情況下在SoC中的實現(xiàn)方式，引自官方技術文檔。

TZASC概述：

可以看出，任何對DRAM存儲器的訪問都會首先通過TZASC，然后轉發(fā)給內存控制器。TZASC可以基于一組內部規(guī)則來判斷是否允許訪問內存。

TZASC包 含一個始終啟用的基礎區(qū)域（區(qū)域0），能夠跨越整個DRAM內存范圍 。此外，還定義了許多其他安全區(qū)域，可以限制對其的訪問。詳細來說，在其他區(qū)域可以設置以下內容：

• 1、起始地址和結束地址。
• 2、安全讀取和寫入的權限。這些權限將應用在嘗試訪問內存范圍的任何安全master上。請注意，TZASC沒有委派給MMU的執(zhí)行許可和強制執(zhí)行的概念。
• 3、非安全ID過濾。可以將區(qū)域配置為允許訪問非安全的master。對于TZC-400來說，可以為讀取和寫入權限來設置位掩碼，以便對允許哪些非安全master訪問內存范圍進行精細化控制。

TZPC實現(xiàn)了類似的概念，但適用于內部外圍設備和SRAM，不適用于外部DRAM 。其中包含一個寄存器（R0size），以4KB為單位指定安全分片上SPAM的大小。 與TZASC相比，它不太靈活，因為它只允許定義一個安全區(qū)域和一個非安全區(qū)域，安全區(qū)域是從0開始直到指定的大小，剩余的SRAM直接被視為非安全區(qū)域。 然后，還有很多其他的寄存器，用于為每個外圍設備指定其安全性（只能由安全的master訪問）。TZPC寄存器中的不同位對應哪些外設并沒有定義，并且它是完全針對不同的SoC。

通常，TZASC和TZPC的大多數(shù)設置都是在初始化期間配置的，并且永遠不會更改 。但是，其中有一些需要在運行時動態(tài)修改。

這里的一個示例是用于執(zhí)行安全付款的可信用戶界面（TUI）。以S10手機的三星支付為例，當用戶需要輸入PIN來授權付款時，TEE將會接管，并直接控制顯示屏和觸摸傳感器。這里的底層邏輯是，由于PIN是一個敏感數(shù)據(jù)，因此交由TEE來處理整個過程，而不再使用不受信任的Android OS。 因此，必須使用TZPC將顯示器和觸摸控制器重新配置為“安全”，這樣一來，即使是在Android中運行內核級代碼的攻擊者也無法獲取到PIN。要在屏幕中顯示圖像，需要在DRAM中存儲一個安全的幀緩沖區(qū)，因此TEE還會使用TZASC將DRAM中的一部分重新配置為“安全”，并將其作為幀緩沖區(qū)。

在用戶輸入完PIN后，TZASC和TZPC將其恢復為之前的值，然后Android再次接管。

安全和非安全模式之間的轉換由名為“安全監(jiān)視器”（Secure Monitor）的組件來管理。這個監(jiān)視器是TEE和REE之間的主要接口，并且是唯一可以修改內核安全狀態(tài)的組件。

與在REE中一樣，TEE在內核和TA之間保持用戶模式與內核模式之間的隔離 。TEE OS還負責加載TA，并在REE和TA之間傳遞參數(shù)。

TA在安全區(qū)域的用戶空間中運行，并為REE提供服務。

ARMv8-A CPU在每個區(qū)域中支持四個特權級別，也將其稱為異常級別，分別是：

• (S-)EL0 – 用戶模式/APP
• (S-)EL1 – 內核
• EL2 – 管理程序（Hypervisor）
• EL3 – 安全監(jiān)視器（Secure Monitor）

在REE中，我們的Android應用程序在EL0上運行，而Linux內核則在EL1上運行。

EL2僅以非安全模式存在（在ARMv8.4-A版本之前），稱之為管理程序（Hypervisor）。它最初被設計為一種處理以較低特權級別并行運行的多個虛擬環(huán)境的方法， 但是在Android環(huán)境中，通常將其用作內核加固機制。 在三星手機中也是如此， 管理程序組件被稱為實時內核保護（RKP，Real-time Kernel Protection），除了這些用途之外 ，它還限制了內核可以訪問的內存，并將某些內核結構設置為只讀，從而增加了內核漏洞利用的難度。在系列文章的第三篇中，我們將詳細分析RKP。

最后，我們來分析安全組件，我們研究的目標是EL3（始終以安全模式運行）、S-EL0和S-EL1。關于TEE的實現(xiàn)方式，有多種方式，但是目前最常見的示例是：在EL3上運行一個非常小的組件，負責在兩個區(qū)域之間進行切換；在EL1上運行一個成熟的內核；在EL0上運行多個TA。三星的TEE OS TEEGRIS也采用了這樣的設計方式。

盡管完全隔離的環(huán)境非常安全，但在使用的過程中，它還是需要與Android中運行的其他不受信任的組件進行通信。REE和TEE之間的通信使用名為“安全監(jiān)視器調用”（SMC）的專用指令觸發(fā)。兩個指令都可以在EL > 0時調用該指令，這意味著Android應用程序無法直接啟動與TEE的通信。

通常的情況是Linux內核充當代理并公開驅動程序，應用程序可以使用該驅動程序與TEE進行交互。

這種設計的優(yōu)勢在于，可以將訪問限制策略（例如使用SELinux）應用于訪問驅動程序的場景中，以確保只有部分應用程序可以與TEE通信 ，從而收斂了攻擊面。對于S10手機來說，情況也是如此，僅允許有限的應用程序和服務與TEE通信。

請注意， 在我們的后續(xù)研究中，我們假設攻擊者具有與TEE進行通信的能力。在使用Magisk這樣的工具對手機進行root時就是這種情況 ，或者，也可以獲取Linux內核的運行時控制，還可以獲取允許與TEE通信的Android應用/服務的運行時控制。

一旦執(zhí)行了SMC指令，就會在EL3中運行的安全監(jiān)視器中生成一個中斷。SMC處理機制會將SMC路由到相應組件。如果監(jiān)視器可以直接處理SMC，那么就進行處理并立即返回。否則，會將請求轉發(fā)到TEE內核（在S-EL1運行），然后在其內部進行處理，或者繼續(xù)將其轉發(fā)到在S-EL0運行的TA。

現(xiàn)在，我們已經了解TrustZone的工作原理，接下來來分析一下三星的實現(xiàn)方式。

0x03 TEEGRIS

TEEGRIS是一個相對較新的TEE操作系統(tǒng)，由三星在Galaxy S10機型上首次推出。從2019年開始，大多數(shù)使用Exynos芯片的三星新款手機也開始在TEE中運行TEEGRIS。

在2019年3月推出S10之前，Exynos芯片使用的是另一個由Trustonic開發(fā)的、名為Kinibi的TEE OS，此前的一些研究文章對這個操作系統(tǒng)進行了充分分析。不過，由于TEEGRIS是一個相對較新的操作系統(tǒng)，因此網上沒有太多的公開信息。

實際上，我們只能從一篇網上的文章中找到一些可用信息，這篇文章對TEEGRIS及其內核進行了很好地介紹，主要說明了如何設置QEMU以進行fuzzing。盡管我們主要聚焦在逆向工程的方向，但這篇文章仍然為我們提供了一些有用的信息，例如引導映像布局（存儲TEEGRIS的位置），以及如何識別內核中處理的系統(tǒng)調用等。

基于這些信息，我們來分析一下TEEGRIS的主要組件：內核、TA、驅動程序。

如前所述，監(jiān)視器代碼在TrustZone中扮演著非常重要的角色，但是在三星的實現(xiàn)中，監(jiān)視器以加密的方式存儲在內存中。

因此，我們沒有對它進行分析，而是專注于其他組件，這些組件都是以明文存儲的。

0x04 TEEGRIS內核

TEEGRIS內核是一個在安全EL1中運行的小型組件。即使小，但它從嚴格意義上說并不是微內核。舉例來說，其中集成了很多可以由TA使用的驅動程序。它以64位模式運行，并支持在用戶空間中運行的64位和32位TA和驅動程序。由于內核以明文存儲在引導分區(qū)中，因此我們可以輕松提取它并進行反匯編。

內核實現(xiàn)了許多POSIX兼容的系統(tǒng)調用，還添加了一些TEEGRIS特定的系統(tǒng)調用。在Alexander Tarasikov的文章中我們注意到，有兩個共享庫中實現(xiàn)的系統(tǒng)調用包裝器（請參考下面的TA章節(jié)，詳細介紹了如何處理共享庫），分別是libtzsl.so和libteesl.so。這讓我們可以快速地識別內核中的兩個表，分別適用于64位和32位TA的系統(tǒng)調用處理程序。

64位和32位系統(tǒng)調用表：

通過對系統(tǒng)調用進行分析，我們發(fā)現(xiàn)三星充分利用了兩個在Linux中比較熟悉的例程——copy_to和from_user。使用這些例程來訪問來自用戶區(qū)域的數(shù)據(jù)，以確保TA不能引用內部內核結構。

copy_from_user反編譯的代碼：

上圖中的代碼首先驗證標志位，以判斷是否忽略其他任何檢查。當內核使用已知的安全參數(shù)直接調用系統(tǒng)調用處理程序時，就會啟用這個標志位。如果設置了標志位，這個函數(shù)就變成了memcpy的包裝。而在其它情況下，代碼將調用check_address，如下圖所示。

地址檢查例程：

上圖中的代碼片段為我們提供了一些重要的信息，一定不能映射TA的第一頁（第10行，可能是為了防止NULL指針解引用），有效的TA地址應該小于0x40000000（第12行）。任何比它大的值都將被視為無效，并且會被丟棄。

此外需要注意的一點是，復制是使用LDTR指令執(zhí)行的。LDTR的行為與常規(guī)LDR * 指令相同，但會導致使用EL0特權執(zhí)行內存訪問。

這是因為PAN被啟用，即使check_address函數(shù)漏掉了某些邊界情況，對內核內存的非特權訪問也會導致訪問沖突。

TA地址空間的上限0x40000000可能意味著ASLR的隨機性相對較小，特別是考慮到支持64位TA的情況。

為了確認這個假設是否成立，我們分析了如何加載TA映像的過程。

請注意，在TEEGRIS中，TA是經過略微修改后的ELF文件，因此我們可以在代碼中查找用于解析標準ELF格式的函數(shù)。

最終，我們找到了map_elf32_image函數(shù)，在64位TA中也存在等價的函數(shù)。

代碼和數(shù)據(jù)段的隨機化：

需要注意的是，該代碼強制只能加載PIE可執(zhí)行文件（第120行）。隨后，它生成2個字節(jié)的隨機數(shù)（第132行），用0x7FFF作為掩碼（第134行），并將其作為要添加到入口點的頁面偏移量（和基址，稍后會在同一函數(shù)中完成）。這意味著ASLR偏移最多只能有32768個值，并且它應用于ELF中指定的所有段。

動態(tài)內存（例如：用于堆和REE共享的映射內存）在“派生”系統(tǒng)調用時會使用不同的值，但還是采用類似的方法進行隨機化。

動態(tài)內存隨機化：

請注意，ASLR不僅適用于TA，并且也會在內核中使用（通常稱為KASLR）。在這里我們不會過多介紹細節(jié)，但是，如果我們最終想要實現(xiàn)內核利用，則需牢記這一點。在入口函數(shù)中，內核生成另一個隨機值，并相應地修改頁和重定位表。

KASLR，全稱Kernel Address Space Layout Randomization，是一種計算機安全技術。它是一種隨機化內核地址空間布局的方法，旨在防止攻擊者通過猜測內核的地址空間布局來攻擊系統(tǒng)。KASLR技術通過在內核啟動階段獲取一個隨機值，并使用該隨機值對內核加載地址進行相應的隨機偏移，以實現(xiàn)內核地址空間的隨機化。這樣，每次啟動系統(tǒng)時，內核的地址空間布局都會有所不同，使得攻擊者難以猜測正確的內核地址空間布局。在完成內核數(shù)據(jù)隨機映射之后，還需要對符號地址進行重定位，校正內核代碼的符號尋址，以確保內核代碼的正常執(zhí)行。總之，KASLR是一種提高系統(tǒng)安全性的技術，通過隨機化內核地址空間布局，防止攻擊者猜測內核的地址空間布局并攻擊系統(tǒng)。

如前所述，在內核中內置了許多驅動程序。驅動程序主要用于和外圍設備（例如SPI和I2C）進行通信或執(zhí)行加密操作。

內核中實現(xiàn)的驅動程序的部分列表：

考慮到三星是遵循POSIX規(guī)范來實現(xiàn)TEEGRIS的，那么這種與驅動程序進行交互的方式就不足為奇了。

驅動程序的名稱通常以“dev://”開頭，可以從TA打開相應的文件進行訪問。

隨后，TA就可以使用許多系統(tǒng)調用（例如：read、write、ioctl、mmap）與驅動程序進行交互。在內核內部，使用一種結構來存儲每個驅動程序的系統(tǒng)調用實現(xiàn)。

在這里，并不是一直向每個TA授予堆驅動程序和系統(tǒng)調用的訪問權限。實際上，根據(jù)TA所屬不同的組，每個組都有不同的權限級別。

內核會跟蹤向每個TA授予了哪些權限，并執(zhí)行檢查，以確保只有允許的TA才能訪問受限制的功能。下面的兩張圖就展示了授予兩個不同組的權限，分別是samsung_ta和samsung_drv。

samsung_ta組的訪問權限：

samsung_drv組的訪問權限：

如圖所示，每個TA有19個權限。其中值為0就表示未授予權限，其他值表示授予了部分或完整權限。

其中大多數(shù)只是標記已授予和未授予，但有幾個（MMAP）還包含一個特定的掩碼用以確定是否可以使用讀/寫/執(zhí)行特權來映射內存。

在上面的兩個示例中，samsung_ta受到了較多限制，只能訪問幾個權限，但samsung_drv組就具有更大的權限。除此之外，其他組也具有不同的權限，但到目前為止，我們發(fā)現(xiàn)上述兩個是最為常見的。

0x05 TA和用戶區(qū)域驅動程序

至此，我們對內核工作原理以及與內核的交互方式進行了分析，接下來看看TA。通常，在TEE中使用TA的方式有兩種。

• 一種是與TEE OS綁定的不可變的blob，始終在初始化時加載；
• 另一種是可以在運行時由Android加載。

三星的TEEGRIS采用了混合的方式，同時支持這兩種選擇。 引導分區(qū)中包含一個特殊的壓縮包（startup.tzar），其中包含TA所需的所有共享庫以及在Android完全引導之前早期系統(tǒng)所需的一些特殊TA和驅動程序，包括TSS（用于管理共享內存）、ACSD（用于支持TA身份驗證的驅動程序）和root_task（用于加載TA，與ACSD共同對其進行驗證）。

tzar壓縮包中的二進制文件是標準的ELF文件，可以直接加載到反匯編程序中進行分析。

由于壓縮包是啟用映像的一部分，因此在啟動時會驗證它的簽名。

TA也可以在運行時從Android加載。可加載的TA存儲在/vendor/tee和/system/tee分區(qū)中。

在S10系列中，大約有30種不同的TA可供加載，其格式如下：

• 1、標頭長度為8個字節(jié)，包含4個字節(jié)的版本信息（SEC2、SEC3或SEC4）和4個字節(jié)的內容。
• 2、內容部分是包含實際TA內容的常規(guī)ELF文件。如果TA的類型為SEC4，則內容是加密的，否則內容以明文形式存在。
• 3、元數(shù)據(jù)部分包含TA組。從SEC3版本開始，還有一個包含版本號的附加字段。root_task和ACSD會利用這個版本號來管理TA，防止其回滾。當加載SEC3或SEC4版本的TA時，都會提取版本號，并將其與RPMB存儲中存儲的版本號進行比較。如果低于存儲的版本號，則不能加載TA并報錯。如果高于存儲的版本號，則增加RPMB中的版本號以匹配TA版本，從而不再加載同一TA的較舊副本。這也意味著，從現(xiàn)在開始，SEC2版本的TA將無法使用。這個功能對于防護包含已知漏洞的舊版本TA至關重要，我們將在第二篇文章中對此進行詳細介紹。
• 4、簽名部分包含其余映像的RSA簽名。它遵循X.509格式，并由ACSD進行解析。

從這個簡短的描述中，我們可以看出，如果刪除初始標頭并將其作為ELF文件加載到反匯編程序中，我們就可以輕松地對TA進行反匯編。唯一比較麻煩的就是SEC4格式，因為其中的ELF已加密，但是實際上，我們發(fā)現(xiàn)Galaxy S10和S20中僅使用SEC2和SEC3。然后，TA可以從tzar壓縮包中導入庫。庫也是常規(guī)的ELF文件，實現(xiàn)C庫函數(shù)和Global Platform（GP）API和TEEGRIS特定功能。

EEGRIS中的TA實現(xiàn)了GP API， 在這個API中指定了TA需要實現(xiàn)以與REE交互的5個接口：

• 1、TA_CreateEntryPoint，在加載TA時調用。
• 2、TA_OpenSessionEntryPoint，在REE中運行的客戶端應用程序（CA，在我們的場景中為Android應用程序）首次建立與TA的連接時調用。
• 3、TA_InvokeCommandEntryPoint，其中包含將被CA發(fā)送的每個命令調用的主命令處理程序。這是大多數(shù)TA功能實現(xiàn)的位置。
• 4、TA_CloseSessionEntryPoint，在CA結束與TA的會話時調用。
• 5、TA_DestroyEntryPoint，在從內存中卸載TA時執(zhí)行。

即使TA是可執(zhí)行文件，由于實際的main()函數(shù)位于libteesl.so庫內部，因此它的執(zhí)行也比較復雜。啟動TA時，實際上會發(fā)生以下情況：

• 1、執(zhí)行TA內部的start()函數(shù)。這個函數(shù)通常情況下只是main()的包裝。

start()函數(shù)的示例：

• 2、主要函數(shù)實際上不在TA內部，而是在libteesl.so庫中。這里是配置TEEGRIS內核與REE通信的大多數(shù)邏輯的地方。 建立了一個基于POSIX epoll的標準機制，用于與根TA進行通信。在下面的代碼段中，主函數(shù)首先調用TA_CreateEntryPoint()，然后跳轉到start_event_loop()。

libteesl主要函數(shù)的代碼片段：

• 3、在start_event_loop()中，該庫隨后將接收事件，例如來自CA的請求。隨后將時間轉發(fā)到對應的GP API入口點。

這一章的標題是“TA和用戶區(qū)域驅動程序”，但到目前為止我們說得都是TA。那么，驅動程序在哪里呢？

實際上，驅動程序與TA相同。它們具有相同的格式，實現(xiàn)相同的GP API，但調用的是TEEGRIS特定的API，名為TEES_InitDriver。

該函數(shù)允許驅動程序指定驅動程序名稱和結構，可用于與用戶區(qū)域驅動程序進行交互，方式類似于與內核區(qū)域驅動程序進行交互的方式。默認情況下，用戶區(qū)域驅動程序不具有任何特殊權限，但它們通常屬于特權較高的組。

0x06 漏洞利用緩解措施

總結一下我們對內核和TA的分析，就可以明確在內核和TA中實現(xiàn)的漏洞利用緩解措施。其中的一些已經在前面的內核分析中介紹過了。在這里，我們匯總措施如下：

• 1、內核和TA中都使用了XN（eXecute Never）。這意味著數(shù)據(jù)內存永遠不可執(zhí)行，代碼永遠不可寫。
• 2、內核和TA中使用了棧金絲雀保護（Stack Canaries），以防止棧緩沖區(qū)溢出。
• 3、ASLR和KASLR用于隨機化TA和內核的地址空間。
• 4、使用PAN和PXN可以防止內核訪問或執(zhí)行用戶模式內存。

從歷史上看，與其他流行的OS相比，此前TEE OS中的漏洞利用緩解措施還是比較少的。之前針對三星TEE的攻擊主要針對僅使用XN來防護的舊款機型，所以緩解措施比較少。

S10無疑是朝著正確方向邁出了一步，如果攻擊者再想要完整攻陷TEE，可能需要結合利用多個漏洞。

0x07 與TA通信

現(xiàn)在，我們對TA已經有更多的了解，我們需要了解如何從Android環(huán)境中與TA進行通信。幸運的是，GP標準不僅為TA定義了一組API，而且還為希望與TA進行通信的CA定義了一組API。每一個入口點都有一個可供CA使用的對應調用，例如TEEC_OpenSession可以用于打開會話，TEEC_InvokeCommand可以用于發(fā)送命令等等。

對于TEEGRIS來說，libteecl.so庫實現(xiàn)了GP API，因此與TA進行通信就像使用dlopen/dlsym來解析GP API所需的符號一樣簡單。要打開會話，需要指定目標TA的UUID。然后，庫會在/vendor/tee或/system/tee中查找具有該UUID的TA（UUID是文件名），并將整個TA映像都傳遞給TEE，然后TEE將對其進行身份驗證后加載。所有操作都是對CA透明進行的，因此CA并不知道實際通信是如何發(fā)生的。

前面我們也提到過，并非每個Android應用都被允許與TEE進行通信。這里存在限制，完整的漏洞利用鏈需要攻擊者首先獲得對可以與TEE通信的應用程序的運行時控制。