cve-2016-0143 Vulnerability Analysis (2016.4)

cve-2016-0143 Vulnerability Analysis

0x00 background

4 Month - Day, Nils Sommer in the Exploitdb a new one was burst out on the Windows Kernel Vulnerabilities PoC . The vulnerability affects all versions of the Windows operating system, which is fixed by Microsoft on a 4 -month patch day, when an attacker gains access to a successful exploit .

0x01 Vulnerability Analysis

Nils Sommer There is no description of the vulnerability in this case, and I think the crash scenario would be NULL Pointer dereference or UAF vulnerability, which, after a rough analysis, feels an integer overflow vulnerability, but finally defines it as a special NULL Pointer dereference vulnerabilities. The following is a simple analysis of the cause of vulnerability.

In Xxxrealdrawmenuitem

the place to crash is in Win32k!xxxrealdrawmenuitem function, within the WinDbg to view the memory state at the time of the crash:

of the crash context code. IDA , name it a procedure A (it will be used when the last note) :

in the Crash before the eax Will and [Ebp+arg_8] do a symbolic multiplication, and the result and ebx make comparisons to determine whether to perform Crash 's instructions.

at this time, eax to be PoC in R.bottom and the R.top The result of the operation, which is specified in the win32k!xxxdrawmenubartemp , the algorithm is: eax= r.bottom-r.top-1;

[Ebp+arg_8] to be PoC in the info.bmiHeader.biSize;

PoC the value given will make "Imul Eax,[ebp+arg_8]" generate overflow, toward Crash process. This seems to be due to an integer overflow caused by the vulnerability, in fact, the normal process will go this process, this is not the cause of the vulnerability.

The operation of the ecx from [ebp+var_28] gets the original value of 1 , [ebp+var_28] this should be Dibobject address, but the function for which memory is allocated win32k! Surfmem::bcreatedib , and there is no memory space allocated for it, the key to the vulnerability is here .

The following analysis creates Dibobject the cause of the failure.

In Surfmem::bcreatedib

Surfmem::bcreatedib the function call stack:

Xxxdrawmenubartemp

à grecreatedibitmapreal

àsurfmem::bcreatedib

in the Surfmem::bcreatedib There is a piece of code inside the function that names the procedure B:

at this time eax xxxrealdrawmenuitem in the function. edi [ebp+arg_0] poc info.bmiheader.bisize*4 poc 0x7fffff69 and 0x274

The same overflow occurs when both are multiplied, but because it is an unsigned operation, edx!=0 . After calling the function ulonglongadd ,[ebp+allocationsize+4]=edx=139h!=0, so it goes to the failed process , Memory is not allocated for dibobject , and The return value of the Grecreatedibitmapreal function is 0.

If overflow does not occur, and the product of both (+0x154) less than 7FFFFFFFh, Surfmem::bcreatedib The function will be based on this product (+0x154) to be Dibobject allocate a piece of memory. The code that allocates memory is in IDA :

after the assignment is successful, the Allocateobject the return value as Grecreatedibitmapreal function returns a value and assigns a value to the Xxxrealdrawmenuitem in the function [ebp+var_28] .

0x02 patch comparison

to see how Microsoft is going to fix this loophole, the post-patch section Xxxrealdrawmenuitem function code in IDA in the following:

can see that after the patch, Xxxrealdrawmenuitem function in the call Grecreatedibitmapreal function, a check is made on the return value : if the return value equals 0 that represents the creation Dibobject fails, the operation is no longer entered Dibobject processes, i.e. processes A in the.

Possible use of 0x03

No one has publicly exploited the code yet, and here is a description of how the vulnerability could be exploited.

Crash Place is a pair of ecx The code snippet for the loop operation, the number of cycles is "Imul Eax,[ebp+arg_8]" of the product. Under normal circumstances, the dibobject of the application is operated.

In this loop operation, there is a controllable write operation instruction in IDA :

The instructions in the red box are the write instructions that are said, edx It is only available after a number of instruction operations, but all of the operations involved are ecx The associated memory value because ecx That is , the content of the 0-page address is controllable, so edx can be controlled as well.

so theoretically, in the case of Win8 in the previous system, it was possible to turn this instruction operation into:

mov [haldispatchtable+4],shellcodeaddress

The user layer is then triggered again to complete the right to raise.

0x04 Other

r.bottom r.top and info.bmiheader.biwidth poc The values are exactly the same. , r.top and crash :

1. Process B Distribution Dibobject failed.
2. Process A towards Crash process.

Process B and Process A to meet these two conditions, the situation is as follows.

Process B
1. process B does not overflow, and the value after the product < 0x7FFFFFFF, resulting in allocateobject The call failed.

2. process B does not overflow, and the value after the product > 0x7FFFFFFF, do not go to call The Allocateobject process.

3. process B overflow, do not go to invoke the allocateobject process.

Process A

1. no overflow.

2. The result after overflow is negative, and the SF bit is changed to 1(signed number comparison).

based on the process given above A and Process B can cause Crash , here are two specific combinations that are interesting to modify the original PoC the corresponding value in the test, will Crash the.

Combination 1

Process B situation 1+ Process A the situation 1 , There was no overflow in two places , but Crash , it also indicates that it is not an integer overflow vulnerability.

Combination 2

Process B situation All Process A situation 2:

cve-2016-0143 Vulnerability Analysis (2016.4)