iOS 10.3.2 沙盒逃逸

信息安全公益宣傳，信息安全知識啟蒙。

微信群；QQ群：16004488

加微信群或QQ群可免費索取：學習教程

教程列表見微信公眾號底部菜單

an Beer@google發布了CVE-2017-7047Triple_Fetch的exp和writeup[1]，chenliang@keenlab也發表了關於Triple_Fetch的分析[2]，但由於這個漏洞和exp有非常多的亮點，所以還剩很多可以深入挖掘的細節。因此，我們簡單分析一下漏洞形成的原因，並具體介紹一下漏洞利用的細節，以及如何利用這個漏洞做到iOS 10.3.2上的沙盒逃逸。

CVE-2017-7047 Triple_Fetch漏洞形成的原因

因為chenliang對漏洞成因的分析非常詳細，這裡我就簡單描述一下，因為使用XPC服務傳輸大塊內存的話很影響效率，蘋果為了減少傳輸時間，對大於0x4000的OS_xpc_data數據會通過mach_vm_map的方式映射這塊內存，然後將這塊數據的send right以port的方式發送到另一方。但這段內存的共享是基於共享物理頁的方式，也就是說發送方和接收方會共享同一塊內存，因此我們將數據發送以後再在發送端對數據進行修改，接收方的數據也會發生變化。

因此通過race condition，可以讓接收端得到不同的數據（接收端認為是相同的數據），如果接收端沒有考慮到這一點的話就可能會出現漏洞。比如我們剛開始讓接收端獲取的字元串是@」ABCD」（包括@和」），那麼接收端會為這個字元串分配7個位元組的空間。隨後在進行字元串拷貝的時候，我們將字元串變為@"ABCDOVERFLOW_OVERFLOW_OVERFLOW"，接收端會一直拷貝到遇到」符號為止，這樣就造成了溢出。

Triple_Fetch攻擊所選擇的函數是CoreFoundation里的___NSMS1函數，這個函數會對我們構造的惡意字元串進行多次讀取操作，如果在讀取的間隙快速對字元串進行三次修改，就會讓函數讀取到不同的字元串，讓函數產生判斷失誤，從而造成溢出並讓我們控制pc，這也是為什麼把這個漏洞稱為Triple_Fetch的原因。下圖就是攻擊所使用的三組不同的字元串：

攻擊所選擇的NSXPC服務是「com.apple.CoreAuthentication.daemon」。對應的二進位文件是/System/Library/Frameworks/LocalAuthentication.framework/Support/coreauthd。原因是這個進程是root許可權並且可以調用processor_set_tasks API從而獲取系統其他進程的send right[3]。下圖是控制了pc后的crash report：

利用漏洞Triple_Fetch雖然可以控制pc，但是還不能控制棧，所以需要先做stack_pivot，好消息是x0寄存器指向的xpc_uuid對象是我們可以控制的：

因此我們可以利用JOP跳轉到_longjmp函數作為來進行stack pivot，從而控制stack：

最終發送的用來做JOP的格式偽造的xpc_uuid對象如下：

控制了stack就可以很容易的寫rop了。但是beer目標不僅僅是執行rop，它還希望獲取目標進程的task port並且執行任意二進位文件，因此除了exp，攻擊端還用mach msg發送了0x1000個帶有send right的port到目標進程中：

這些port的mach msg在內存中的位置和內容如下（msgh_id都為0x12344321）：

隨後，exp採用rop的方法對這些port進行遍歷並且發送回發送端：

隨後，攻擊端會接收mach msg，如果獲取到的msgh_id為0x12344321的消息，說明我們成果得到了目標進程的task port：

得到了task_port后，sploit函數就結束了，開始進入do_post_exploit。do_post_exploit也做了非常多的事情，首先是利用coreauthd的task port以及processor_set_tasks獲取所有進程的task port。這是怎麼做到的呢？

利用coreauthd的task port我們可以利用mach_vm_* API任意的修改coreauthd的內存以及寄存器，所以我們需要先開闢一段內存作為stack，然後將sp指向這段內存，再將pc指向我們想要執行的函數地址就可以讓目標進程執行任意的函數了，具體實現在call_remote中：

下面閱讀原文，有啥 ？