CVE-2016-7255: analysis of Mining the Windows kernel to mention the right vulnerability-vulnerability warning-the black bar safety net

The Windows kernel mention the right Vulnerability, CVE-2016-7255 has been a lot of media attention. In the 11 month’s Patch Tuesday, Microsoft released for this vulnerability fix, as MS16-135 announcement of the part. According to Microsoft’s description, CVE-2016-7255 mainly used to perform targeted attacks, and by some of the“wild way”to find samples. Google and Microsoft have confirmed that a Russian hacker group APT28 used a Flash Vulnerability, CVE-2016-7855 and this kernel mention the right vulnerability to perform a targeted attack, Google also released some for this vulnerability the discussion:
https://security.googleblog.com/2016/10/disclosing-vulnerabilities-to-protect.html
https://threatpost.com/microsoft-says-russian-apt-group-behind-zero-day-attacks/121722/
http://securityaffairs.co/wordpress/53242/hacking/cve-2016-7255-zero-day.html
McAfee Labs vulnerability research team spent a lot of time to analyze this vulnerability. In this article we will briefly discuss some of our findings.
Analysis
We first from MS16-135 patch to start the analysis, 很快我们就注意到MS16-135在目标系统上更新了win32k.sys so our next step is to start comparing through binary differential means two win32k. sys file to install the patch before and after it. In addition, our test system is running Windows 7, The version number is 6. 1. 7601. 23584。
Look at the binary difference of the results, we note that the following function is modified.
! [](/Article/UploadPic/2016-12/201612312262609. png? www. myhack58. com)
Figure 1: in win32k. sys is to change the function-xxxNextWindow
After these preliminary investigations we conclude that: CVE-2016-7255 to the patch fully applied to the repair win32k. sys in xxxNextWindow function.
The following screenshot shows a patch of xxxNextWindow(x, x)the change of a more advanced overview:
! [](/Article/UploadPic/2016-12/201612312262532. png? www. myhack58. com)
Figure 2: The function xxxNextWindow advanced differential results
We can see in the repair function to add some new logic, with a red highlight. Zoom in to the first newly inserted basic block, we can see the introduction of a new code to eax + 0x23 compares the value of the operation:
! [](/Article/UploadPic/2016-12/201612312262346. png? www. myhack58. com)
Figure 3: xxxNextWindow inserted into the first basic block
Then, our next newly inserted basic block saw a similar logic.
! [](/Article/UploadPic/2016-12/201612312262724. png? www. myhack58. com)
Figure 4: xxxNextWindow inserted in the second basic block
Google has stated that the vulnerability“can be obtained by win32k. sys system call NtSetWindowLongPtr()for GWL_STYLE set to WS_CHILD window handle on the index GWLP_ID trigger.“
In fact, NtSetWindowLongPtr()only played trigger this vulnerability to the role, and the fundamental reason is that xxxNextWindow it. More specifically, by NtSetWindowLongPtr()to set inappropriate parameter can trigger xxxNextWindow in the“any address write”scene.
Now let’s look at the unpatched xxxNextWindow(x, x, …)of the decompiled version.
! [](/Article/UploadPic/2016-12/201612312262345. png? www. myhack58. com)
Figure 5: unrepaired xxxNextWindow the decompiled version
Apply the patch after xxxNextWindow(x, x, …)as shown below:
! [](/Article/UploadPic/2016-12/201612312262846. png? www. myhack58. com)
Figure 6: the repaired xxxNextWindow the decompiled version
Patched after the code using a conditional branch statement“(*(_BYTE *)(v8 + 0x23) & 0xC0) != 0x40”enhanced parameter validation.
In this new statement, the variable v8 in eax is a GetNextQueueWindow call return value. （See Figure）
! [](/Article/UploadPic/2016-12/201612312262410. png? www. myhack58. com)
Figure 7: variable v8 from the GetNextQueueWindow the call:“v8 = _GetNextQueueWindow(v7, v31, 1);”
Quick View _GetNextQueueWindow(x, x, …)is achieved, it reveals the function actually returns a pointer to the tagWND structure pointer.
The following figure shows the windbg in tagWND structure:
! [](/Article/UploadPic/2016-12/201612312262587. png? www. myhack58. com)
Figure 8: tagWND structure
Analyzing this code, we can get to know tagWND configuration offset 0x78 of the field is with the vulnerabilities associated. The following from a not repair function to decompile the lines of code confirms this:
! [](/Article/UploadPic/2016-12/201612312262301. png? www. myhack58. com)
Figure 9: unrepaired xxxNextWindow problems in the code
Now the question becomes simple: if we can control in the v8+0x78 the value at the address, it is possible in the core region of an arbitrary address for a write operation, and it is likely you can achieve the mentioned rights. Fortunately, a user state of the API NtSetWindowLongPtr it can be used in this position is set to any value.
The following figure shows, we passed to the NtSetWindowLongPtr value, 0x41414141, is the reflection to the tagWND structure, through this vulnerability you can easily achieve arbitrary memory write.
! [](/Article/UploadPic/2016-12/201612312262505. png? www. myhack58. com)

[1] [2] next