2018年5月15日，ESET披露了其捕獲的PDF文檔樣本中的兩枚0-day漏洞。其中CVE-2018-4990為Adobe PDF閱讀器的代碼執(zhí)行漏洞，而CVE-2018-8120則是Windows操作系統(tǒng)Win32k的內(nèi)核提權(quán)漏洞，在獲取代碼執(zhí)行權(quán)限后通過內(nèi)核提權(quán)漏洞繞過Adobe PDF閱讀器的沙盒保護，實現(xiàn)任意代碼執(zhí)行。
360威脅情報中心在2018年5月25日已經(jīng)發(fā)布了《CVE-2018-4990 Adobe Reader 代碼執(zhí)行漏洞利用分析》（詳見參考資料[1]），而其中的內(nèi)核提權(quán)漏洞雖然已經(jīng)有公開的漏洞利用代碼，但僅僅是針對Windows 32位環(huán)境下的利用。由于大部分用戶機器已經(jīng)是64位操作系統(tǒng)，所以泄露的利用代碼危害有限。而在近日，有安全研究人員在GitHub上上傳了針對Windows 7 64位環(huán)境下CVE-2018-8120的漏洞利用代碼，經(jīng)驗證分析該漏洞利用代碼真實可用，考慮到漏洞相關(guān)的技術(shù)細(xì)節(jié)和驗證程序已經(jīng)公開，所以此漏洞接下來極有可能被利用來執(zhí)行大規(guī)模的攻擊。
漏洞分析
在本文中我們試圖通過公開的針對Windows 7 64位環(huán)境的內(nèi)核提權(quán)POC對漏洞原理和利用過程進(jìn)行詳細(xì)分析，并記錄整個分析過程。如有分析不當(dāng)之處敬請諒解。
分析環(huán)境：分析和調(diào)試的過程將在 Windows 7 x64 為基礎(chǔ)的環(huán)境中進(jìn)行
樣本來源：https://github.com/unamer/CVE-2018-8120
補丁比較
通過分析安全公告補丁程序可以知道，本次漏洞主要修復(fù)了系統(tǒng)中的win32k.sys內(nèi)核模塊文件，我們將64位Windows 7中的win32k.sys文件與未打補丁的文件進(jìn)行對比，發(fā)現(xiàn)本次針對 win32k.sys 的NtUserSetImeInfoEx函數(shù)做了以下修補：
可以明顯看到，補丁后的函數(shù)代碼在函數(shù)中增加了對窗口站對象tagWINDOWSTATION的成員域spklList的值是否為0的校驗，如果值為0則函數(shù)直接返回：
修補前的代碼：
修補后的代碼：
漏洞細(xì)節(jié)
根據(jù)以上對win32k.sys補丁前后改動的代碼對比可知，漏洞發(fā)生在函數(shù)NtUserSetImeInfoEx中。NtUserSetImeInfoEx 是操作系統(tǒng)提供的接口函數(shù)，用于將用戶進(jìn)程定義的輸入法擴展信息對象設(shè)置在與當(dāng)前進(jìn)程關(guān)聯(lián)的窗口站中。
窗口站
窗口站是和當(dāng)前進(jìn)程和會話(session)相關(guān)聯(lián)的一個內(nèi)核對象，它包含剪貼板(clipboard)、原子表、一個或多個桌面(desktop)對象等。窗口站 tagWINDOWSTATION 結(jié)構(gòu)體的定義如下：
NtUserSetImeInfoEx執(zhí)行過程分析
知道了補丁代碼修復(fù)的部分，我們來看下漏洞函數(shù)NtUserSetImeInfoEx的具體實現(xiàn)，此函數(shù)只有一個tagIMEINFOEX類型的參數(shù)：
整理后的漏洞函數(shù)執(zhí)行過程分析如下：
l 函數(shù)先獲取當(dāng)前的窗口站rpwinsta，并從rpwinsta指向的窗口站對象中獲取spklList成員
spklList 是指向關(guān)聯(lián)的鍵盤布局 tagKL 對象鏈表首節(jié)點的指針。鍵盤布局 tagKL 結(jié)構(gòu)體的定義如下：
l 然后函數(shù)從首節(jié)點開始遍歷鍵盤布局對象鏈表，直到節(jié)點對象的pklNext成員指回到首節(jié)點對象為止。函數(shù)判斷每個被遍歷的節(jié)點對象的hkl成員是否與參數(shù) ime_info_ex 指向的源輸入法擴展信息對象的hkl成員相等
l 接下來函數(shù)判斷目標(biāo)鍵盤布局對象的piiex成員是否為空，且成員變量 fLoadFlag 值是否為 FALSE。如果是，則把參數(shù) ime_info_ex 的數(shù)據(jù)拷貝到目標(biāo)鍵盤布局對象的piiex成員中
函數(shù)的實現(xiàn)過程比較簡單，在這里我們可以清楚的看到分析過程的第2步中導(dǎo)致漏洞產(chǎn)生的原因：
在遍歷鍵盤布局對象鏈表 spklList 的時候并沒有判斷 spklList 地址是否為 NULL，假設(shè)此時 spklList 為空的話，接下來對 spklList 訪問的時候?qū)⒂|發(fā)訪問異常，導(dǎo)致系統(tǒng) BSOD 的發(fā)生。
POC驗證
我們使用PowerShell腳本來測試驗證該漏洞，以下PowerShell腳本使用CreateWindowStation創(chuàng)建了一個窗口站，并調(diào)用函數(shù) SetProcessWindowStation 將創(chuàng)建的窗口站與當(dāng)前進(jìn)程關(guān)聯(lián)起來，然后打印出窗口站的HANDLE，最后調(diào)用 NtUserSetImeInfoEx 函數(shù)觸發(fā)漏洞
| 
