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

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

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

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

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

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

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

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

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

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

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

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

假設(shè)有這樣的場(chǎng)景：
進(jìn)程 A 是 service 、進(jìn)程 B 是 client，兩者通過(guò)IPC通訊。
進(jìn)程A提供的服務(wù)接口分別有：a1 , a2 ，其中只希望接口a1能被B訪問(wèn)。

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

除了常見(jiàn)的Stack Canaries、 ASLR和DEP等利用緩解技術(shù)之外，iOS還有很多高級(jí)的或者獨(dú)有的利用緩解技術(shù)：

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

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

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

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

iOS系統(tǒng)在釋放內(nèi)存塊的過(guò)程中，會(huì)對(duì)內(nèi)存釋放后在free隊(duì)列中的順序進(jìn)行隨機(jī)化處理，這個(gè)安全措施主要是使用攻擊者無(wú)法根據(jù)堆噴接口調(diào)用的時(shí)序來(lái)預(yù)測(cè)對(duì)應(yīng)元素在內(nèi)核的布局。

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

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

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

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

更多技術(shù)交流和進(jìn)展，歡迎大家繼續(xù)關(guān)注阿里移動(dòng)安全。

Hacking from iOS 8 to iOS 9, POC 2015.

ARMv8 wiki

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

漫談iOS程序的證書(shū)和簽名機(jī)制

作者：龍磊、黑雪、蒸米@阿里巴巴移動(dòng)安全，更多安全類技術(shù)文章，請(qǐng)?jiān)L問(wèn)阿里聚安全博客