Shulou(Shulou.com)05/31 Report--

This article mainly shows you the "example analysis of Windows kernel lifting vulnerability CVE-2020-1034", which is easy to understand and well-organized. I hope it can help you solve your doubts. Let the editor lead you to study and study the "sample analysis of Windows kernel lifting vulnerability CVE-2020-1034".

Overview of vulnerabilities

There is a rights raising vulnerability in the Windows kernel when dealing with objects in memory. Attackers will be able to exploit this vulnerability to elevate rights and implement code execution on the target device. To exploit this vulnerability, an authenticated local attacker can run a specially designed application on the target host.

Patch comparison

The affected module is ntoskrnl.exe, and I downloaded the repaired and unrepaired versions of the module, and analyzed and compared them on the Windows 10 1903 x64 system.

The following is the source code comparison between versions 18362.1049 and 18362.1082:

Obviously, EtwpNotifyGuid has changed, so I briefly analyzed the source code of the function and found a major change:

Therefore, I decided to analyze it in depth.

Loophole analysis

First of all, I studied the gateway of EtwpNotifyGuid, that is, NtTraceControl.

The FunctionCode for calling EtwpNotifyGuid is 0x11, and some condition tests need to be performed before the call, as shown below:

In the process of analyzing EtwpNotifyGuid, we also found the following interesting repair points:

The rdi register contains the address of the income buffer, and the data in the chart shows that the byte data of the address rdi+0Ch determines whether to create a UmReplyObject object.

Next, let's see where the value of the r12b register comes from:

The initial value of r12b is 4, but here it is set to 1. Therefore, when the value of byte ptr [rdi+0Ch] is 1, the qword of rdi+18h is set to the address of the newly created UmReplyObject. Otherwise, qword will remain as it is. This will have very serious consequences because the input data can never be trusted.

I set the qword of rdi+18h to an arbitrary value, and as we expected, the device blue screen:

This is great. Let's move on.

The input buffer here is passed to EtwpSendDataBlock and EtwpQueueNotification:

Looking at EtwpQueueNotification, I found a reference to UmReplyObject:

The bll value here is 0, and if the byte value of rbp+0Ch is not 0, then the qword of rbp+18h will be read as a pointer to the object, and the reference to the object will be increased.

We know the root cause of the vulnerability, and the culprit is the code's inconsistent comparison of rbp+0C bytes of data. The comparison is done in EtwpNotifyGuid, and the code compares whether the value is 1 to determine whether a new UmReplyObject object needs to be created. However, in the last comparison, the value is compared to zero.

The first comparison in C code looks like this:

If (* (bool*) (rdi+0x0C) = = true)

The code form of the second comparison is as follows:

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

If the value is not 1 or 0, any value entered will be treated as the object address. Next, ObfReferenceObject will call the address, which means that the qword ptr [[InputBuffer + 0x18]-0x30] + + operation will be performed, which will result in an increase in any address.

Exploit code

The above is all the contents of this article entitled "example Analysis of Windows Kernel lifting vulnerability CVE-2020-1034". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.