前沿拓展：

stream.sys

下面應(yīng)該可ut沒有end這個(gè)符plete!\r" % i )
sys.stdout.flush()

體會(huì)一下，將上面的"\r"拿掉試試看，是不是不換行而直接輸出了？明白了么。很長一段時(shí)間內(nèi)python都會(huì)停留在2.x的時(shí)代。

作者：overXsky

預(yù)估稿費(fèi)：200RMB

投稿方式：發(fā)送郵件至linwei##，或登陸網(wǎng)頁版在線投稿

前言

現(xiàn)代圖形驅(qū)動(dòng)程序是十分復(fù)雜的，它提供了大量有希望被利用的攻擊面，可以使用具有訪問GPU權(quán)限的進(jìn)程（比如Chrome的GPU進(jìn)程）進(jìn)行提權(quán)和沙箱逃逸。在這篇文章中，你們將看到如何攻擊NVIDIA內(nèi)核模式的Windows驅(qū)動(dòng)程序，以及在此期間我發(fā)現(xiàn)的一些bug。我的這項(xiàng)研究是Project Zero的一個(gè)20％項(xiàng)目的一部分，在此期間我總共發(fā)現(xiàn)了16個(gè)漏洞。

內(nèi)核WDDM接口

圖形驅(qū)動(dòng)程序的內(nèi)核模式組件被稱為顯示微端口驅(qū)動(dòng)程序。微軟的官方文檔為我們提供了一個(gè)很好的結(jié)構(gòu)圖，小編綜合來說了各個(gè)組件之間的關(guān)系：

在顯示微端口驅(qū)動(dòng)程序 的DriverEntry()函數(shù)中，DRIVER_INITIALIZATION_DATA結(jié)構(gòu)被由廠商實(shí)現(xiàn)的函數(shù)（實(shí)際上與硬件進(jìn)行交互）的回調(diào)進(jìn)行填充，該函數(shù)通過DxgkInitialize()傳遞給dxgkrnl.sys（DirectX的子系統(tǒng)）。這些回調(diào)要么由DirectX內(nèi)核子系統(tǒng)調(diào)用，要么在某些情況下直接從用戶模式代碼調(diào)用。

DxgkDdiEscape

一個(gè)眾所周知的潛在漏洞的入口點(diǎn)是 DxgkDdiEscape 接口。它可以直接在用戶模式下被調(diào)用，并且可以接受任意數(shù)據(jù)，該數(shù)據(jù)以廠商指定的方式（本質(zhì)上是IOCTL）解析和處理。在后文中，我們將使用術(shù)語“逃逸”來表示由DxgkDdiEscape 函數(shù)支持的特定命令。

截止寫作時(shí)，NVIDIA有著數(shù)量驚人的400多個(gè)逃逸，所以這里也是我花費(fèi)了絕大部分時(shí)間的地方（這些逃逸中的絕大多數(shù)是否有必要處在內(nèi)核空間中是一個(gè)問題）：

NVIDIA為每一個(gè)逃逸都單獨(dú)實(shí)現(xiàn)了其私有數(shù)據(jù)（DXGKARG_ESCAPE 結(jié)構(gòu)體中的pPrivateDriverData），格式為“頭部+數(shù)據(jù)”。頭部格式如下：

這些逃逸由32位代碼（上面NvEscapeCodeInfo結(jié)構(gòu)體的第一個(gè)成員）標(biāo)識(shí)，并根據(jù)它們的最高有效字節(jié)進(jìn)行分組（從1到9）。

在處理每個(gè)逃逸代碼之前都會(huì)做一些驗(yàn)證。具體來說，每個(gè) NvEscapeCodeInfo 應(yīng)當(dāng)包含頭部后面的逃逸數(shù)據(jù)的預(yù)期大小。這將根據(jù)NvEscapeHeader中的大小來驗(yàn)證，NvEscapeHeader自身又通過傳遞給 DxgkDdiEscape的PrivateDriverDataSize字段進(jìn)行驗(yàn)證。但是，預(yù)期大小有時(shí)可能為0（通常當(dāng)逃逸數(shù)據(jù)為可變大小時(shí)），這意味著逃逸處理程序負(fù)責(zé)進(jìn)行自身的驗(yàn)證。這將導(dǎo)致一些bug（1，2）。

在逃逸處理程序中發(fā)現(xiàn)的大多數(shù)漏洞（總共13個(gè)）都是些非常基本的bug，例如盲目地向用戶提供的指針進(jìn)行寫入**作，向用戶模式公開未初始化的內(nèi)核內(nèi)存以及不正確的邊界檢查。還有許多我發(fā)現(xiàn)的問題（例如OOB讀取）沒有報(bào)告出去，因?yàn)樗鼈兯坪鯖]有可以利用的地方。

DxgkDdiSubmitBufferVirtual

另一個(gè)有趣的入口點(diǎn)是DxgkDdiSubmitBufferVirtual函數(shù)，它首次在Windows 10和WDDM 2.0中被引入，主要用來支持GPU虛擬內(nèi)存（而舊的 DxgkDdiSubmitBuffer / DxgkDdiRender 函數(shù)已被棄用）。這個(gè)函數(shù)相當(dāng)復(fù)雜，并且還接受來自用戶模式驅(qū)動(dòng)程序提交的每一個(gè)由廠商特定的數(shù)據(jù)。我在這里找到了一個(gè)bug。

其他

還有一些其他WDDM函數(shù)接受廠商特定的數(shù)據(jù)，但快速瀏覽后沒有發(fā)現(xiàn)任何有趣的東西。

暴露的設(shè)備

更多有趣的Bug

我發(fā)現(xiàn)的大多數(shù)bug是通過手動(dòng)逆向和分析得到的，并且使用了一些自定義的IDA腳本。我還寫了一個(gè)模糊工具。最終結(jié)果成功得有點(diǎn)令人驚訝，這也說明了這些bug的簡單性。

雖然大多數(shù)bug相當(dāng)無聊（缺乏驗(yàn)證之類的簡單案例），但也有一些比較有意思。

NvStreamKms

此驅(qū)動(dòng)程序使用 PsSetCreateProcessNotifyRoutineEx 函數(shù)注冊(cè)進(jìn)程創(chuàng)建通知回調(diào)。該回調(diào)檢查系統(tǒng)上創(chuàng)建的新進(jìn)程是否和先前通過發(fā)送IOCTL設(shè)置的映像名稱相匹配。

這個(gè)創(chuàng)建通知的例程包含一個(gè)bug：

（簡化的反編譯輸出）

此例程通過向后搜索反斜杠（”）的方法從PS_CREATE_NOTIFY_INFO的ImageFileName 成員中提取映像名稱，第二使用 wcscpy_s 將其**到堆棧緩沖區(qū)（Dst），但傳遞的長度是計(jì)算出的名稱長度，而不是目標(biāo)緩沖區(qū)的長度。

即使 Dst 是大小固定的緩沖區(qū)，這也不能被視為一個(gè)直接溢出。因?yàn)樗拇笮〈笥?55個(gè)wchar長度，并且對(duì)于大多數(shù)Windows文件系統(tǒng)路徑組件來說其不能超過255個(gè)字符。而因?yàn)镮mageFileName 是規(guī)范化的路徑，所以掃描反斜杠在大多數(shù)情況下也是有效的。

然而，上述規(guī)則可以通過如下方式繞過：對(duì)于一個(gè)符合通用命名規(guī)約（UNC）的路徑，其規(guī)范化后保持以正斜杠（’/’）作為路徑分隔符（感謝James Forshaw向我指出這一點(diǎn)）。這便意味著我們可以得到一個(gè)“aaa / bbb / ccc / …”形式的文件名從而引發(fā)溢出。

例如：

另一個(gè)有趣的關(guān)注點(diǎn)是，跟隨受損副本的wcslwr實(shí)際上并不限制溢出的內(nèi)容（唯一的要求是有效的UTF-16編碼）。因?yàn)橛?jì)算的filename_length不包含null終止符，所以wcscpy_s 會(huì)認(rèn)為目的地太小，第二以在開始處寫入null字節(jié)的方式來清除目的地字符串（發(fā)生在內(nèi)容**到 filename_length 字節(jié)之后，因此溢出仍然發(fā)生）。這意味著 wcslwr是無用的，因?yàn)閷?duì) wcscpy_s的調(diào)用和一部分的代碼從來沒有工作過。

利用這個(gè)漏洞就不那么復(fù)雜了，因?yàn)轵?qū)動(dòng)程序沒有使用堆棧cookie編譯過。在以前的漏洞中附加過一個(gè)本地特權(quán)提升漏洞利用程序，它配置了一個(gè)偽造的WebDAV服務(wù)器來利用漏洞（ROP，從主堆棧到用戶緩沖區(qū)，再次ROP來分配 讀寫執(zhí)行內(nèi)存，用來存放shellcode并跳轉(zhuǎn)進(jìn)去）。

UVMLiteController中錯(cuò)誤的驗(yàn)證

NVIDIA的驅(qū)動(dòng)程序還在 \. UVMLiteController路徑中暴露了一個(gè)可以由任何用戶打開的設(shè)備（包括從沙箱中的Chrome GPU進(jìn)程）。該設(shè)備的IOCTL處理程序直接將結(jié)果寫入Irp->UserBuffer中，作為將要傳遞給 DeviceIoControl 的輸出指針 （微軟的文檔中指出不要這樣做）。IO控制代碼指定使用METHOD_BUFFERED，這意味著在Windows內(nèi)核檢查地址提供的范圍并將其傳遞給驅(qū)動(dòng)器之前，用戶具有寫**作的權(quán)限。

然而，這些處理程序還缺少對(duì)輸出緩沖區(qū)的邊界檢查，這意味著用戶模式上下文可以通過任何任意地址傳遞值為0的長度（可以繞過ProbeForWrite的檢查）， 這樣做的結(jié)果是創(chuàng)造出一個(gè)受限的Write-what-where情景（這里的“what“僅限于一些特定的值：包括32位0xffff，32位0x1f，32位0和8位0）。

在原始問題中附加了簡單的提權(quán)漏洞利用 。

遠(yuǎn)程攻擊途徑？

考慮到已發(fā)現(xiàn)的bug數(shù)量如此之眾，我做了一個(gè)調(diào)查，是否可以在不必第一破壞沙盒進(jìn)程的前提下，完全從遠(yuǎn)程環(huán)境中訪問其中任意一個(gè)bug（例如通過瀏覽器中的WebGL或通過視頻加速）。

幸運(yùn)的是結(jié)果似乎并非如此。但這并不令人驚訝，因?yàn)檫@里的易受攻擊的API是非常底層的，只有經(jīng)過許多層才能訪問得到（對(duì)于Chrome而言，需要經(jīng)歷libANGLE -> Direct3D運(yùn)行時(shí)和用戶模式驅(qū)動(dòng)程序 ->內(nèi)核模式驅(qū)動(dòng)程序），并且通常需要在用戶模式驅(qū)動(dòng)程序中構(gòu)造有效的參數(shù)才能調(diào)用。

NVIDIA的回應(yīng)

發(fā)現(xiàn)的bug的性質(zhì)表明NVIDIA仍有很多工作要做。他們的驅(qū)動(dòng)程序包含的很多可能不必出現(xiàn)在內(nèi)核中的代碼，而發(fā)現(xiàn)的大多數(shù)錯(cuò)誤是非常基本的錯(cuò)誤。事到如今，他們的驅(qū)動(dòng)程序（NvStreamKms.sys）仍然缺乏非?；镜木徑獯胧ǘ褩ookie）。

不過，他們的反應(yīng)倒是快速且積極的。大多數(shù)bug在截止日期之前已經(jīng)修復(fù)好了，并且他們自己內(nèi)部也在做一些尋找bug的工作。他們還表示，他們一直在努力重構(gòu)他們內(nèi)核驅(qū)動(dòng)程序的安全性，但還沒有準(zhǔn)備好分享任何具體的細(xì)節(jié)。

時(shí)間線

補(bǔ)丁間隔

NVIDIA的第一個(gè)補(bǔ)丁，其中包括我報(bào)告的6個(gè)bug的修復(fù)，但是沒有在公告中詳細(xì)說明（發(fā)布說明稱作“安全更新“）。他們?cè)居?jì)劃在補(bǔ)丁發(fā)布后一個(gè)月再公布詳細(xì)信息。我們注意到了這一點(diǎn)并告訴他們這樣做并不恰當(dāng)，因?yàn)楹诳涂梢酝ㄟ^逆向補(bǔ)丁來找到之前的漏洞，而當(dāng)大眾意識(shí)到這些漏洞細(xì)節(jié)的時(shí)候已經(jīng)晚了。

雖然前6個(gè)bug修復(fù)后在30多天內(nèi)都沒有發(fā)布修復(fù)的詳細(xì)信息，但剩余的8個(gè)bug的修復(fù)補(bǔ)丁發(fā)布后5天內(nèi)就發(fā)布了細(xì)節(jié)公告?？瓷先VIDIA也一直在嘗試減少這種差距，但是就最近的公告來看兩者的發(fā)布仍有很大的不一致性。

結(jié)論

鑒于內(nèi)核中的圖形驅(qū)動(dòng)程序所暴露出來的巨大攻擊面，以及第三方廠商的低質(zhì)量代碼，它似乎是挖掘沙箱逃逸和特權(quán)提升漏洞的一個(gè)非常豐富的目標(biāo)。GPU廠商應(yīng)該盡快將其驅(qū)動(dòng)代碼從內(nèi)核中轉(zhuǎn)移出去，從而縮小攻擊面使得這種情況得以限制。

拓展知識(shí)：