議題概要

現(xiàn)代操作系統(tǒng)基本都已經(jīng)在硬件級(jí)別(MMU)支持了用戶態(tài)只讀內(nèi)存，只讀內(nèi)存映射在保證了跨進(jìn)程間通信、用戶態(tài)與內(nèi)核間通信高效性的同時(shí)，也保證了其安全性。直到DirtyCOW漏洞的出現(xiàn)，這種信任邊界被徹底打破。

在iOS中，這樣的可信邊界似乎是安全的，然而隨著蘋果設(shè)備的快速更新和發(fā)展，引入了越來越多的酷炫功能。許多酷炫功能依賴iOS與一些獨(dú)立芯片的共同協(xié)作。其中，DMA(直接內(nèi)存訪問)技術(shù)讓iOS與這些獨(dú)立芯片之間的數(shù)據(jù)通信變得更加高效。

然而，很少有人意識(shí)到，這些新功能的引入，悄然使得建立已久的可信邊界被打破。科恩實(shí)驗(yàn)室經(jīng)過長(zhǎng)時(shí)間的研究，發(fā)現(xiàn)了一些間接暴露給用戶應(yīng)用的DMA接口。雖然DMA的通信機(jī)制設(shè)計(jì)的比較完美，但是在軟件實(shí)現(xiàn)層出現(xiàn)了問題。將一系列的問題串聯(lián)起來后，將會(huì)形成了一個(gè)危害巨大的攻擊鏈，甚至可導(dǎo)致iOS手機(jī)被遠(yuǎn)程越獄。部分技術(shù)曾在去年的MOSEC大會(huì)上進(jìn)行演示，但核心細(xì)節(jié)與技術(shù)從未被公開。該議題將首次對(duì)這些技術(shù)細(xì)節(jié)、漏洞及利用過程進(jìn)行分享，揭示如何串聯(lián)多個(gè)模塊中暴露的“不相關(guān)”問題，最終獲取iOS內(nèi)核最高權(quán)限的新型攻擊模式。

[[239745]]

作者簡(jiǎn)介

陳良，騰訊安全科恩實(shí)驗(yàn)室安全研究專家，專注于瀏覽器高級(jí)利用技術(shù)、Apple系操作系統(tǒng)(macOS/iOS)的漏洞挖掘與利用技術(shù)研究。他曾多次帶領(lǐng)團(tuán)隊(duì)獲得Pwn2Own 、Mobile Pwn2Own的冠軍，并多次實(shí)現(xiàn)針對(duì)iOS系統(tǒng)的越獄。

[[239746]]

議題解析

現(xiàn)代操作系統(tǒng)都會(huì)實(shí)現(xiàn)內(nèi)存保護(hù)機(jī)制，讓攻擊變得更困難。iOS在不同級(jí)別實(shí)現(xiàn)了這樣的內(nèi)存保護(hù)，例如，MMU的TBE屬性實(shí)現(xiàn)NX、PXN、AP等，以及更底層的KPP、AMCC等：

其中，用戶態(tài)只讀內(nèi)存機(jī)制，在iOS上有很多應(yīng)用，比如可執(zhí)行頁只讀、進(jìn)程間只讀以及內(nèi)核到用戶態(tài)內(nèi)存的只讀：

如果一旦這些只讀內(nèi)存的保護(hù)被破壞，那么最初的可信邊界就會(huì)被徹底破壞，在多進(jìn)程通信的模式下，這可以導(dǎo)致沙盒繞過。而對(duì)于內(nèi)核和用戶態(tài)內(nèi)存共享模式下，這可能可以導(dǎo)致內(nèi)核代碼執(zhí)行：

然而突破這樣的限制并不容易，在iOS中，內(nèi)核代碼會(huì)阻止這樣的情況發(fā)生：每個(gè)內(nèi)存頁都有一個(gè)max_prot屬性，如果這個(gè)屬性設(shè)置為不能大于只讀，那么所有設(shè)置成writable的重映射請(qǐng)求都會(huì)被阻止：

隨著手機(jī)新技術(shù)的發(fā)展，DMA技術(shù)也被應(yīng)用于手機(jī)上，DMA是一種讓內(nèi)存可以不通過CPU進(jìn)行處理的技術(shù)，也就是說，所有CPU級(jí)別的內(nèi)存保護(hù)，對(duì)于DMA全部無效。

那么，是不是說，DMA沒有內(nèi)存保護(hù)呢?事實(shí)并非如此，這是因?yàn)閮蓚€(gè)原因：第一，對(duì)于64位手機(jī)設(shè)備，許多手機(jī)的周邊設(shè)備(例如WIFI設(shè)備)還是32位的，這使得有必要進(jìn)行64位和32位地址間轉(zhuǎn)換;第二是因?yàn)镈MA技術(shù)本身需要必要的內(nèi)存保護(hù)。

正因?yàn)槿绱耍琁OMMU的概念被提出了。在iOS設(shè)備中，DART模塊用來實(shí)現(xiàn)這樣的地址轉(zhuǎn)換。

事實(shí)上DMA有兩種：Host-to-device DMA以及device-to-host DMA，前者用于將系統(tǒng)內(nèi)存映射到設(shè)備，而后者用戶將設(shè)備內(nèi)存映射于系統(tǒng)虛擬內(nèi)存。在2017年中，Google Project Zero的研究員Gal Beniamini先將WIFI芯片攻破，然后通過修改Host-to-device DMA的一塊內(nèi)存，由于內(nèi)核充分信任這塊內(nèi)存，忽略了一些必要的邊界檢查，導(dǎo)致成功通過WIFI來攻破整個(gè)iOS系統(tǒng)：

然而Gal的攻擊方式存在一定局限，因?yàn)楸仨氃诙叹嚯x模式下才能完成：攻擊WIFI芯片需要攻擊者和受害者在同一個(gè)WIFI環(huán)境中。

我們有沒有辦法通過DMA的問題實(shí)現(xiàn)遠(yuǎn)距離攻破，這聽上去并不可行，因?yàn)镈MA接口本身并不會(huì)暴露于iOS用戶態(tài)。

然而通過科恩實(shí)驗(yàn)室的研究發(fā)現(xiàn)，可能存在一些間接接口，可以用來做DMA相關(guān)的操作，例如iOS中的JPEG引擎以及IOSurface transform等模塊。我們選擇研究IOSurface transform模塊的工作機(jī)制。以下是IOSurface transform模塊的工作機(jī)制：

IOSurfaceAccelerator接口通過用戶態(tài)提供的兩個(gè)IOSurface地址作為用戶參數(shù)，通過操作Scaler設(shè)備，將IOSurface對(duì)應(yīng)的地址轉(zhuǎn)換成Scaler設(shè)備可見的設(shè)備地址，然后啟動(dòng)scaler設(shè)備進(jìn)行transform，整個(gè)過程如下：

另一方面，在這個(gè)Host-to-device DMA過程中，用戶態(tài)內(nèi)存的只讀屬性是否被考慮在內(nèi)，是一個(gè)比較疑惑的問題。我們經(jīng)過研究，發(fā)現(xiàn)在IOMMU中是支持內(nèi)存屬性的：

在TTE的第8和第9位，是用于執(zhí)行內(nèi)存頁的讀寫屬性的：

因此我們得到這樣的頁表屬性定義：

我們之后介紹了蘋果圖形組件的工作模式：

在iPhone7設(shè)備中，一共有128個(gè)Channel，這些Channel被分成三類：CL、GL和TA，內(nèi)核將來自用戶態(tài)的繪圖指令包裝并塞入這128個(gè)channel，然后等待GPU的處理。由于GPU處理是高并發(fā)的，因此需要很健全的通知機(jī)制。

首先GPU會(huì)映射一個(gè)128個(gè)元素的stampArray給kernel，kernel也會(huì)把這塊內(nèi)存映射到用戶態(tài)。與此同時(shí)，內(nèi)核也維護(hù)了一個(gè)stamp address array，用于保存每個(gè)channel的stamp地址：

值得注意的是，GPU每處理完一個(gè)繪圖指令后，都會(huì)將對(duì)應(yīng)channel的stamp值加1。另一方面，對(duì)于每個(gè)繪圖指令，都會(huì)有一個(gè)期望stamp值，這個(gè)值被封裝于IOAccelEvent對(duì)象中：

系統(tǒng)通過簡(jiǎn)單的比較expectStamp于當(dāng)前channel的stamp值就可以確定這個(gè)繪圖指令是否已經(jīng)完成。為了提高處理效率，部分IOAccelEvent對(duì)象會(huì)被映射到用戶態(tài)，屬性只讀。

在介紹完了所有這些機(jī)制性的問題后，我們來介紹兩個(gè)用于Jailbreak的關(guān)鍵漏洞。漏洞1存在于DMA映射模塊，先前提到，系統(tǒng)的內(nèi)存屬性mapOption會(huì)被傳入底層DART的代碼中，然而在iOS 10以及早期的iOS 11版本中，這個(gè)mapOption參數(shù)被下層的DART轉(zhuǎn)換所忽略：

所有操作系統(tǒng)中的虛擬地址，都會(huì)被映射成IOSpace中允許讀寫的內(nèi)存：

之后我們介紹第二個(gè)漏洞，這個(gè)漏洞存在于蘋果圖形模塊中。在IOAccelResource對(duì)象創(chuàng)建過程中，一個(gè)IOAccelClientShareRO對(duì)象會(huì)被映射到用戶態(tài)作為只讀內(nèi)存，這個(gè)對(duì)象包含4個(gè)IOAccelEvent對(duì)象：

在IOAccelResource對(duì)象銷毀過程中，testEvent函數(shù)會(huì)被執(zhí)行，用于測(cè)試IOAccelResource對(duì)應(yīng)的繪圖指令是否已經(jīng)被GPU處理完成：

在這個(gè)代碼邏輯中，由于內(nèi)核充分信任這塊IOAccelEvent內(nèi)存不會(huì)被用戶態(tài)程序篡改(因?yàn)槭侵蛔x映射)，因此并沒有對(duì)channelIndex做邊界檢查。這雖然在絕大多數(shù)情況下是安全的，但如果我們配合漏洞1，在用戶態(tài)直接修改這塊只讀內(nèi)存，就會(huì)導(dǎo)致可信邊界被徹底破壞，從而造成m_stampAddressArray的越界讀以及m_inlineArray的越界寫：

最后，我們討論兩個(gè)漏洞的利用。要利用這兩個(gè)漏洞并不容易，因?yàn)槲覀冃枰业揭环N內(nèi)存布局方法，讓m_stampAddressArray以及m_inlineArray這兩個(gè)數(shù)組的越界值都可控。但因?yàn)檫@兩個(gè)數(shù)組在系統(tǒng)啟動(dòng)初期就已經(jīng)分配，而且這兩個(gè)數(shù)組的元素大小并不相同，因此布局并不容易。

經(jīng)過研究，我們發(fā)現(xiàn)，只有通過指定大index以及合理的內(nèi)核對(duì)噴，才能實(shí)現(xiàn)這樣的布局。因?yàn)樵趇Phone7設(shè)備中，用戶態(tài)應(yīng)用可以噴射大概350MB的內(nèi)存，并且在m_stampAddressArray以及m_inlineArray初始化后，會(huì)有額外50MB的內(nèi)存消耗，因此我們需要使得index滿足以下兩個(gè)條件：

• index ∗ 24 < 350MB + 50MB
• index ∗ 8 > 50MB

也就是說index的值需要在[0x640000, 0x10AAAAA]這個(gè)范圍內(nèi)，可以使得兩個(gè)數(shù)組的越界值極大概率在我們可控的噴射內(nèi)存內(nèi)：

然后，下一個(gè)問題就是，我們是否能夠任意地址讀以及任意地址寫。對(duì)于任意地址讀似乎不是什么問題，因?yàn)閙_stampAddressArray的元素大小是8字節(jié)，可以通過指定任意index到達(dá)任意內(nèi)存地址。但任意地址寫需要研究，因?yàn)閙_inlineArray的元素大小是24字節(jié)，只有一個(gè)field可以用于越界寫，所以不是每個(gè)內(nèi)存地址都可以被寫到：

在這種情況下，我們退求其次，如果能實(shí)現(xiàn)對(duì)于一個(gè)頁中的任意偏移值進(jìn)行寫操作，那么也可以基本達(dá)到我們的要求。在這里，我們需要通過同余定理來實(shí)現(xiàn)：

因?yàn)椋?/p>

0xc000 ≡ 0(mod0x4000) 

因此對(duì)于任意整數(shù)n，滿足：

n ∗ 0×800 ∗ 24 ≡ 0(mod0x4000)  

由于0×4000 / 24 * 0xF0 / 16 = 0x27f6，我們得到：

0xF0 + 0x27f6 ∗ 24 + n ∗ 0×800 ∗ 24 ≡ 0(mod0x4000)  

最后我們得出結(jié)論，如果需要通過越界m_inlineArray寫到一個(gè)頁的前8字節(jié)，需要滿足:

index = 0x27f6 + n ∗ 0×800  

而如果需要到達(dá)任意頁內(nèi)偏移，假設(shè)要到達(dá)偏移m，則index需要滿足條件：

index = 0x27f6 + 0x2ab ∗ m/8 + n ∗ 0×800  

與之前得出的index范圍結(jié)論相結(jié)合，我們最終選擇了index值0x9e6185:

然后我們通過以下幾個(gè)步驟進(jìn)行漏洞利用，在第一個(gè)布局中，我們得出Slot B與Slot C的index值：

隨之我們將slot B填入相同大小的AGXGLContext對(duì)象，然后再次利用漏洞泄露出其vtable的第四位：

最后我們通過將Slot C釋放并填入AGXGLContext對(duì)象，將其原本0×568偏移的AGXAccelerator對(duì)象改為我們可控的內(nèi)存值，實(shí)現(xiàn)代碼執(zhí)行：

最后，整個(gè)利用流程總結(jié)如下：

[[239747]]

在通過一系列ROP后，我們最終拿到了TFP0，但這離越獄還有一段距離：繞過AMFI，rootfs的讀寫掛載、AMCC/KPP繞過工作都需要做，由于這些繞過技術(shù)都有公開資料可以查詢，我們這里不作詳細(xì)討論：

[[239748]]

最后，我們對(duì)整條攻擊鏈作了總結(jié)：

• 在iOS 11的第一個(gè)版本發(fā)布后，我們的DMA映射漏洞被修復(fù);
• 但是蘋果圖形組件中的越界寫漏洞并沒有被修復(fù);
• 這是一個(gè)”設(shè)計(jì)安全，但實(shí)現(xiàn)并不安全”的典型案例，通過這一系列問題，我們將這些問題串聯(lián)起來實(shí)現(xiàn)了復(fù)雜的攻擊;
• 也許目前即便越界寫漏洞不修復(fù)，我們也無法破壞重新建立起來的只讀內(nèi)存可信邊界;
• 但是至少，我們通過這篇文章，證明了可信邊界是可以被打破的，因?yàn)橛脩魬B(tài)只讀映射是”危險(xiǎn)”的;
• 也許在未來的某一天，另一個(gè)漏洞的發(fā)現(xiàn)又徹底破壞了這樣的可信邊界，配合這個(gè)越界寫漏洞將整個(gè)攻擊鏈再次復(fù)活。這是完全有可能的。

[[239749]]