微軟Windows系統嚴重漏洞分析

近期，微軟發布的安全補丁中修復了一個正被黑客在野利用的Windows內核提權漏洞。該漏洞主要影響早期Windows系統版本,無法在Windows 11上觸發。這類漏洞由來已久,本文將探討在當前安全防護不斷加強的背景下,攻擊者如何繼續利用此類漏洞。

本次分析基於Windows Server 2016環境完成。

漏洞背景

這是一個零日漏洞,指尚未公開且未修復的系統漏洞。黑客可以在用戶毫無察覺的情況下利用零日漏洞發動攻擊,具有極大破壞性。

本次發現的零日漏洞存在於Windows系統內核層面,黑客可通過該漏洞獲取Windows的完整控制權。這可能導致用戶隱私泄露、系統崩潰、數據丟失、財務損失等嚴重後果。從Web3角度看,用戶的私鑰可能被盜取,數字資產面臨被轉移的風險。更大範圍來說,這個漏洞甚至可能影響到基於Web2基礎設施運行的整個Web3生態。

漏洞分析

分析補丁代碼,我們發現問題出在一個對象的引用計數被多次處理。查看早期win32k源碼注釋,可以了解到以前的代碼只鎖定了窗口對象,而沒有鎖定窗口對象中的菜單對象,這可能導致菜單對象被錯誤引用。

進一步分析發現,傳入xxxEnableMenuItem()函數的菜單通常已在上層函數中被鎖定,那麼這裏究竟要保護哪個菜單對象?經研究,xxxEnableMenuItem中的MenuItemState函數返回的菜單有兩種可能:窗口的主菜單,或菜單的子菜單(甚至子子菜單)。

漏洞利用

爲驗證漏洞,我們構造了一個特殊的四層菜單結構,並設置了一些特定條件:

1. 最底層菜單D的ID必須爲系統菜單類型,如關閉菜單(0xf060)
2. 頂層菜單A也必須是系統菜單,但需刪除其中的0xf060菜單項
3. 刪除菜單C在菜單B中的引用
4. 菜單B的存在似乎對菜單C的釋放有影響

觸發漏洞時,在xxxRedrawTitle返回用戶層時刪除菜單C和B的關聯,成功釋放菜單C。當內核中xxxEnableMenuItem函數返回到xxxRedrawTitle時,即將引用的菜單C對象已失效。

漏洞利用分析

在設計漏洞利用方案時,我們主要考慮了兩個方向:

1. 執行shellcode:參考早期CVE-2017-0263和CVE-2016-0167的方法。但在高版本Windows中,shellcode執行入口點和SMEP等安全機制可能存在障礙。

2. 利用讀寫原語修改token地址:這種方法具有較好的通用性。關鍵是分析如何在UAF內存重用時首次控制cbwndextra爲特大值。

我們將漏洞利用分爲兩步:控制cbwndextra值,以及實現穩定的讀寫原語。

首次數據寫入

系統錯誤使用被控制內存的窗口對象數據主要發生在xxxEnableMenuItem函數的MNGetPopupFromMenu()和xxxMNUpdateShownMenu()中。我們利用窗口類WNDClass的窗口名稱對象佔用釋放的菜單對象內存。

關鍵是找到一個可被任意寫入的地址結構,哪怕只有一個字節。我們最終選擇了xxxRedrawWindow函數中的方案,通過AND 2操作寫入HWNDClass的cb-extra。

內存布局

我們設計了連續三個0x250字節HWND對象的內存布局,釋放中間對象並用0x250字節HWNDClass對象佔用。前一HWND對象尾部數據用於通過xxxRedrawWindow檢驗,後一HWND對象的菜單和HWNDClass對象用於最終讀寫原語。

我們盡量使窗口對象和HWNDClass對象大小一致,並通過泄露的內核句柄地址精確判斷對象排列是否符合預期。

讀寫原語

任意讀原語使用GetMenuBarInfo(),任意寫原語使用SetClassLongPtr()。除TOKEN寫入外,其他寫入都利用第一個窗口對象的class對象進行偏移寫入。

總結

1. 微軟正在用Rust重構win32k相關內核代碼,未來此類漏洞可能在新系統中被杜絕。

2. 該漏洞利用過程相對簡單,主要依賴桌面堆句柄地址泄露。如不徹底解決這個問題,老舊系統仍存在安全隱患。

3. 該漏洞的發現可能得益於更完善的代碼覆蓋率檢測。

4. 對於漏洞利用檢測,除關注漏洞觸發函數關鍵點外,還應關注對內存布局和窗口類額外數據異常偏移讀寫的檢測。