The operating system kernel is the final goal for every great exploit chain. You can look at the entries in the Zero Day Initiative (ZDI) Pwn2Own contests over the years to see that process at work. The Windows kernel has been subject to many points of attack. One of my favorites is abuse of DeviceIoControl calls to various drivers since this allows access to so many drivers written by so many vendors, many of which are not all that well written or tested.
Over the years, most of the attacks to penetrate into the Windows kernel have gone through win32k.sys -- a kernel-mode device driver that controls the Windows graphic and window management system. When Microsoft moved this functionality out of CSRSS and into the kernel twenty years ago, it instantly doubled or tripled the attack surface into the Windows kernel -- and that has been a rich mine of vulnerabilities ever since.
Another large attack surface has opened up since WDDM (Windows Display Driver Model) supplanted the earlier XDDM over the last decade. Calls to initiate actions by the display system start by going through win32k.sys, but after that there are direct calls by user processes into dgxkrnl.sys and other drivers through entry points in GDIPlus. This expanded attack surface is an inviting target for researchers.
In the spring on 2018, the ZDI purchased five vulnerabilities from ChenNan and RanchoIce of Tencent ZhanluLab that target the DirectX kernel interfaces. These purchases resulted in four CVE's from Microsoft. This post covers the vulnerabilities and provides Proof of Concept sources published on our site.
Additionally, one of the attacks (ZDI-18-946/CVE-2018-8405) was featured in a presentation by Rancho and ChenNan at the 44CON conference in September. I highly recommend that researchers review the " [PDF]. I highly recommend reading it. The presentation goes into great detail on the complex attack surface of the kernel side of WDDM.
Walkthrough of the vulnerabilities
The Proof of Concept (PoC) sources are found , and the patch from Microsoft is located on dxgkrnl.sys before running the PoC. The type confusion results from inappropriate use of the CrossAdapter flag in an allocation. The PoC code uses a CrossAdapter flag of 0 for an allocation, and then passes the resultant handle into a second allocation in which it sets a CrossAdapter flag of 1.
And here is the blue screen analysis:
The faulting code is in DXGDEVICE::CreateAllocation and is a classic type confusion walk off of the end of an allocation:
ZDI-18-947/CVE-2018-8406 - D3DKMTRender Type Confusion Vulnerability
The next vulnerability exists in the dxgmms2.sys driver, and is exposed through the D3DKMTRender method. This vulnerability also could allow a local attacker to escalate privileges to System. Our advisory for this can be found . Like the first example, this bug results in a type confusion condition. While similar in nature, these bugs have different root causes.
Again, you need to enable special pool on dxgkrnl.sys and dxgmms2.sys to see these bugs, and, of course, attach a kernel debugger to your target machine. This type confusion results from allocation operation that gets confused between two different adapters.
Relevant PoC code:
PoC crash details:
Vulnerable code:
ZDI-18-950/CVE-2018-8400 - D3DKMTRender Untrusted Pointer Dereference Vulnerability
This next vulnerability is also exposed through the D3DKMTRender routine. The vulnerability is in the DGXCONTEXT::ResizeUserModeBuffers method in dxgkrnl.sys. Our advisory for this can be found . In this case, the bug is caused by the lack of proper validation of a user-supplied value prior to dereferencing it as a pointer. The resulting pointer dereference is due to the driver trusting a flag set by the user. Here are the relevant PoC details:
Which results in the crash:
Called from:
Vulnerable code:
Obviously, this flag from the user should not lead to an arbitrary dereference in the kernel.
ZDI-18-951/CVE-2018-8401 – BasicRender Race Condition Vulnerability
This final vulnerability is a bit more complex, as the vulnerability resides in the processing of the D3DKMTMarkDeviceAsError API and the D3DKMTSubmitCommand API by the BasicRender driver. Our advisory for this can be found . Shared resources are not properly secured, which can result in a memory corruption condition. An attacker can use this to escalate privileges to SYSTEM. This type of elevation is often used by malware to install itself once a user clicks something they shouldn’t. Note that Microsoft gave one CVE for this bug and for , and follow the team for the latest in exploit techniques and security patches.
SOCIAL SHARE CARD GENERATOR