微软RDP服务高危UAF漏洞分析(CVE-2019-0708)
一、简介CVE-2019-0708经微软披露已经有一个多月了，本文将主要围绕以下几个方面介绍该漏洞经过分析验证该漏洞是一个UAF漏洞，引发UAF漏洞的指针是由何时创建以及为何该指针在Free之后又被使用，是本文重点关注的地方。该漏洞属于RDP协议实现方面的漏洞，文中会列举与该漏洞相关的RDP协议知识。二、RDP协议介绍2.1 协议简介远程桌面协议（RDP,
一、简介
CVE-2019-0708经微软披露已经有一个多月了，本文将主要围绕以下几个方面介绍该漏洞
- 经过分析验证该漏洞是一个UAF漏洞，引发UAF漏洞的指针是由何时创建以及为何该指针在Free之后又被使用，是本文重点关注的地方。
- 该漏洞属于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的过程：
- RDP连接建立，RDP Server 默认调用IcaCreateChannel() 创建MS_T120静态虚拟信道，并绑定到0x1F信道号，此时是该信道第一次绑定。
- RDP Client 在通讯的Channel Connecttion阶段告知 RDP Server 绑定名称为“MS_T120”的信道到指定信道，此时Server使用IcaFindChannelByName()函数搜索到默认创建的MS_T120信道，将该信道对象绑定到用户指定的信道号上。此时是MS_T120信道第二次绑定。
- 至此，MS_T120信道已经完成2次绑定。随后RDP Client 告知RDP Server断开第二次绑定的信道，该操作会引发RDP Server调用IcaFreeChannel()释放该信道并释放该对象占用的空间。
- 随后RDP Client 将通知RDP Server关闭RDP连接，此操作会引Server调用SingalBrokenConnection()函数释放信道号0x1F的MS_T120信道对象。由于该对象空间已经释放过，这里再次调用IcaFreeChannel()函数执行清理操作，其中ExDeleteResourceLite()会引用该对象的成员数据而触发UAF漏洞。
3.2调试过程
下图是漏洞补丁修复前后对比图：
关键的修改是针对_IcaBindChannel()函数的调用前增加了一个条件判断，判断的内容是stricmp()返回值，也就是字符串是否相等。而以字面意思解读icaFindChannelByName(),就是以名字查找信道。下图为该函数的实现，通过遍历列表，可以确定的是信道对象中偏移0x94的位置就是信道名称。
回过头来看漏洞补丁的代码，实际上打过补丁后，在调用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()进行空间释放时，由于该函数会引用已被控制的内核对象，就有机会造成读写任意内核地址进而达到任意代码执行的目的。
作者天融信阿尔法实验室
腾讯云开发者
