這篇文章給大家介紹win32k.sys中怎么實(shí)現(xiàn)漏洞挖掘，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。
成都創(chuàng)新互聯(lián)專注于企業(yè)營銷型網(wǎng)站、網(wǎng)站重做改版、孝昌網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5技術(shù)、成都商城網(wǎng)站開發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)公司、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為孝昌等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
4月1日，以色列安全研究員Gil Dabah在博客上發(fā)布了一篇關(guān)于win32k漏洞研究文章，描述了如何通過內(nèi)核對(duì)象的Destroy函數(shù)和win32k user-mode callback緩解措施的特性來尋找UAF漏洞的新思路。
為此，啟明星辰ADLab對(duì)win32k相關(guān)內(nèi)核機(jī)制進(jìn)行研究分析，并對(duì)這類漏洞的挖掘思路進(jìn)行詳細(xì)解讀分析。
由于設(shè)計(jì)原因，win32k驅(qū)動(dòng)需要處理很多用戶層的回調(diào)，這些回調(diào)給win32k模塊的安全帶來了非常大的隱患，并在過去10年時(shí)間貢獻(xiàn)了大量的漏洞。
為了便于漏洞描述，以如下偽代碼進(jìn)行舉例分析。
上述代碼執(zhí)行效果如下圖所示，用戶層執(zhí)行的某函數(shù)通過syscall傳入內(nèi)核層，當(dāng)內(nèi)核層代碼執(zhí)行到somecallback這一句時(shí)，用戶層可以在用戶定義的callback函數(shù)中獲得代碼執(zhí)行的機(jī)會(huì)，如果用戶在callback函數(shù)調(diào)用了DestroyWindow函數(shù)銷毀窗口p，內(nèi)核層的相應(yīng)銷毀代碼將會(huì)被執(zhí)行，p的相應(yīng)內(nèi)存被釋放，回調(diào)執(zhí)行完畢，NtUserSysCall函數(shù)繼續(xù)執(zhí)行，當(dāng)執(zhí)行到xxxSetWindowStyle(p)一句時(shí)，由于p的內(nèi)存已經(jīng)被釋放從而導(dǎo)致UAF漏洞的產(chǎn)生。
為了防止上述問題的產(chǎn)生，微軟在對(duì)象中引入了一個(gè)引用計(jì)數(shù)（對(duì)象+0x8處），對(duì)象分配時(shí)引用計(jì)數(shù)為1，當(dāng)執(zhí)行對(duì)象的Destroy函數(shù)時(shí)引用計(jì)數(shù)減1，當(dāng)引用計(jì)數(shù)為0時(shí)對(duì)象會(huì)被真正釋放。微軟通過鎖的概念為對(duì)象添加和減少引用計(jì)數(shù)，在win32k中為對(duì)象管理引用計(jì)數(shù)的鎖有兩種分別是臨時(shí)鎖（相應(yīng)函數(shù)為ThreadLock/ ThreadUnlock）和永久鎖（相應(yīng)函數(shù)為HMAssignmentLock/ HMAssignmentUnlock）。經(jīng)過加固之后代碼表現(xiàn)為如下形式：
通過上述代碼，可以保證即使callback被執(zhí)行，p在xxxSetWindowStyle函數(shù)執(zhí)行的時(shí)候也不會(huì)被釋放。
上一節(jié)提到了對(duì)象的引用計(jì)數(shù)，如果對(duì)象的引用計(jì)數(shù)為正，即使執(zhí)行對(duì)象的destroy函數(shù)，對(duì)象沒有真正被釋放，仍舊存留在內(nèi)存中，這種對(duì)象被微軟開發(fā)者稱為僵尸（Zombie）對(duì)象。一旦僵尸對(duì)象的引用計(jì)數(shù)減少到0它將會(huì)消失，但是在此之前它仍舊存在內(nèi)存中，只是用戶層無法訪問該對(duì)象。
同時(shí)為了防止僵尸對(duì)象繼續(xù)存留在內(nèi)存中，鎖的釋放函數(shù)（ThreadUnlock/ HMAssignmentUnlock）一般會(huì)包含對(duì)象的釋放環(huán)節(jié)。
對(duì)象的Destroy函數(shù)還有一個(gè)特性就是在釋放對(duì)象的同時(shí)，Destroy函數(shù)也會(huì)釋放對(duì)象的子資源，其過程可以簡要描述如下。
DestroyWindow在第一次調(diào)用時(shí)釋放子資源，一旦窗口不再被引用，句柄管理器就會(huì)再次完全銷毀它，一般情況下，第二次銷毀Destroy函數(shù)不會(huì)在去處理子資源，因?yàn)榈谝淮我呀?jīng)釋放了所有的子資源。
但是事情往往不是這么簡單，事實(shí)上即使是一個(gè)已經(jīng)調(diào)用過相應(yīng)Destroy函數(shù)釋放的僵尸對(duì)象，仍然有機(jī)會(huì)對(duì)其本身進(jìn)行一些更改（回調(diào)之后內(nèi)核代碼仍會(huì)對(duì)對(duì)象進(jìn)行一些操作），我們把這種情況叫做Zombie Reload，當(dāng)該僵尸對(duì)象由于引用計(jì)數(shù)為0而被真正釋放時(shí)，之前的更改操作將會(huì)給內(nèi)核帶來一些隱患。
對(duì)于如下代碼片段：
我們?cè)谟脩魧踊卣{(diào)中對(duì)pwnd執(zhí)行了Destroy函數(shù)，然后通過InternalSetTimer為之設(shè)置了一個(gè)計(jì)時(shí)器，當(dāng)ThreadUnlock將pwnd真正釋放的時(shí)候，計(jì)時(shí)器也將被釋放，那么接下來對(duì)計(jì)時(shí)器的操作將會(huì)導(dǎo)致UAF漏洞的產(chǎn)生。
上一節(jié)我們討論了對(duì)象的引用計(jì)數(shù)和鎖給對(duì)象帶來的新的安全隱患，但是真正的挑戰(zhàn)在于我們?nèi)绾未_定一段代碼中存在漏洞，關(guān)鍵點(diǎn)是確保在unlock函數(shù)中釋放的對(duì)象在運(yùn)行到有問題的代碼時(shí)其引用計(jì)數(shù)應(yīng)該為1，只有這樣我們才能在用戶層回調(diào)調(diào)用其Destroy函數(shù)，并通過unlock函數(shù)將這個(gè)對(duì)象真正釋放掉（上鎖的時(shí)候會(huì)做+1處理），這也是我們接下來需要討論的。下面我們通過一個(gè)案例來分析漏洞挖掘思路。
下圖是xxxMnOpenHierarchy函數(shù)的代碼片段。
圖中通過xxxCreateWindowEx可以獲得一個(gè)返回用戶層執(zhí)行callback函數(shù)的機(jī)會(huì)，xxxCreateWindowEx創(chuàng)建的窗口將作為父窗口*(structtagWND **)(**v3 + 8)（上圖紅框）的子窗口，如果我們可以通過ThreadUnlock釋放父窗口，那么子窗口v32也會(huì)被釋放，所以當(dāng)后續(xù)的safe_cast_fnid_to_PMENUWND函數(shù)將v32作為參數(shù)執(zhí)行時(shí)就會(huì)產(chǎn)生問題，值得注意的是通過回調(diào)釋放v32是行不通的，如果這樣xxxCreateWindowEx將會(huì)返回0，無法通過if判斷。
這里的問題就在于如何保證父窗口在ThreadUnlock函數(shù)執(zhí)行的時(shí)候引用計(jì)數(shù)為1，因?yàn)橐獔?zhí)行xxxMnOpenHierarchy函數(shù)需要將父窗口關(guān)聯(lián)到一個(gè)menu窗口上，此時(shí)父窗口和menu窗口將會(huì)被一個(gè)永久鎖鎖住，下面我們介紹如何繞過永久鎖。
首先我們創(chuàng)建了g_hMenuOwner和g_hNewOwner兩個(gè)窗口，其中g(shù)_hMenuOwner的菜單句柄為hMenu，它也是g_hNewOwner的所有者。
在上述創(chuàng)建過程中內(nèi)核通過LockPopuMenu函數(shù)分別為hMenu和g_hMenuOwner添加了永久鎖，為了達(dá)成釋放目的，這個(gè)永久鎖需要被繞過。
此時(shí)鎖和所有者的關(guān)系是這樣的：
接下來我們通過SetWindowsHookEx給窗口添加了WH_CBT鉤子，并讓窗口進(jìn)入消息循環(huán)中。
SendMessage操作為g_hMenuOwner添加一個(gè)臨時(shí)鎖，由于后續(xù)的所有攻擊都是在message的回調(diào)中進(jìn)行，所以對(duì)于g_hMenuOwner來說這個(gè)臨時(shí)鎖是無法釋放的，如果想要構(gòu)造一個(gè)漏洞利用環(huán)境首先需要用一些方法來繞過它。
現(xiàn)在的情況變成了下圖所示：
當(dāng)消息為HCBT_CREATEWND時(shí)，我們第一次到達(dá)xxxMNOpenHierarchy函數(shù)內(nèi)部的xxxCreateWindowEx。
這里可以通過定義關(guān)于HCBT_CREATEWND消息的處理得到執(zhí)行用戶層回調(diào)代碼的機(jī)會(huì)，這一步的主要目的是為了獲取Menu的Wnd。
當(dāng)接收到的消息為WM_ENTERIDLE時(shí)，我們?cè)诖翱诘南⒒卣{(diào)中通過PostMessage下發(fā)消息。
發(fā)送消息后，驅(qū)動(dòng)程序來到了xxxMNKeyDown函數(shù)內(nèi)部調(diào)用xxxSendMessage處。
通過WM_NEXTMENU消息的回調(diào)函數(shù)開始為LPARAM賦值，賦值操作是為了修改hMenu的Owner，這樣就可以將Owner的臨時(shí)鎖繞過。
此時(shí)內(nèi)核會(huì)接到銷毀menu的消息，通過用戶層的回調(diào)函數(shù)返回1阻止menu的銷毀。
xxxMNKeyDown函數(shù)通過UnlockPopupMenu將g_hMenuOwner身上的永久鎖被去掉。
取而代之的是g_hNewOwner加上了一個(gè)鎖，hMenu的Owner也從g_hMenuOwner變成了g_hNewOwner。
這時(shí)，鎖的關(guān)系變成了：
接下來程序第二次進(jìn)入到xxxMNOpenHierarchy函數(shù)并通過xxxSendMessage發(fā)送了消息。
此時(shí)通過設(shè)置WM_INITMENUPOPUP回調(diào)來獲得用戶層執(zhí)行的機(jī)會(huì)，WM_INITMENUPOPUP回調(diào)函數(shù)通過SetWindowsHookEx函數(shù)設(shè)置了一個(gè)新的hook，目的是為了在xxxMnOpenHierarchy函數(shù)創(chuàng)建子窗口的時(shí)候獲得用戶層執(zhí)行權(quán)限。
xxxMnOpenHierarchy函數(shù)繼續(xù)向下執(zhí)行，再次來到xxxCreateWindowEx處。
xxxCreateWindowEx調(diào)用了剛剛設(shè)置的回調(diào)函數(shù)childMenuHookProc。
在回調(diào)函數(shù)childMenuHookProc中，SendMessage發(fā)送了WM_NEXTMENU消息，通過該定義該消息的回調(diào)函數(shù)再次修改參數(shù)LPARAM，這是為了去掉g_hNewOwner身上的永久鎖。
Menu的Owner關(guān)系再次被改變，xxxMNKeyDown通過函數(shù)UnlockPopMenu去掉g_hNewOwner身上的永久鎖。并將這個(gè)鎖重新加在了g_hMenuOwner上。
這個(gè)時(shí)候，所有的鎖都已經(jīng)轉(zhuǎn)移到了g_hMenuOwner身上，而由于WH_CBT鉤子已經(jīng)被移除，menu將被棄用，g_hNewOwner將把新創(chuàng)建的窗口link到自己身上。這個(gè)時(shí)候情況變成了下面的樣子，g_hNewOwner身上已經(jīng)沒有需要繞過的鎖了。
接著childMenuHookProc通過SetWindowsHookEx函數(shù)又一次設(shè)置了回調(diào)函數(shù)并通過SetWindowLongPtr函數(shù)來調(diào)用它，回調(diào)函數(shù)銷毀了g_hNewOwner和xxxCreateWindowEx生成的新窗口。
xxxCreateWindowEx返回的值為ffff871b80239130，這就是xxxCreateWindowEx創(chuàng)建的子窗口。
接下來就可以通過ThreadUnlock來銷毀g_hNewOwner和其新創(chuàng)建的子窗口來得到一個(gè)UAF漏洞。
關(guān)于win32k.sys中怎么實(shí)現(xiàn)漏洞挖掘就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。
重慶分公司
重慶分公司
