摘要： *本文中涉及到的相關漏洞已報送廠商並得到修復，本文僅限技術研究與討論，嚴禁用於非法用途，否則產生的一切後果自行承擔。
一 漏洞背景
2月12日，微軟發佈2月份月度例行安全公告，修復了多個高危漏洞，其中包括Windows DHCP Server遠程代碼執行漏洞CVE-2019-0626。當攻擊者向DHCP服務器發送精心設計的數據包併成功利用後，就可以在DHCP服務中執行任意代碼，漏洞影響範圍較大。
二 漏洞影響版本
Windows 7
Windows 8.1
Windows 10
Windows Server 2008
Windows Server 2012
Windows Server 2016
Windows Server 2019
三 協議簡介
DHCP，動態主機配置協議，前身是BOOTP協議，是一個局域網的網絡協議。DHCP通常用於集中管理分配IP地址，使client動態地獲得IP地址、Gateway地址、DNS服務器地址等信息。DHCP客戶端和DHCP服務端的交互過程如下圖所示。
傳輸的DHCP協議報文需遵循以下格式：
DHCP包含許多類型的Option，每個Option由Type、Length和Data三個字段組成。
Type取值範圍1~255，部分Type類型如下圖所示。
DHCP服務在處理VendorSpecific 類型（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）。
（1）DHCP服務器收到Discovery請求報文，對數據包進行處理。首先執行ExtractOptions處理Options，當處理vendor_specific類型的Option時，進入到ParseVendorSpecific進行處理。POC中構造一個合法的vendor_specific1，目的是為了繞過84~85行的校驗代碼，使程序順利執行到ParseVendorSpecific函數。
（2）ParseVendorSpecific調用UncodeOption函數。
a. 32~43行在do-while循環中計算Option結構的 Length值之和，保存到v13，作為分配堆內存長度。POC中包含兩個vendor_specific結構，首先處理vendor_specific1，計算v13，即vendor_specific1長度a，並且使v12指向下一個Option結構vendor_specific2，當進入43行while條件判斷，由於vendor_specific2長度不合法，do-while循環結束。
b. 48行調用HeapAlloc分配堆內存，分配的內存大小v13=a。
c. 51~58行在for循環中依次將vendor_specific結構中的Data拷貝到分配的堆內存中。進入第一次循環時，v1指向vendor_specific1，v8指向末尾位置，滿足條件v1 五 補丁比對 補丁後的版本添加了對Length字段的有效性判斷。 
閱讀更多 安全可以很簡單 的文章
