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的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！