一、简介
CVE-2019-0708经微软披露已经有一个多月了，本文将主要围绕以下几个方面介绍该漏洞
1、 经过分析验证该漏洞是一个UAF漏洞，引发UAF漏洞的指针是由何时创建以及为何该指针在Free之后又被使用，是本文重点关注的地方。
2、 该漏洞属于RDP协议实现方面的漏洞，文中会列举与该漏洞相关的RDP协议知识。
二、RDP协议介绍
2.1 协议简介
远程桌面协议（RDP, Remote Desktop Protocol）是一个多通道（multi-channel）的协议。
RDP协议也是C/S网络结构，双方通过TCP连接进行通信，基本也是基于请求/响应这样的数据交换模式，这里贴一张来自微软发布的RDP协议时序图，该图详细描述了RDP连接中请求及响应的顺序及过程。
该文档（[MS-RDPBCGR].pdf）地址如下：
文中不介绍通讯细节，有兴趣的读者可以自行阅读该文档。
2.2静态虚拟信道（Static Virtual Channels）
静态虚拟通道允许RDP Client和RDP Server通过主RDP数据连接通信。虚拟通道数据是特定于应用程序的，对RDP不透明。连接时最多可以创建31个静态虚拟通道。RDP Client在连接序列的Basic Settings Exchange阶段请求并确认所需虚拟通道列表，并在Channel Connection阶段进行信道的连接。
每个虚拟通道充当独立的数据流。RDP Client和RDP Server检查在每个虚拟通道上接收的数据，并将数据流路由到适当的处理函数以进行进一步处理。
三、UAF成因及调试过程
已确认的是，CVE-2019-0708为UAF漏洞，众所周知UAF漏洞主要是由于对象指针在释放后再次被使用而引发的安全问题。那么在这一部分内容中，我将描述引发UAF漏洞的指针是由何时创建以及为何该指针在Free之后又被使用。
3.1触发UAF的过程：
1) RDP连接建立，RDP Server 默认调用IcaCreateChannel() 创建MS_T120静态虚拟信道，并绑定到0x1F信道号，此时是该信道第一次绑定。
2) RDP Client 在通讯的Channel Connecttion阶段告知 RDP Server 绑定名称为“MS_T120”的信道到指定信道，此时Server使用IcaFindChannelByName()函数搜索到默认创建的MS_T120信道，将该信道对象绑定到用户指定的信道号上。此时是MS_T120信道第二次绑定。
3) 至此，MS_T120信道已经完成2次绑定。随后RDP Client 告知RDP Server断开第二次绑定的信道，该操作会引发RDP Server 调用IcaFreeChannel()释放该信道并释放该对象占用的空间。
4) 随后RDP Client 将通知RDP Server关闭RDP连接，此操作会引发Server调用SingalBrokenConnection()函数释放信道号0x1F的MS_T120信道对象。由于该对象空间已经释放过，这里再次调用IcaFreeChannel()函数执行清理操作，其中ExDeleteResourceLite()会引用该对象的成员数据而触发UAF漏洞。
3.2调试过程
下图是漏洞补丁修复前后对比图：
关键的修改是针对_IcaBindChannel()函数的调用前增加了一个条件判断，判断的内容是stricmp() 返回值，也就是字符串是否相等。
而以字面意思解读icaFindChannelByName(), 就是以名字查找信道。下图为该函数的实现，通过遍历列表，可以确定的是信道对象中偏移0×94的位置就是信道名称。
回过头来看漏洞补丁的代码，实际上打过补丁后，在调用icaBindChannel()函数的之前，也是进行信道名称的判定，当信道名称为”MS_T120” 的时候，后续调用icaBindChannel()的第三个参数，强制改为0x1F。
这里看一看icaBindChannel()函数的实现，关键在第12行的代码中，会将传入该函数参数1的信道指针，写入一个内存地址中。显而易见的是，写入的地方是通过参数2及参数3计算得到。
实际上这个函数就是漏洞的关键，至于为什么关键，我们后面再谈。首先先介绍一下，引起UAF的对象指针是何时创建的。
早在前文已经介绍过， RDP协议定义静态虚拟信道，而名称为MS_T120的信道就是其中一个。MS_T120在RDP协议建立之初， 就会由RDP服务端主动创建，本次漏洞引起UAF的对象指针就是MS_T120信道。termdd!icaCreateChannel()函数用于创建信道，在该函数设置断点，使用微软远程桌面连接工具连接并观察一下该信道建立的过程。
通过分析该函数代码可知，参数2偏移0xC的位置为信道名称。建立RDP连接，WinDbg停在IcaCreateChannel()处，其参数中的名称正是MS_T120
进一步跟踪该函数，进入了关键函数_IcaAllocateChannel()，如下图，该函数首先调用ExAllocatePoolWithTag()申请空间，之后就是对象成员初始化工作。
值得注意的是，在初始化完部分成员变量之后，又调用了icaBindChannel(), 在windbg中实时跟踪该调用
可以发现，此时的参数3为0x1F，此时调用icaBindChannel()将新创建的MS_T120信道放入数组下标0x1F的位置.
也就是说，MS_T120信道对象指针在RDP 连接创建的时候就会建立，并立即绑定到0x1F信道号中。这是该指针创建的地方，在这里还将该信道绑定到了0x1F信道号中。
此时回过头来看微软补丁修复的地方，未修复之前，程序代码在调用icaFindChannelByName()之后，紧接着调用icaBindChannel()将信道绑定到指定的信道号中。
在修复之后，会判断信道是否为MS_T120，如果是，将绑定的信道号重定向为0x1F，而不是用户指定的信道号。实际上UAF漏洞的关键就在这里，我们知道MS_T120信道在连接建立之初就已经和0x1F绑定，此时如果再次将MS_T120和另一个信道号绑定，在关键数组中就会存在2个指针值，也就是绑定了2次。
目前在Github上（https://github.com/n1xbyte/CVE-2019-0708/ ）有一份可以UAF导致蓝屏的POC，下面跟踪验证一下。
该POC使用Python编写，在ubuntu上安装python环境即可运行该POC
该POC通过发送MCS Connect Initial请求，触发RDP 服务端中icaBindVirtualChannel()中引发UAF漏洞的代码。
继续单步走观察调用_IcaBindChannel()时的信道号，下图可见此时信道号为3.此时会将MS_T120信道与 POC中指定的3号信道号绑定。
之后该POC会发送数据包通知RDP服务端断开3号信道的连接，这将会引发服务端调用icaFreeChannel(), 该函数会调用ExFreePoolWithTag() 释放空间。
之后POC通知RDP Sever关闭RDP连接，而在关闭连接的时候，会触发默认的位于下标0x1F的信道释放操作，如下图所示（图片为多次调试所截取， 其中关键指针值不同不要引起疑惑）：
这里继续单步走， 可以发现触发了内核异常。
F5继续运行系统，引发蓝了。显示如下
经过智能分析后如下，核心原因则是0x83e9b362处的代码对ecx保存的内存地址进行了写，可以看到的是，当时的ecx为0， 根据异常类型表示，当前IRQL无法对0地址进行读写。
仔细看下2张图可以发现，ecx 来源于edi，而edi 是icaFreeChannel()的传入参数，也就是待释放的信道对象指针。已释放的指针被再次引用，所以导致了漏洞。
这里引用的来源即icaFreeChannel()中调用的ExDeleteResouceLite()，在释放信道对象之前，会使用该对象的一些数据。
四、结语
通过以上的分析可知，MS_T120信道被绑定两次（一次由RDPserver创建并绑定，第二次由我们发送数据包绑定）。由于信道绑定在两个不同的ID下，我们得到两个独立的引用。
当使用其中的一个引用来关闭信道时，将删除该引用，信道对象也将释放。 但是，另一个引用仍然存在。如果我们可以在第一次释放信道对象空间之后，通过内核POOL喷射，获得在该信道对象填充自定义数据的能力，在第二次调用IcaFreeChannel()进行空间释放时，由于该函数会引用已被控制的内核对象，就有机会造成读写任意内核地址进而达到任意代码执行的目的。