【ios非越獄手機沙箱漏洞】iOS越獄和沙盒機制的關係翻譯 |Hacking |MacOS沙箱逃逸競賽 |
近日總部位於意大利監控軟件開發公司HackingTeam黑，415GB文件泄露，HackingTeam泄漏數據涉及多個Android 4.4以下版本遠程代碼執行和提權漏洞、多個Java、Word瀏覽器沙箱逃逸漏洞攻擊代碼(exploit)以及MacOS X、iOS、Android、WP8系統軟件代碼，裏面有Flash 0day, Windows字體0day, iOS enterprise backdoor app, Android selinux exploit, WP8 trojan，是，Hacking Team 控系統RCS，能夠感染包括雲平台內所有平台或介質，實現了全平台RSC系統（包括windows phone）。
HackingTeam泄漏文件，我們發現了有IOS進行監控代碼，用户點擊運行，會請求獲取一些數據訪問權限並追蹤用户位置，日曆和聯繫人。這個過程中，手機需要越獄實現。
相關代碼\core-ios-master.zip\core-ios-master\ios-newsstand-app\newsstand-app文件夾下，通覽全部源碼後，我們發現，監控實現，主要是通過目標設備上安裝一個報刊雜誌應，該應用安裝後顯示一個空白應用，沒有圖標。起代碼文件如下所示：
查看一下應用信息文件info.plist，通過該文件知道該應用一個報刊雜誌類(NewsstandApp)應用，並指定了應用顯示風格和圖標，部分信息如下所示：
然後看程序入口模塊Main.m，Main函數直接調用了AppDelegate類模塊啓動應。
AppDelegate模塊主要功能是任務派發以及後台刷新。包括後台獲取訪問權限，刷新獲取用户日曆，聯繫人以及照片任務，鍵盤任務。
同時該模塊調用接口ViewController創建了一個nil類型gMainView，當view需要展示而它是nil時，viewController會調用該方法
該方法中實現了獲取用户信息主要功能，其功能模塊ViewConroller.m，該應用加載後開始獲取日曆，聯繫人，GPS位置信息以及用户照片。啓動代碼如下所示：
將程序編譯，然後在手機上運行。安裝過後，會創建報刊雜誌隱藏應，應用顯示出來，設置應用列表中可以看到，如下圖所示：
點擊該應用後，其所有監控服務會啓動起來，越獄用户是沒有任何提示直接啓動，而非越獄用户需要添加信任，如下圖所示：
越獄方案沙盒會有所不同影響，iOS 越獄代表沙盒（sandbox）移除，但會使其變得『』。 越獄風險：安裝應用並需要 App Store 證書校驗，可以自己選擇安裝路徑，譬如説跟 Apple 預裝應用安裝 /var/stash/Applications/ 下面，那麼它不受沙盒控制。它可以訪問文件多了，限於短信、聯繫人、郵件、設置。
獄後，即使AppStore安裝App（路徑 /var/mobile/Applications/ 下面）能獲得【部分】沙盒外文件訪問權限。
不能：原本一些文件，比如短信資料(/var/mobile/Library/SMS/sms.db)，AppStore安裝App沒有訪問權限。
能：獄後App能獲得應用文件夾(/var/mobile/Aplications/)讀寫權限，可遍歷App裏面用户資料，這會導致安全問題（‘fork’ 沙盒外文件）。AppStore上線App可當前是否越獄來作出動作，Apple審核檢查不到這一點。
iOS 12幾周前發佈了，並帶來了許多安全方面修復和改進。是，這個版本修補了我們Synacktiv發現一個內核漏洞。
此漏洞位於lio_listio系統調用中，競爭條件會觸發。它可以地被於釋放兩次內核對象，從而導致潛在UAF。
這個漏洞本身大約9年前xnu-1228和xnu-1456之間提出，應該可以大多數iOS多核設備上使用，直到iOS 11.4.1（包含內）版本和MacOS10.14版本發佈。內部，我們此漏洞命名LightSpeed，因為我們十分棘手競爭條件下獲勝了（並且作為添加一些關於星球大戰模因藉口），但不要擔心，我們會其作為一種標記。
因為 listio_lio系統調用可以從任何沙箱訪問，並且於漏洞提供了一些基本數據類型，LightSpeed可能會於越獄iOS 11.4.1。但是，這篇博文解釋漏洞並提供觸發內核崩潰代碼。
正如POSIX.1b中所定義，XNU內核為用户空間提供系統調用執行異步I/O(aio)。該標準規定各種功能,從而實現諸如 aio_read()， aio_write()， lio_listio()， aio_error()， aio_return(),…於XNU-517以及大多數結構開頭是/bsd/sys/aio.h中，這些系統調用 bsd/kern/kern_aio.c可以實現。
延伸閱讀…
作為AIO函數家族介紹， aio_read()和 aio_write()是 read() write()系統調用異步版本。這兩個函數期望 structaiocb*描述要執行 I/O請求：
執行 I/O請求，XNU通過該函數 aio_create_queue_entry()，將用户結構轉換 aio_workq_entry。然後內核通過 aio_enqueue_work()將創建對象排入系統aio隊列中。 以下是兩種功能原型：
加入隊列後，預定工作準備 aio workers提取和處理， aio worker是執行函數 aio_work_thread()內核線程。 aio_read()和 aio_write()系統調用可以返回，並且後通過 aio_return(), aio_error()可以請求aio狀態。
介紹完了後，我們來談談 lio_listio()。這個系統調用類似於 aio_read()和 aio_write()，它設計於一個調用中調度AIO整個列表。所以它需要aiocb一個數組以及其他一些參數。
該mode參數指定了系統調用行為，並且以下其中一個：
LIO_WAIT情況下，內核跟蹤整批aio。實際上，後一個I/O處理時，aio worker線程想要喚醒系統調用中等待用户線程。
這裏，我們可以看到， lio_context每個 aio_workq_entry中都標記上了（作為 aio_create_queue_entry()中group_tag參數）。後，aio worker線程檢索此context， lio_context->io_completed並需要時喚醒用户線程。
延伸閱讀…
我們上一節中解釋了aioliocontext用法，但存在一個問題：誰負責釋放context？這取決於mode操作。
當liolistioLIONOWAIT模式時調用，系統調用中線程會等待所有I/O執行完成。所以釋放liocontext是aio worker工作。這是後一個aio處理後，doaio_completion例程中完成：
另一方面，當調用者LIOWAIT模式下等待時，liocontextlio_listio釋放 。以下是系統調用結束時相關部分：
前面代碼有一個小小的漏洞，可以LIONOWAIT模式下觸發。後一部分test (liocontext->ioissued == 0)是沒有I/O調度時，一個釋放context錯誤處理案例。例如，當用户I/O發出請求，但它們有LIONOP作為aiolioopcode（而不是LIOREAD或LIOWRITE）時，這有可能發生。
但是，執行時，先前檢查是錯誤，並且於其他內核線程可能篡改了，因此lio_context無法得到保證。
如果我們有超快aio worker，可以系統調用結束之前執行我們所有I/O，liocontext可能釋放並且使用了。實際上，aio安排上，worker只需要調用者pmlock程序開始工作，並且lio_listio會多個時間釋放它。
因此，如果liocontext釋放並且使用，那麼liocontext->ioissued可能零。這種情況下，liolistio調用freeliocontext()結束，並且釋放另一個內核分配。
總而言，我們需要以下順序才能觸發漏洞：
來説，越獄後，原本一些文件，比如短信資料(/var/mobile/Library/SMS/sms.db)，AppStore安裝App沒有訪問權限。但是，獄後App能獲得應用文件夾(/var/mobile/Aplications/)讀寫權限，説，我能夠遍歷找到你支付寶、招行、QQ、微信App裏面用户資料，這會導致安全問題。
即使AppStore上線App，能當前是否越獄來作出動作，Apple審核檢查不到這一點。