細數ios上的那些安全防護
作者：龍磊、黑雪、蒸米@阿裡巴巴移動安全
随着蘋果對ios系統多年的研發，ios上的安全防護機制也是越來越多，越來越複雜。這對于剛接觸ios安全的研究人員來說非常不友好，往往不知從何入手。是以，為了讓大家能夠更加系統性的了解ios上的安全機制，我們從三個方面着眼：代碼簽名(codesign)、沙盒機制(sandbox) 和利用緩解(exploit mitigation)，對ios的系統安全機制做了一個總結。希望能夠給大家的學習以及研究帶來一定的幫助。注意，以下内容是以最新版的ios 9.3.4做為标準進行講解。
為了保護開發者的版權以及防止盜版應用，蘋果系統擁有非常嚴格的簽名保護機制。想要開發ios程式，必須先注冊開發者賬号，并向蘋果申請相關的證書，否則程式隻能在模拟器上運作，無法在真機上調試，也無法上架app store。除了傳統的簽名機制以外，蘋果還額外增加了team id的安全防護措施，用來增強ios系統的安全性。
傳統的簽名機制即ios系統中使用的數字證書機制。數字證書是一種對數字内容進行校驗的方法，它首先對内容使用摘要算法（例如md5，sha1）生成一段固定長度的hash值(可以了解為原内容的摘要)，然後利用私鑰對這個摘要進行加密，得到原内容的數字簽名。接受方一并接收到原内容和數字簽名，首先用相同的摘要算法生成原内容的摘要，同時用公鑰解密數字簽名，得到摘要2，然後比較摘要1和摘要2，若相同，則驗證原内容有效。我們從蘋果mc（member center）中獲得的數字證書就是被蘋果ca簽過名的合法的證書。而ios裝置在執行app前，首先要先驗證ca的簽名是否合法，然後再通過證書中我們的公鑰來驗證app是否的确是開發者釋出的，且中途沒有對程式進行過篡改。理論上想要破解或者繞過這個簽名機制，需要能夠擷取到蘋果的私鑰，或者能夠找到簽名校驗過程中的漏洞。
ios在運作代碼前，都會對即将運作的代碼進行簽名校驗。簽名的校驗機制是運作在核心裡的。是以想要關閉這個校驗的話，需要對系統進行越獄才行。核心在vm_fault_enter中規定了絕大部分情況下，具有執行位的頁需要進行簽名有效性檢查，如果檢查到該頁簽名無效會為程序設定kill flag。簽名校驗分兩種情況；如果binary是platform binary，系統會直接校驗binary的哈希值是否存在于trustcache中。如果binary是第三方應用程式，會先在核心在檢查執行頁對應hash值，而頁hash對應的簽名由使用者态程序amfid校驗其正确性。
team id 最早在ios 8中被提出，在ios 9中得到了進一步的加強。team id的出現主要是為了阻止攻擊者将自己的動态庫加載到不屬于自己的executable中，常見例子：越獄過程中将動态庫加載到系統程序，獲得沙箱外的任意代碼執行能力；惡意應用通過沙箱逃逸将自己的動态庫加載到别人的app運作環境，盜取賬号密碼等有價值的資訊。是以team id的具體的校驗邏輯就是根據這個原則來設計。除了特殊情況，系統的程序隻能加載系統的動态庫。第三方app根據自己的team id來決定哪些具有相同team id的dylib能被加載。
很多系統都有沙盒機制，但是像ios這麼複雜的卻很少。ios從uid/gid permission，mac和entitlement三個次元實作了整個系統的沙盒機制：
一般情況下，ios會将程序的權限分為root和mobile，一些特殊的子產品（比如基帶）會有自己的使用者組。需要注意的是，所有第三方的app都是運作在mobile權限下的。
ios的mac在trustedbsd mac framework基礎上實作，在核心具體接口、具體位置插入權限hook check（mac_** call），在發生調用時檢查目前程序是否滿足調用的mac police。
而程序的mac police主要是通過sandbox profile。sandbox profile是蘋果為每個系統程序或app預設的，例如：哪些檔案可讀可寫，哪些不能；哪些system call可以調用，哪些不能等等。
對于系統程序，一般情況下蘋果會為不同的系統程序配備不同的sandbox profile，既滿足業務需求，又遵循權限最小化原則。
對于第三方app，則是統一配備名為 container 的sandbox profile，這個profile裡面的内容限制可達數千條。限制非常嚴格，以緻于隻有很少數的syscall能在第三方app内通路。一些安卓中非常普通的調用，例如fork，exec等建立子程序的系統調用，在第三方app内都是無法生效的。我們常說的沙盒逃逸，其實目的就是跳出container的sandbox profile。
entitlement的出現主要是為了上面兩個次元都無法解決的權限檢查問題。
假設有這樣的場景：
程序 a 是 service 、程序 b 是 client，兩者通過ipc通訊。
程序a提供的服務接口分别有：a1 , a2 ，其中隻希望接口a1能被b通路。
因為檢查發生在使用者态，不能直接使用trustedbsd mac framework，同時需要有更簡單的查詢方式，這樣就需要在a2接口的代碼中加入權限校驗。基于entitlement的校驗架構就是在這個需求背景下被提出來的。業務程序隻需要關注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還有很多進階的或者獨有的利用緩解技術：
棧金絲雀保護是已知的放置在緩沖器和控制資料之間的一個随機值。當緩沖器溢出時，最先被破壞通常是金絲雀值。是以當金絲雀的資料的驗證失敗的時候，就表示出現了緩沖區溢出，進而觸發保護機制，并使程式停止運作。
為了增加攻擊者預測目的位址的難度，防止攻擊者直接定位攻擊代碼位置，使用者态程序在每次啟動時的執行檔案基址都是随機生成的。并且，在每次手機重新開機後，核心kernel mach-o的基址也是随機的。
dep是為了防止資料頁執行代碼。通常情況下，預設不從堆和棧執行代碼。dep會檢測從這些位置運作的代碼，并在發現執行情況時引發異常。在mprotect對應的核心實作中，不允許page被同時賦予執行和寫這兩種權限。當page的權限發生變化或一個新的page mmap到記憶體中的時候，vm_fault_enter會檢查這個頁是否有執行位，如果有執行位，會對這個頁做簽名檢查。
在ios中，如果修改一個zone中已釋放的free element，當記憶體管理器再次配置設定記憶體到這個free element的時候會發生随機panic。具體的邏輯是，當element被釋放後，核心會根據重新開機時建立的token生成一些内容填充在element中。這樣一方面使用者态無法得知填充的内容是什麼，另一方面核心在配置設定記憶體的時候可以根據token知道這個element有沒有被修改，如果被修改就産生panic。
ios系統在釋放記憶體塊的過程中，會對記憶體釋放後在free隊列中的順序進行随機化處理，這個安全措施主要是使用攻擊者無法根據堆噴接口調用的時序來預測對應元素在核心的布局。
armv8-a架構定義了四個例外層級，分别為el0到el3，其中數字越大代表特權(privilege)越大:
el0: 無特權模式(unprivileged)
el1: 作業系統核心模式(os kernel mode)
el2: 虛拟機螢幕模式(hypervisor mode)
el3: trustzone monitor mode
kpp就是運作在application process 的 el3中，目的是用來保證：隻讀的頁不可修改、page table 不可修改、執行頁不可修改。
雖然ios有衆多的安全機制和緩解措施，但這并不代表ios系統牢不可破。有時候一些不起眼的小錯誤就可能導緻蝴蝶效應，最終造成整個安全系統的崩盤。通過對最新的ios 9.3.4研究，我們團隊依然找到了ios系統上的一些安全問題，甚至可以導緻整個系統被控制。如下視訊就示範了在最新的ios 9.3.4上擷取系統最高權限并安裝cydia的過程：
更多技術交流和進展，歡迎大家繼續關注阿裡移動安全。
1. hacking from ios 8 to ios 9, poc 2015.
2. armv8 wiki
3. to sign and protect – cops in os x and ios, rsa 2015
4. 漫談ios程式的證書和簽名機制
阿裡聚安全由阿裡巴巴移動安全部出品，面向企業和開發者提供企業安全解決方案，全面覆寫移動安全、資料風控、内容安全、實人認證等次元，并在業界率先提出“以業務為中心的安全”，賦能生态，與行業共享阿裡巴巴集團多年沉澱的專業安全能力。