在研究NVIDIA DxgDdiEscape Handler的漏洞时，可以非常明显的感觉到过去几年中讨论的GDI原语的方法对于可靠的利用此漏洞毫无帮助。

因此，我想出了另一个解决方案：可以选择映射一些的特殊的虚拟地址，强制对齐这些地址的页目录，然后使用漏洞来改写这个页目录。

简单来讲，这种操作允许在我们选择的/一直的虚拟地址上映射任意的物理地址。

在接下来的部分中，我将介绍x64分页表的详细信息以及利用此漏洞的特殊技巧。

x64使用了4级页表来映射物理内存与虚拟内存。这4级分别是PML4（Page Map Level 4）（俗名：PXE），PDPT（Page Directory Pointers），PD（Page Directory）以及PT（Page Table）。CR3（控制寄存器）保存着当前进程的PML4基地址（物理地址）。

下图是x64下从虚拟内存到物理内存寻址的大致流程：

举个栗子：

如果我们要遍历虚拟地址为0x71000000000（仅仅是个例子。。）：

首先，分解这个虚拟地址：

虚拟地址的低12位表明了页内偏移。接下来（译注：从低位到高位的顺序）的9位是PT（Page Table）索引，接着是PD（Page Directory）索引，再接下来的9位是PDPT（Page Directory Pointer Table）索引，再往下的9位是PML索引（Page Mapping Level 4）。

我使用了下边这个结构体来表示这些数据：

比如说：

对于我们之前的例子（虚拟地址为0x71000000000）来讲，我们通过上边的结构体获得了pml4_index=0x0E，pdpt_index=x040，pd_idnex=0，pt_indedx=0,offset=0。

现在，我们知道了对于0x71000000000这个虚拟地址，PML4 目录是0x38a0000040653867

这实际上是一个被称为MMPTE的8字节结构，我们需要从中得到PFN（Page Frame Number）。

现在，得到了PFN是0x40653。将PFN*PageSize就得到了下一级结构PDPT的基址，然后使用pdpt_index来索引PDPT.

继续将PFN(0x41cd7)*PageSize得到了下一级结构PD的基址是0x41cd7000。使用pd_index来索引这张表。

和之前同样的操作使用PFN（0x3e7d8）* PageSize得到了PT的基址是0x3e7d8000。使用pt_index来索引这张表。

最终，剩下的就是将这个PFN（0x3d7d9）* PageSize + page_offset。

现在我们知道了虚拟地址0x71000000000对应的物理地址是0x3d7d9000。

如果你想更加深入的了解这些机制，可以参考一下资料：

https://www.coresecurity.com/blog/getting-physical-extreme-abuse-of-intel-based-paging-systems-part-1
https://www.coresecurity.com/blog/getting-physical-extreme-abuse-of-intel-based-paging-systems-part-2-windows
https://www.coresecurity.com/blog/getting-physical-extreme-abuse-of-intel-based-paging-systems-part-3-windows-hals-heap

最早被Google Project Zero报告，在PDXGKDDI_ESCAPE各种回调中，有一个分支出现了漏洞。这是一个用户模式display驱动程序与display 微端口驱动之间共享数据的接口。

经过一番研究，我决定把重点放在‘NVIDIA: Unchecked write to user provided pointer in escape 0x600000D’,这条信息上。这个漏洞可以让我们在任意的虚拟地址上写入数据，但是不能控制正在写入的数据或数据的大小。事实上，写入的大部分数据是0，内部代码强制执行了大小检查只允许我们至少写入0x1000（4096）字节。

原始POChttps://bugs.chromium.org/p/project-zero/issues/detail?id=911&can=1&q=NVIDIA%20escape

由于缺乏对正在写入的数据或者写入数据大小的控制，我不得不放弃最近使用的GDI原语，认识到需要搞点与众不同的事了。

之前讨论的“x64中的分页机制”中的页表有时也存在于被称为"PTE空间"的内存区域，通过对该区域的滥用，我得到了一个解决方案。

PTE空间是Windows内核在需要管理分页结构时使用的虚拟内存区域。（涉及页访问权限，将内容移动到pagefile中，协同内存映射等等。。）

通过一些偏移和掩码，我们可以计算出任何给定虚拟地址（在PTE空间上）的每个表的虚拟地址。

以下代码来自于：https://github.com/JeremyFetiveau/Exploits/blob/master/Bypass_SMEP_DEP/mitigation%20bypass/Computations.cpp)

再来一次，对于我们的例子0x71000000000这个虚拟地址来说：

GetPML4VirtualAddress(0x71000000000) 将返回 0xFFFFF6FB7DBED070

可以通过WINDBG或者KD来确认：

此刻，我们已经具备了攻击计划的全部要素：

可以使用VirtualAlloc获得一个被映射的虚拟地址（例如：0x71000000000，姑且称这个被映射的虚拟地址位ADDR1a）,同时破坏它在PTE空间中的PD目录（例如：FFFFF6FB41C40000）使其指向物理地址0。

看起来就像这样：

此时，我们的原语就已经准备好了。

我们可以通过对0x71080000000处的_MMPTE写入一些数据使这个地址有效。然后从0x71000000000读取和写入。

完成这项工作的宏定义：

我们使用物理0地址的原因是漏洞只允许我们写0。但是它到底是怎么起作用的呢？？？如果物理地址无效，我们的操作将立即导致BSOD。

1)如何保留_MMPTE的标志位。我们需要至少保留12标志位中的3位以表明我们从RING3中映射的地址是可读可写的。

可以通过写数据的时候错位1字节的偏移来解决这个问题（ 写入FFFFF6FB41C40001来替代写入FFFFF6FB41C40000）。

2)事实上，漏洞需要我们至少写入0x1000字节，这意味着我们需要在FFFFF6FB41C40001来写入ADDR1a的PD表。同时，要确保FFFFF6FB41C41001是一个可以写入的地址。同样，可以通过VirtualAlloc

来解决这个问题，但是，这次映射的地址变为了0x71040000000（称之为ADDR1b）。

分解0x71040000000这个地址之后，它看起来像这样（注意：仅仅将ADDR1a的pfpt_index=0x40改为 `0x41）：

在函数GetPDEVirtualAddress(0x71040000000)执行后，我们得到了FFFFF6FB41C41000。所以我们现在解决了第二个问题。

3)这个问题稍微有点复杂，依赖于硬件或者系统。由于性能原因，分页结构被缓存在TLB（Translation Lookaside Buffer，转换检测缓冲区）中。

在使用完映射原语之后，我们需要某种方式来使TLB无效或者刷新TLB，否则对页表所做的操作将不会立即生效（因为旧的值被缓存了）。

尝试强制Windows触发TLB刷新的方式似乎非常依赖于硬件。在某些处理器上，页面错误可能足以强制执行TLB刷新，而在另一些处理器上则需要执行任务切换（CR3重加载），在某些情况下，即使这样做也不够，可能需要IPI（处理器间中断）。

我解决这个问题的方法（尽管不是100％可靠）是尝试以上所有方法。。。

4)我们需要知道PML4表的实际物理地址（CR3的值），否则将无法将目标虚拟地址重新映射到我们控制的地址。

假设我们知道我们想写的虚拟地址0xFFFFF900C1F88000有一些特定的值。我们需要遍历分页表PML4-> PDPT-> PD-> PT-> [物理地址]，然后将具有该物理地址的有效_MMPTE写入ADDR2a（即：0x71080000000）。

所以当我们写入ADDR1a（即：0x71000000000）时，我们将写入相同的物理内存，就像我们写入0xFFFFF900C1F88000一样。

为了遍历分页表，我们需要知道PML4的物理地址。

在较新的硬件上，我们可以使用Enrique Nissim的技术在最新的Windows 10版本上猜测我们的PML4条目。（Enrique的论文和代码https://github.com/IOActive/I-know-where-your-page-lives）

但是，我们将重点关注较旧的硬件/ Windows版本（Windows 7/8 / 8.1和10 Gold），所以我们只能通过蛮力来解决这个问题了。

可以在注册表中查询有效的物理地址范围。 （HKLM\HARDWARE\RESOURCEMAP\System Resources\Physical Memory）

为了简单起见，我将假定有最大范围内有RAM（虽然这不会是100％）。然后，我们可以尝试每个物理页面，直到找到一个具有正确的PML4自引用项（在索引0x1ed）。

5)我们将无法从每个分页开始遍历到最终的物理地址。内存映射到分页文件中也是一个问题，以及文件映射以及其他标志位延缓了PFN真正的值。幸运的是，这似乎并不影响我们对PML4基址的扫描。

恢复PFN：

重映射虚拟地址代码：

读写原语(极小)：

6)修复PFN数据库和工作集列表是就像Catch 22（第二十二条军规，小说）一样：

成功利用之后，如果需要终止利用，机器将会BSOD。Windows内存管理试图回收当前未使用的页面，会在PFN数据库(nt!mmPfnDatabase)和进程工作集（EPROCESS->Vm->VmWorkingSetList->Wsle）中遇到不匹配的条目。

我们可以遍历PFN数据库寻找 PteAddress 匹配我们的页面入口地址的 MMPFN条目。这将使我们的篡改页面回到原来的PFN和正确的WsIndex。这些数据足够恢复使修改过的条目回到正常的行为。

坏消息是，实际上，只要我们恢复了两个被篡改的分页条目之一（ADDR1a或ADDR2a）回到他们原来的状态，我们将失去读写原语，因此无法单独通过这个技术解决这两个问题。

我解决这个问题的方法是将这种技术与“Abusing GDI for ring0 exploit primitives”中描述的技术相结合。使用Paging table原语来破坏位图，并从中使用GDI原语来恢复我们相关的mmPfnDatabase条目。

考虑到bug的限制，需要真正的硬件（不可能进行虚拟机调试）以及Windows工作集微调整导致的额外不稳定性，这是一个很难利用的漏洞。

我希望这种技术虽然不完整，或者说有点过时，但仍然可以被其他漏洞挖掘人员使用。

[注意]APP应用上架合规检测服务，协助应用顺利上架！