From DirectX to the Windows Kernel--a few of the CVE vulnerability analysis-vulnerability warning-the black bar safety net

One, Foreword
Operating systemthe kernel is each vulnerability the use of chain final goal, we can view the Zero Day Initiative (ZDI) Pwn2Own calendar year, race, and understand this aspect of the content. Windows kernel has always been the attacker keen to target, my favorite is the abuse of the DeviceIoControl calls with various drive deal, so you can visit many of the vendors prepare a variety of driving, many of which drive the code written is not perfect, also not after extensive testing.
Over the years, many of the attackers are by means of win32k. sys to attack the Windows kernel this is a kernel-mode device driver, you can control the Windows graphics and window management system. When will Microsoft the functions from CSRSS to migrate to the kernel, enter the Windows kernel-the attack surface is also increased by 1 times or 3 times, since then it has become one of the many vulnerabilities of the homeland.
During the past decade, since the WDDM Windows Display Driver Model replaced the early XDDM after, we found another huge attack surface. Displayed system call operation will first go through the win32k. sys the treatment, but after that, 用户进程就可以直接调用dgxkrnl.sys, or through the GDIPlus entry point directly calls the other drive. This further expanded the attack surface, thus causing the researchers of interest.
2018 spring, ZDI from Tencent ZhanluLab of ChenNan and RanchoIce bought 5 for the DirectX kernel interface vulnerabilities, exploit these vulnerabilities from Microsoft’s acquisition of the 4 CVE number. This article analyses these vulnerabilities, and provides a corresponding PoC code code already published on our website in.
In addition, the Rancho and ChenNan in the 9 months of the 44CON conference presented by one of the attack techniques ZDI-18-946/CVE-2018-8405, and strongly recommend everyone to study the speech of presentation.

Second, DirectX overview
In the analysis of vulnerability before, we first briefly review the DirectX interface and the drive.
The DirectX graphics kernel subsystem by 3 a kernel-mode driver consisting of: dxgkrnl.sys and dxgmms1.sys以及dxgmms2.sys the. These drive by win32k. sys and its own interface to communicate with the user. In addition, 这些驱动也会与BasicRender.sys and BasicDisplay. sys and miniport（micro ports display drive communication.
DirectX defines a number of complex kernel object, most object names to DXG at the beginning. The user through many of the complicated API interface, and DirectX interaction, many of which interface to D3DKMT at the beginning, the other interface to DXGK at the beginning.
One of the more interesting parts of the entry point as shown below:
D3DKMTEscape: this entry points to the user full control of a piece of data as input. The input data may be very large, so the system is likely to be stored in the user memory, without switching to the kernel during the processing in the kernel to capture this piece of data. As a result, if not properly addressed, the relevant kernel routine it is easy to the presence of TOC/TOU time of check, time of use, based on the test of time/usage time of an asynchronous attack vulnerability. This data is not standardized structure, each drive has its own definition.
D3DKMTRender: this entry point is the actual rendering of the graphics data to the core. From the user address of the command and the patch buffer by the kernel driver to explain, in fact, these data will be passed to the miniport driver. Similarly, this is also a race condition problem in the breed. In addition, the rendering process will also generate a worker thread, the more prone to race condition vulnerability.
D3DKMTCreateAllocation: this entry point is used to allocate memory. Since the transfer to the API of the different flags and the handle between a variety of complex interactions, so there may be some issue with reference to the following ZDI-18-946.
From an attacking point of view, from IOActive Ilja van Sprundel had at the 2014 Black Hat conference to do tricks to WDDM of a speech, entitled“Windows Kernel Graphics Driver Attack Surface”, which is a very good overview of the information. Highly recommend the first reference to this material, which describes in detail about the WDDM kernel aspects of the complex attack surface.

Third, vulnerability analysis
You can visit here to download the PoC source code. If you want to reproduce the crash problem, you need to install 2018 8 months before the Windows version at the time Windows hasn’t patched it. During the test, remember the kernel debugger attach on the target host, and to attack the drive on set Special Pool special pool. I have been in the Windows 10 x64 bit systems on the test through this paper the analysis of these vulnerabilities.
ZDI-18-946/CVE-2018-8405: the D3DKMTCreateAllocation type confusion vulnerability
Our analysis of the first vulnerability is located in the dgxkrnl. sys DXGDEVICE::CreateAllocation method, by D3DKMTCreateAllocation interface is triggered, a local attacker could exploit the vulnerability elevation of privileges to SYSTEM level. You can visit here to read our security Bulletin, visit here for the Microsoft patch. Vulnerability lies at the root of the drive does not properly validate user-supplied data, resulting in the presence of type confusion.
In order to reproduce the vulnerability, we need to run a PoC before in dxgkrnl. sys provided a Special Pool. Type confusion problem stems from in the pool allocation is not the correct use of CrossAdapter flag. In the pool distribution process, the PoC code will CrossAdapter flag is set to 0, and then the resulting handle is passed to the 2 the allocation process, wherein CrossAdapter flag is set to 1.
! [](/Article/UploadPic/2018-12/2018127174957850. png)
Blue screen of information analysis as follows:
! [](/Article/UploadPic/2018-12/2018127174957543. png)
! [](/Article/UploadPic/2018-12/2018127174957797. png)
! [](/Article/UploadPic/2018-12/2018127174958770. png)
The error code is located in the DXGDEVICE::CreateAllocation, this is a in the allocation process at the end of a typical type confusion issue:
! [](/Article/UploadPic/2018-12/2018127174958830. png)
ZDI-18-947/CVE-2018-8406: the D3DKMTRender type confusion vulnerability
The next vulnerability is located in the dxgmms2. sys the drive, by D3DKMTRender method is triggered. The attacker can also exploit this vulnerability will be elevated to the SYSTEM level. You can visit here to learn about our security Bulletin, visit here to obtain the appropriate patches. With the first vulnerability, this bug will cause a type confusion situation. Although essentially similar, but these bug the root cause is not the same.

[1] [2] next