iOS 12完美越獄來了！漫談iOS 12緩解機制
0×00 序
每年iOS系統大版本升級，對於安全研究人員都是一次新的挑戰。在大版本中，除了修補一些未經公開的漏洞外，蘋果還會增加新的緩解機制，大大提高了整個越獄的難度。這不僅要求安全研究人員能夠挖掘出可以獨立提權的漏洞，還要能夠攻破簽名繞過和根目錄讀寫這兩道關卡。在iOS 12中，業界公開的解決方案都已經被蘋果封堵。
0×01 簽名繞過（CodeSign Bypass）
在iOS中有非常嚴格的簽名校驗機制，所有釋出的App均需要通過蘋果頒發的證書進行簽名之後才能上架。由於存在TeamID機制，即第三方動態庫與宿主程序使用同一個證書籤名，縱使通過漏洞利用完成提權後，依然無法執行未簽名的binary，也無法注入程式碼到其他程序，因此需要繞過蘋果的簽名校驗。在iOS11中，業界有兩種公開的解決方案：
(1). 劫持簽名校驗程序amfid（hijack amfid @i41nbeer）
iOS系統中通過AMFI的Mach Message呼叫使用者態程序amfid進行簽名校驗，其中MISValidateSignatureAndCopyInfo函式返回簽名校驗結果和CDHash（Code Dictionary Hash）到核心。
在iOS 10以前，MISValidateSignature可以通過簡單地返回一個布林值完成繞過。iOS 10以後，MISValidateSignature*函式的返回值為字典。Google Project Zero的安全研究人員Ian Beer提出的解決方案是通過劫持amfid的exception handler，並把MISValidateSignatureAndCopyInfo函式指向一個無效地址，從而使得每次進行簽名校驗時amfid都會發生exception，最終回撥到劫持的exception handler。從回撥函式中獲取到binary資訊並正確返回CDHash，通過整個校驗邏輯。如圖1-1所示。
圖1-1 劫持amfid繞過簽名簡易流程圖
在iOS12中，核心增加了CMS（Cryptographic Message Syntax）校驗，而業界常用的自簽名工具ldid以及jtool中CMS都是為空的，導致上述解決方案失效。同時核心增加了CoreTrust模組用於對抗hardcoded證書，因此要偽造簽名並通過蘋果校驗的難度大大提高。
(2). 偽造簽名授信快取（fake trust cache @Xerub）
核心中AMFI使用trust cache快速校驗ad-hoc的binary，它是一個連結串列式的資料結構，並且存放的位置不受限於KPP/AMCC的保護，提權完成之後可以在核心中找到這個結構體，插入自簽名binary的CDHash繞過簽名校驗。
在iOS12中，已經無法從AMFI中找到trust cache chain了，他被存放在核心的const data段中，這意味著無法對他進行修改。系統通過呼叫pmap_lookup_in_static_trust_cache進行校驗。
然而當我們仔細研究AMFI中的簽名校驗邏輯時發現，核心中有2個trust cache chain，校驗時分別對這兩個trust cache進行檢索匹配，只要通過其中一個校驗即可，雖然上述static trust cache chain無法修改，但是另外一個依然可以修改！並且binary通過trust cache的校驗後，無需再進行CMS校驗！蘋果雖然嘗試封堵這種繞過方式，但依然存在漏洞，導致新增加的緩解機制被輕鬆繞過。
0×02 根目錄讀寫（Root Filesystem Read / Write）
在iOS中為了保障手機檔案安全，即使程序擁有Root許可權，依然無法修改Root Filesystem的內容。iOS 11.3對Root Filesystem有過加強，從而令重新掛載Root Filesystem後，修改Root Filesystem會觸發核心panic。在iOS 11.3後根目錄讀寫的解決方案有兩種：
(1). 偽造有效的mnt_data（Xiaolong Bai and Min (Spark) Zheng @ Alibaba Security Lab）
在iOS 11.3中，即使把RDONLY的標誌去掉使Root Filesystem能被掛載為可讀寫，但由於掛載的是一個只讀的snapshot，並且snapshot中的mnt_data 不包含有效的extent結構，因此修改Root Filesystem會觸發核心panic。那解決的方案自然是將snapshot remount的mnt_data替換為一個有效的mnt_data。蘋果在iOS 12的APFS中進一步加強了對mnt_data合法性的校驗，用上述方法直接替換會觸發核心OOM Panic。
(2). 刪除/dev/disk0s1s1 snapshot （cererdlong and eakerqiu @ Alibaba Pandora Lab）
對於snapshot的另一種解決方案是直接刪除。通過刪除/dev/disk0s1s1的snapshot，使得reboot時系統無法載入對應的snapshot，最終被迫系統使用真實的/dev/disk0s1s1進行mount。
雖然蘋果在核心有對fs_snapshot_delete進行校驗，無法將正在使用的snapshot直接刪除，但卻沒有對fs_snapshot_rename進行校驗。因此可以對正在使用的snapshot改名！通過這個漏洞將snapshot改名後，reboot時系統找不到原本註冊的snapshot，被迫使用真實的/dev/disk0s1s1進行mount。重啟完成後，不僅可以直接將改名的snapshot刪除，而且可以通過簡單修改mount的mnt_flag直接mount update根目錄為可讀寫。
蘋果在iOS 12的APFS對這個漏洞也進行修補，使得正在使用的snapshot無法被rename。儘管如此，依然有新的思路和方法可以掛載根目錄為可讀寫。
0×03 結論
蘋果在iOS 12中修復了很多未公開的漏洞，增加了新的緩解機制，但在iOS 12正式版釋出的數小時內，潘多拉實驗室完成了iOS 12的完美越獄，如圖3-1和3-2所示。從技術的角度來看，完美越獄和非完美越獄的主要區別在於重啟過程中是否能自動執行越獄程式碼，在手機重啟完成前完成越獄。
