Windows內核提權漏洞CVE-2020-1034的示例分析

這篇文章主要為大家展示了“Windows內核提權漏洞CVE-2020-1034的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“Windows內核提權漏洞CVE-2020-1034的示例分析”這篇文章吧。

漏洞概述

Windows內核在處理內存中對象的時候，存在一個提權漏洞。攻擊者將能夠利用該漏洞實現提權，并在目標設備上實現代碼執行。為了利用該漏洞，經過了身份認證的本地攻擊者可以在目標主機上運行一個專門設計的應用程序。

補丁對比

受影響的模塊為ntoskrnl.exe，我下載了該模塊的已修復版本和未修復版本，并在Windows 10 1903 x64系統上對其進行了分析比對。

下面給出的是版本18362.1049和18362.1082之間的源碼對比結果：

很明顯，EtwpNotifyGuid發生了變化，因此我對該函數源碼進行了簡單分析，并發現了一個重大改變：

因此，我決定對其進行深入分析。

漏洞分析

首先，我研究了一下EtwpNotifyGuid的網關，也就是NtTraceControl。

調用EtwpNotifyGuid的FunctionCode為0x11，而且在調用之前還需要進行一些條件檢測，具體如下圖所示：

在對EtwpNotifyGuid的分析過程中，我們還發現了下面這些有意思的修復點：

rdi寄存器包含收入緩沖區的地址，圖表中的數據表明地址rdi+0Ch的字節數據決定了是否去創建一個UmReplyObject對象。

接下來，我們看看r12b寄存器的值是從哪里來的：

r12b的初始值為4，但是這里被設置成了1。因此，當byte ptr [rdi+0Ch]的值為1時，rdi+18h的qword會被設置為新創建的UmReplyObject的地址。否則，qword將保持原樣。這將引起非常嚴重的后果，因為輸入數據永遠不可信。

我將rdi+18h的qword設置為了一個任意值，正如我們所料，設備藍屏了：

這就非常棒了，我們繼續。

這里的輸入緩沖區被傳遞給了EtwpSendDataBlock和EtwpQueueNotification：

查看EtwpQueueNotification，我發現了引用UmReplyObject的地方：

這里的bl值為0，如果rbp+0Ch的字節值不為0，那么rbp+18h的qword會被讀取為一個指向對象的指針，然后對象的引用將會增加。

我們知道了漏洞的根源，罪魁禍首就是代碼對rbp+0C字節數據的不一致對比。對比操作是在EtwpNotifyGuid中進行的，代碼會比較值是否為1來判斷是否需要創建一個新的UmReplyObject對象。但在最后一次比較中，將該值與零進行了比較。

第一次比較在C代碼中的形式如下：

if（*（bool*）（rdi+0x0C）==  true）

第二次比較的代碼形式如下：

if (*(bool*)(rbp+0x0C))

如果值不是1或者0的話，任何輸入的值都將被視作對象地址。接下來，ObfReferenceObject將會調用該地址，這也就意味著qword ptr [[InputBuffer + 0x18] - 0x30] ++運算將會被執行，這樣將導致任意地址增加。

漏洞利用代碼

以上是“Windows內核提權漏洞CVE-2020-1034的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！