摘要：序隨著蘋果對系統(tǒng)多年的研發(fā)，上的安全防護機制也是越來越多，越來越復雜。代碼簽名為了保護開發(fā)者的版權以及防止盜版應用，蘋果系統(tǒng)擁有非常嚴格的簽名保護機制。除了傳統(tǒng)的簽名機制以外，蘋果還額外增加了的安全防護措施，用來增強系統(tǒng)的安全性。

隨著蘋果對iOS系統(tǒng)多年的研發(fā)，iOS上的安全防護機制也是越來越多，越來越復雜。這對于剛接觸iOS安全的研究人員來說非常不友好，往往不知從何入手。因此，為了讓大家能夠更加系統(tǒng)性的了解iOS上的安全機制，我們從三個方面著眼：代碼簽名(CodeSign)、沙盒機制(SandBox) 和利用緩解(Exploit Mitigation)，對iOS的系統(tǒng)安全機制做了一個總結。希望能夠給大家的學習以及研究帶來一定的幫助。注意，以下內容是以最新版的iOS 9.3.4做為標準進行講解。

為了保護開發(fā)者的版權以及防止盜版應用，蘋果系統(tǒng)擁有非常嚴格的簽名保護機制。想要開發(fā)iOS程序，必須先注冊開發(fā)者賬號，并向蘋果申請相關的證書，否則程序只能在模擬器上運行，無法在真機上調試，也無法上架App Store。除了傳統(tǒng)的簽名機制以外，蘋果還額外增加了Team ID的安全防護措施，用來增強iOS系統(tǒng)的安全性。

傳統(tǒng)的簽名機制即iOS系統(tǒng)中使用的數(shù)字證書機制。數(shù)字證書是一種對數(shù)字內容進行校驗的方法，它首先對內容使用摘要算法（例如MD5，SHA1）生成一段固定長度的hash值(可以理解為原內容的摘要)，然后利用私鑰對這個摘要進行加密，得到原內容的數(shù)字簽名。接受方一并接收到原內容和數(shù)字簽名，首先用相同的摘要算法生成原內容的摘要，同時用公鑰解密數(shù)字簽名，得到摘要2，然后比較摘要1和摘要2，若相同，則驗證原內容有效。我們從蘋果MC（Member Center）中獲得的數(shù)字證書就是被蘋果CA簽過名的合法的證書。而iOS設備在執(zhí)行app前，首先要先驗證CA的簽名是否合法，然后再通過證書中我們的公鑰來驗證app是否的確是開發(fā)者發(fā)布的，且中途沒有對程序進行過篡改。理論上想要破解或者繞過這個簽名機制，需要能夠獲取到蘋果的私鑰，或者能夠找到簽名校驗過程中的漏洞。

iOS在運行代碼前，都會對即將運行的代碼進行簽名校驗。簽名的校驗機制是運行在內核里的。因此想要關閉這個校驗的話，需要對系統(tǒng)進行越獄才行。內核在vm_fault_enter中規(guī)定了絕大部分情況下，具有執(zhí)行位的頁需要進行簽名有效性檢查，如果檢查到該頁簽名無效會為進程設置kill flag。簽名校驗分兩種情況；如果binary是platform binary，系統(tǒng)會直接校驗binary的哈希值是否存在于trustcache中。如果binary是第三方應用程序，會先在內核在檢查執(zhí)行頁對應hash值，而頁hash對應的簽名由用戶態(tài)進程amfid校驗其正確性。

Team ID 最早在iOS 8中被提出，在iOS 9中得到了進一步的加強。Team ID的出現(xiàn)主要是為了阻止攻擊者將自己的動態(tài)庫加載到不屬于自己的executable中，常見例子：越獄過程中將動態(tài)庫加載到系統(tǒng)進程，獲得沙箱外的任意代碼執(zhí)行能力；惡意應用通過沙箱逃逸將自己的動態(tài)庫加載到別人的app運行環(huán)境，盜取賬號密碼等有價值的信息。所以Team ID的具體的校驗邏輯就是根據這個原則來設計。除了特殊情況，系統(tǒng)的進程只能加載系統(tǒng)的動態(tài)庫。第三方app根據自己的Team ID來決定哪些具有相同Team ID的dylib能被加載。

很多系統(tǒng)都有沙盒機制，但是像iOS這么復雜的卻很少。iOS從UID/GID permission，MAC和entitlement三個維度實現(xiàn)了整個系統(tǒng)的沙盒機制：

一般情況下，iOS會將進程的權限分為root和mobile，一些特殊的模塊（比如基帶）會有自己的用戶組。需要注意的是，所有第三方的app都是運行在mobile權限下的。

iOS的MAC在TrustedBSD Mac Framework基礎上實現(xiàn)，在內核具體接口、具體位置插入權限hook check（mac_** call），在發(fā)生調用時檢查當前進程是否滿足調用的MAC police。
而進程的MAC police主要是通過sandbox profile。Sandbox profile是蘋果為每個系統(tǒng)進程或app預設的，例如：哪些文件可讀可寫，哪些不能；哪些system call可以調用，哪些不能等等。

對于系統(tǒng)進程，一般情況下蘋果會為不同的系統(tǒng)進程配備不同的sandbox profile，既滿足業(yè)務需求，又遵循權限最小化原則。

對于第三方app，則是統(tǒng)一配備名為 Container 的sandbox profile，這個profile里面的內容限制可達數(shù)千條。限制非常嚴格，以致于只有很少數(shù)的syscall能在第三方app內訪問。一些安卓中非常普通的調用，例如fork，exec等創(chuàng)建子進程的系統(tǒng)調用，在第三方app內都是無法生效的。我們常說的沙盒逃逸，其實目的就是跳出container的sandbox profile。

Entitlement的出現(xiàn)主要是為了上面兩個維度都無法解決的權限檢查問題。

假設有這樣的場景：
進程 A 是 service 、進程 B 是 client，兩者通過IPC通訊。
進程A提供的服務接口分別有：a1 , a2 ，其中只希望接口a1能被B訪問。

因為檢查發(fā)生在用戶態(tài)，不能直接使用TrustedBSD Mac Framework，同時需要有更簡單的查詢方式，這樣就需要在a2接口的代碼中加入權限校驗?；趀ntitlement的校驗框架就是在這個需求背景下被提出來的。業(yè)務進程只需要關注entitlement的內容，而entitlement的正確性由簽名保證。比如想要訪問提供了能刪除app的接口的”com.apple.mobile.installd”服務就必須擁有對應的”com.apple.private.mobileinstall.allowedSPI” entitlement才行。而lockdownd這個service是用于和iTunes交互來進行安裝、升級、刪除應用的，所以這個服務為了能與installd服務通訊，進行刪除app操作，就需要擁有”com.apple.private.mobileinstall.allowedSPI” 這個entitlement：

除了常見的Stack Canaries、 ASLR和DEP等利用緩解技術之外，iOS還有很多高級的或者獨有的利用緩解技術：

棧金絲雀保護是已知的放置在緩沖器和控制數(shù)據之間的一個隨機值。當緩沖器溢出時，最先被破壞通常是金絲雀值。因此當金絲雀的數(shù)據的驗證失敗的時候，就表示出現(xiàn)了緩沖區(qū)溢出，從而觸發(fā)保護機制，并使程序停止運行。

為了增加攻擊者預測目的地址的難度，防止攻擊者直接定位攻擊代碼位置，用戶態(tài)進程在每次啟動時的執(zhí)行文件基址都是隨機生成的。并且，在每次手機重啟后，內核kernel mach-o的基址也是隨機的。

DEP是為了防止數(shù)據頁執(zhí)行代碼。通常情況下，默認不從堆和棧執(zhí)行代碼。DEP會檢測從這些位置運行的代碼，并在發(fā)現(xiàn)執(zhí)行情況時引發(fā)異常。在mprotect對應的內核實現(xiàn)中，不允許page被同時賦予執(zhí)行和寫這兩種權限。當page的權限發(fā)生變化或一個新的page mmap到內存中的時候，vm_fault_enter會檢查這個頁是否有執(zhí)行位，如果有執(zhí)行位，會對這個頁做簽名檢查。

在iOS中，如果修改一個zone中已釋放的free element，當內存管理器再次分配內存到這個free element的時候會發(fā)生隨機panic。具體的邏輯是，當element被釋放后，內核會根據重啟時創(chuàng)建的token生成一些內容填充在element中。這樣一方面用戶態(tài)無法得知填充的內容是什么，另一方面內核在分配內存的時候可以根據token知道這個element有沒有被修改，如果被修改就產生panic。

iOS系統(tǒng)在釋放內存塊的過程中，會對內存釋放后在free隊列中的順序進行隨機化處理，這個安全措施主要是使用攻擊者無法根據堆噴接口調用的時序來預測對應元素在內核的布局。

ARMv8-A架構定義了四個例外層級，分別為EL0到EL3，其中數(shù)字越大代表特權(privilege)越大:

EL0: 無特權模式(unprivileged)
EL1: 操作系統(tǒng)內核模式(OS kernel mode)
EL2: 虛擬機監(jiān)視器模式(Hypervisor mode)
EL3: TrustZone monitor mode

KPP就是運行在Application Process 的 EL3中，目的是用來保證：只讀的頁不可修改、page table 不可修改、執(zhí)行頁不可修改。

雖然iOS有眾多的安全機制和緩解措施，但這并不代表iOS系統(tǒng)牢不可破。有時候一些不起眼的小錯誤就可能導致蝴蝶效應，最終造成整個安全系統(tǒng)的崩盤。通過對最新的iOS 9.3.4研究，我們團隊依然找到了iOS系統(tǒng)上的一些安全問題，甚至可以導致整個系統(tǒng)被控制。如下視頻就演示了在最新的iOS 9.3.4上獲取系統(tǒng)最高權限并安裝cydia的過程：

更多技術交流和進展，歡迎大家繼續(xù)關注阿里移動安全。

Hacking from iOS 8 to iOS 9, POC 2015.

ARMv8 wiki

To Sign and Protect – COPS in OS X and iOS, RSA 2015

漫談iOS程序的證書和簽名機制

作者：龍磊、黑雪、蒸米@阿里巴巴移動安全，更多安全類技術文章，請訪問阿里聚安全博客