前沿拓展：

stream.sys

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

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

作者：overXsky

預估稿費：200RMB

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

前言

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

內核WDDM接口

圖形驅動程序的內核模式組件被稱為顯示微端口驅動程序。微軟的官方文檔為我們提供了一個很好的結構圖，小編綜合來說了各個組件之間的關系：

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

DxgkDdiEscape

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

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

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

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

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

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

DxgkDdiSubmitBufferVirtual

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

其他

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

暴露的設備

更多有趣的Bug

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

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

NvStreamKms

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

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

（簡化的反編譯輸出）

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

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

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

例如：

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

利用這個漏洞就不那么復雜了，因為驅動程序沒有使用堆棧cookie編譯過。在以前的漏洞中附加過一個本地特權提升漏洞利用程序，它配置了一個偽造的WebDAV服務器來利用漏洞（ROP，從主堆棧到用戶緩沖區(qū)，再次ROP來分配 讀寫執(zhí)行內存，用來存放shellcode并跳轉進去）。

UVMLiteController中錯誤的驗證

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

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

在原始問題中附加了簡單的提權漏洞利用 。

遠程攻擊途徑？

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

幸運的是結果似乎并非如此。但這并不令人驚訝，因為這里的易受攻擊的API是非常底層的，只有經(jīng)過許多層才能訪問得到（對于Chrome而言，需要經(jīng)歷libANGLE -> Direct3D運行時和用戶模式驅動程序 ->內核模式驅動程序），并且通常需要在用戶模式驅動程序中構造有效的參數(shù)才能調用。

NVIDIA的回應

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

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

時間線

補丁間隔

NVIDIA的第一個補丁，其中包括我報告的6個bug的修復，但是沒有在公告中詳細說明（發(fā)布說明稱作“安全更新“）。他們原本計劃在補丁發(fā)布后一個月再公布詳細信息。我們注意到了這一點并告訴他們這樣做并不恰當，因為黑客可以通過逆向補丁來找到之前的漏洞，而當大眾意識到這些漏洞細節(jié)的時候已經(jīng)晚了。

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

結論

鑒于內核中的圖形驅動程序所暴露出來的巨大攻擊面，以及第三方廠商的低質量代碼，它似乎是挖掘沙箱逃逸和特權提升漏洞的一個非常豐富的目標。GPU廠商應該盡快將其驅動代碼從內核中轉移出去，從而縮小攻擊面使得這種情況得以限制。

拓展知識：