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

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

漏洞概述

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

補丁對比

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

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

很明顯，EtwpNotifyGuid發(fā)生了變化，因此我對該函數(shù)源碼進行了簡單分析，并發(fā)現(xiàn)了一個重大改變：

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

漏洞分析

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

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

在對EtwpNotifyGuid的分析過程中，我們還發(fā)現(xiàn)了下面這些有意思的修復點：

rdi寄存器包含收入緩沖區(qū)的地址，圖表中的數(shù)據(jù)表明地址rdi+0Ch的字節(jié)數(shù)據(jù)決定了是否去創(chuàng)建一個UmReplyObject對象。

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

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

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

這就非常棒了，我們繼續(xù)。

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

查看EtwpQueueNotification，我發(fā)現(xiàn)了引用UmReplyObject的地方：

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

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

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

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

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

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

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

漏洞利用代碼

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