Windows DHCP Server远程代码执行缝隙分析（CVE-2019-0626）
颁布功夫 2019-02-19
缝隙布景
2月12日，， ，，，，，微软颁布2月份月度例行安全布告，， ，，，，，建复了多个高危缝隙，， ，，，，，其中蕴含Windows DHCP Server远程代码执行缝隙CVE-2019-0626。。。。。。。。当攻击者向DHCP服务器发送精心设计的数据包并成功利用后，， ，，，，，就能够在DHCP服务中执行肆意代码，， ，，，，，缝隙影响领域较大。。。。。。。。针对此缝隙，， ，，，，，8827太阳集团ADLab第一功夫对其进行了具体分析。。。。。。。。
缝隙影响版本
Windows 7
Windows 8.1
Windows 10
Windows Server 2008
Windows Server 2012
Windows Server 2016
传输的DHCP和谈报文需遵循以下体式：
DHCP蕴含很多类型的Option，， ，，，，，每个Option由Type、Length和Data三个字段组成。。。。。。。。
Type取值领域1~255，， ，，，，，部门Type类型如下图所示。。。。。。。。
DHCP服务在处置Vendor Specific 类型（Type=43）的Option结构存在安全缝隙。。。。。。。。首先看下DHCP服务法式对Option的处置过程，， ，，，，， ProcessMessage函数掌管处置收到的DHCP报文，， ，，，，，挪用ExtractOptions函数处置DHCP的Option字段，， ，，，，，传入函数ExtractOptions的参数1（v7）为DHCP报文指针，， ，，，，，参数3（*(unsigned int *)(v5 + 16)）对应指针偏移地位+16的数据，， ，，，，，即Len字段。。。。。。。。
ExtractOption函数如下所示。。。。。。。。 v6 = (unsigned __int64)&a1[a3 - 1];指向报文末尾地位；；；；；v10=a1+240;指向报文中Option结构。。。。。。。。在for循环中处置分歧类型的Option结构，， ，，，，，当type=43（Vendor Specific Information），， ，，，，，传入指针v10和指针v6作为参数，， ，，，，，挪用ParseVendorSpecific函数进行处置。。。。。。。。
机关一个DHCP Discovery报文，， ，，，，，POC如下所示，， ，，，，，POC蕴含两个vendor_specific 类型的Option结构。。。。。。。。vendor_specific1是合法的Option结构，， ，，，，，Length取值0x0a蹬宗Data的现实长度（0x0a），， ，，，，，vendor_specific2是不合法的Option结构，， ，，，，， Length取值0x0f大于Data的现实长度（0x0a）。。。。。。。。
DHCP服务器收到Discovery要求报文，， ，，，，，对数据包进行处置。。。。。。。。首先执行ExtractOptions处置Options，， ，，，，，当处置vendor_specific类型的Option时，， ，，，，，进入到ParseVendorSpecific进行处置。。。。。。。。POC中机关一个合法的vendor_specific1，， ，，，，，主张是为了绕过84~85行的校验代码，， ，，，，，使法式顺利执行到ParseVendorSpecific函数。。。。。。。。
补丁比对
补丁后的版本增长了对Length字段的有效性判断。。。。。。。。
2月12日，， ，，，，，微软颁布2月份月度例行安全布告，， ，，，，，建复了多个高危缝隙，， ，，，，，其中蕴含Windows DHCP Server远程代码执行缝隙CVE-2019-0626。。。。。。。。当攻击者向DHCP服务器发送精心设计的数据包并成功利用后，， ，，，，，就能够在DHCP服务中执行肆意代码，， ，，，，，缝隙影响领域较大。。。。。。。。针对此缝隙，， ，，，，，8827太阳集团ADLab第一功夫对其进行了具体分析。。。。。。。。
缝隙影响版本
Windows 7
Windows 8.1
Windows 10
Windows Server 2008
Windows Server 2012
Windows Server 2016
Windows Server 2019
和谈简介
传输的DHCP和谈报文需遵循以下体式：
DHCP蕴含很多类型的Option，， ，，，，，每个Option由Type、Length和Data三个字段组成。。。。。。。。
Type取值领域1~255，， ，，，，，部门Type类型如下图所示。。。。。。。。
DHCP服务在处置Vendor Specific 类型（Type=43）的Option结构存在安全缝隙。。。。。。。。首先看下DHCP服务法式对Option的处置过程，， ，，，，， ProcessMessage函数掌管处置收到的DHCP报文，， ，，，，，挪用ExtractOptions函数处置DHCP的Option字段，， ，，，，，传入函数ExtractOptions的参数1（v7）为DHCP报文指针，， ，，，，，参数3（*(unsigned int *)(v5 + 16)）对应指针偏移地位+16的数据，， ，，，，，即Len字段。。。。。。。。
ExtractOption函数如下所示。。。。。。。。 v6 = (unsigned __int64)&a1[a3 - 1];指向报文末尾地位；；；；；v10=a1+240;指向报文中Option结构。。。。。。。。在for循环中处置分歧类型的Option结构，， ，，，，，当type=43（Vendor Specific Information），， ，，，，，传入指针v10和指针v6作为参数，， ，，，，，挪用ParseVendorSpecific函数进行处置。。。。。。。。
ParseVendorSpecific函数内部挪用UncodeOption函数。。。。。。。。UncodeOption函数参数a1指向option肇始地位，， ，，，，，a2指向报文的末尾地位。。。。。。。。UncodeOption函数存在安全缝隙，， ，，，，，下面结合POC和补丁比对进行分析。。。。。。。。
机关一个DHCP Discovery报文，， ，，，，，POC如下所示，， ，，，，，POC蕴含两个vendor_specific 类型的Option结构。。。。。。。。vendor_specific1是合法的Option结构，， ，，，，，Length取值0x0a蹬宗Data的现实长度（0x0a），， ，，，，，vendor_specific2是不合法的Option结构，， ，，，，， Length取值0x0f大于Data的现实长度（0x0a）。。。。。。。。
DHCP服务器收到Discovery要求报文，， ，，，，，对数据包进行处置。。。。。。。。首先执行ExtractOptions处置Options，， ，，，，，当处置vendor_specific类型的Option时，， ，，，，，进入到ParseVendorSpecific进行处置。。。。。。。。POC中机关一个合法的vendor_specific1，， ，，，，，主张是为了绕过84~85行的校验代码，， ，，，，，使法式顺利执行到ParseVendorSpecific函数。。。。。。。。
ParseVendorSpecific挪用UncodeOption函数，， ，，，，，具体如下：
48行挪用HeapAlloc分配堆内存，， ，，，，，分配的内存大幼v13=a。。。。。。。。
补丁比对
补丁后的版本增长了对Length字段的有效性判断。。。。。。。。
京公网安备11010802024551号