作者：耀刺 黑雪 @ 阿裡安全潘多拉實驗室
0x00 序
每年iOS系統大版本更新，對于安全研究人員都是一次新的挑戰。在大版本中，除了修補一些未經公開的漏洞外，蘋果還會增加新的緩解機制，大大提高了整個越獄的難度。這不僅要求安全研究人員能夠挖掘出可以獨立提權的漏洞，還要能夠攻破簽名繞過和根目錄讀寫這兩道關卡。在iOS 12中，業界公開的解決方案都已經被蘋果封堵。
0x01 簽名繞過（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校驗！蘋果雖然嘗試封堵這種繞過方式，但依然存在漏洞，導緻新增加的緩解機制被輕松繞過。
0x02 根目錄讀寫（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。盡管如此，依然有新的思路和方法可以挂載根目錄為可讀寫。
0x03 結論
蘋果在iOS 12中修複了很多未公開的漏洞，增加了新的緩解機制，但在iOS 12正式版釋出的數小時内，潘多拉實驗室完成了iOS 12的完美越獄，如圖3-1和3-2所示。從技術的角度來看，完美越獄和非完美越獄的主要差別在于重新開機過程中是否能自動執行越獄代碼，在手機重新開機完成前完成越獄。
圖3-1&3-2 iOS 12控制核心PC完成越獄并安裝Cydia
附：iOS 12完美越獄視訊示範
0x04 參考文獻- MacOS and *OS Internals http://newosxbook.com
- Mach portal https://bugs.chromium.org/p/project-zero/issues/detail?id=965
- extra_recipe https://github.com/xerub/extra_recipe
- iOS jailbreak internals (1): Remount rootfs after iOS 11.3 https://media.weibo.cn/article?id=2309404245794218721506