作者：啟明星辰ADLab
公眾號：ADLab

1. 漏洞背景

2月12日，微軟發布2月份月度例行安全公告，修復了多個高危漏洞，其中包括Windows DHCP Server遠程代碼執行漏洞CVE-2019-0626。當攻擊者向DHCP服務器發送精心設計的數據包并成功利用后，就可以在DHCP服務中執行任意代碼，漏洞影響范圍較大。針對此漏洞，啟明星辰ADLab第一時間對其進行了詳細分析。

2. 漏洞影響版本

  • Windows 7
  • Windows 8.1
  • Windows 10
  • Windows Server 2008
  • Windows Server 2012
  • Windows Server 2016
  • Windows Server 2019

3. 協議簡介

DHCP，動態主機配置協議，前身是BOOTP協議，是一個局域網的網絡協議。DHCP通常用于集中管理分配IP地址，使client動態地獲得IP地址、Gateway地址、DNS服務器地址等信息。DHCP客戶端和DHCP服務端的交互過程如下圖所示。

img

傳輸的DHCP協議報文需遵循以下格式：

img

DHCP包含許多類型的Option，每個Option由Type、Length和Data三個字段組成。

img

Type取值范圍1~255，部分Type類型如下圖所示。

img

DHCP服務在處理Vendor Specific 類型（Type=43）的Option結構存在安全漏洞。首先看下DHCP服務程序對Option的處理過程， ProcessMessage函數負責處理收到的DHCP報文，調用ExtractOptions函數處理DHCP的Option字段，傳入函數ExtractOptions的參數1（v7）為DHCP報文指針，參數3（*(unsigned int *)(v5 + 16)）對應指針偏移位置+16的數據，即Len字段。

img

……

img

img

img

ExtractOption函數如下所示。 v6 = (unsigned __int64)&a1[a3 - 1];指向報文末尾位置；v10=a1+240;指向報文中Option結構。在for循環中處理不同類型的Option結構，當type=43（Vendor Specific Information），傳入指針v10和指針v6作為參數，調用ParseVendorSpecific函數進行處理。

img

……

img

……

img

……

img

img

ParseVendorSpecific函數內部調用UncodeOption函數。UncodeOption函數參數a1指向option起始位置，a2指向報文的末尾位置。UncodeOption函數存在安全漏洞，下面結合POC和補丁比對進行分析。

4. 漏洞分析

構造一個DHCP Discovery報文，POC如下所示，POC包含兩個vendor_specific 類型的Option結構。vendor_specific1是合法的Option結構，Length取值0x0a等于Data的實際長度（0x0a），vendor_specific2是不合法的Option結構， Length取值0x0f大于Data的實際長度（0x0a）。

img

（1）DHCP服務器收到Discovery請求報文，對數據包進行處理。首先執行ExtractOptions處理Options，當處理vendor_specific類型的Option時，進入到ParseVendorSpecific進行處理。POC中構造一個合法的vendor_specific1，目的是為了繞過84~85行的校驗代碼，使程序順利執行到ParseVendorSpecific函數。

img

（2）ParseVendorSpecific調用UncodeOption函數。

  • 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循環結束。

  • 48行調用HeapAlloc分配堆內存，分配的內存大小v13=a。

  • 51~58行在for循環中依次將vendor_specific結構中的Data拷貝到分配的堆內存中。進入第一次循環時，v1指向vendor_specific1，v8指向末尾位置，滿足條件v1<v8，55行調用memcpy將vendor_specific1的Data字段拷貝到分配的堆內存，拷貝長度Length=a。進入第二次循環，v1指向vendor_specific2，v8指向末尾位置，仍然滿足條件v1<v8，再次調用memcpy將vendor_specific2的Data字段拷貝到分配的堆內存，拷貝長度Length=0xf。由于分配的堆內存大小只有a個字節，而拷貝的總長度=0x0a+0x0f，從而導致堆溢出。

img

5. 補丁比對

補丁后的版本添加了對Length字段的有效性判斷。

img

6. 安全建議

及時安裝安全補丁：https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0626

啟明星辰積極防御實驗室（ADLab）

ADLab成立于1999年，是中國安全行業最早成立的攻防技術研究實驗室之一，微軟MAPP計劃核心成員。截止目前，ADLab通過CVE發布Windows、Linux、Unix等操作系統安全或軟件漏洞近400個，持續保持國際網絡安全領域一流水準。實驗室研究方向涵蓋操作系統與應用系統安全研究、移動智能終端安全研究、物聯網智能設備安全研究、Web安全研究、工控系統安全研究、云安全研究。研究成果應用于產品核心技術研究、國家重點科技項目攻關、專業安全服務等。

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/819/