CVE-2020-1350是微软在2020年7月修复的DNS协议相关漏洞，CVSS给出了高达10分的评分。漏洞发现的细节最初由CheckPoint进行纰漏，

随后FSecureLabs的@maxpl0it研究员给出了相关POC脚本，我会在文末给出相关链接。

本文主要在肝完checkpoint的文章的基础上，通过[4][5]两篇文章的启发，使用POC进行漏洞分析和复现。

测试环境：Win Server2019+Win Server2016

本文原文地址：https://saturn35.com/2020/07/24/20200724-1/#more

根据checkpoint的描述，以及对相关补丁的diff后，找到漏洞函数为

在IDA中查看其流程如下所示：

伪代码如下：

可以看到在申请内存函数RR_AllocateEX的参数中，第一参数v9+v13+20表示分配大小，其值由

[Name_PacketNameToCountNameEx result] + [0x14] + [signature’s length (rdi–rax)] 决定。当此值结果在CX和DI寄存器中传递，而16位寄存器最大值为65535，当上数值结果大于65535时，将发生溢出，而真正申请到的数据是比要申请的大小小的多。

而后续我们可以看到存在memcpy拷贝函数，那么，可能存在由整数溢出的导致基于堆的缓冲区溢出。

格式如下：

Header表示DNS数据头，Question表示查询区，Answer表示应答区，后两个为认证区和附加区。

Header部分始终存在。大小为12字节，包含以下字段

ID：同一查询和应答对应相同的16位ID;

QR：一位代表查询（0）或者应答（1）；

TC：指定此消息由于长度大于传输通道上允许的长度而被截断。在DNS协议中，默认采用的传输层协议为用户数据报协议（UDP）,但UDP传输的DNS数据包限制最大为512B，并不足以触发漏洞。而此标志位是漏洞触发的关键，当其被设置为1是，在应答时，表示通知客户端，数据量比较大，让客户端用TCP重发一次查询请求，而基于TCP的DNS数据包大小可大于512字节。

查询区主要由域名、类型和类构成。

比较有趣的是域名的构成是分段式的len+str的形式：

eg:对于完整的一个域名，www.baidu.com,需要14个字节：

规定域名段的长度不能超过63个字节，所以表示域名段长度的字节最高两位没有用到，因此另有用途。

（1）当最高两位为00时，表示以上面的形式的传输

（2）当最高两位为11时，表示将域名进行压缩，该字节去掉最高两位后剩下的6位，以及后面的8位总共14位，指向DNS数据报文中的某一段域名，相当于一个指针。如0xc00c, 表示从DNS正文（UDP payload）的偏移offset=0x0c处所表示的域名。

（3）混合表示：以www.baidu.com为例，假设该域名位于DNS报文偏移0x20处，可能的用法有：

a、0xc020：表示完整域名www.baidu.com

b、0xc024：从完整域名的第二段开始，指代baidu.com

c、0x016dc024：0x01表示后面跟的size大小1，0x6d表示字符m，所以0x016d表示字符串"m"，第二段0xc024指代baidu.com，因此整段表示m.baidu.com

在漏洞函数中，当读取SIG类型响应包才回进入触发流程，因此有必要了解下其结构。

在RFC2535官方文档中，对SIG资源记录的概括如下：

其格式如下：

其中，signer's name表示生成SIG RR的签名者的域名。这是可用于验证签名的公钥RR的所有者名。通常是包含被认证的RRset的区域......可以使用标准的DNS名称压缩来压缩签名者的名称。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)