2022年1月下旬，一個新的微軟Windows特權升級漏洞(CVE-2022-21882)被發現，經分析，這是Win32k用戶模式回調函數xxxClientAllocWindowClassExtraBytes中的一個漏洞。早在2021年，微軟報告了一個非常類似的漏洞（CVE-2021-1732），并進行了修復。不過分析發現，CVE-2021-1732的補丁不足以阻止CVE-2022-21882。
Win32k背景信息
在Windows NT 4.0之前，Microsoft在名為Client-Server Runtime SubSystem（CSRSS.exe）的用戶模式進程中實現了Win32 API的GUI功能。然而，用戶模式和內核模式之間的上下文切換計算成本高昂，并且需要大量內存消耗。
為了消除這些問題并提高整個Windows操作系統的速度，微軟決定將Windows子系統(窗口管理器、GDI和圖形驅動程序)轉移到內核中。這種轉變始于1996年的Windows NT 4.0。
這一變化是通過一個名為Win32k.sys的內核模式驅動程序實現的，現在被稱為內核模式Windows子系統，Windows子系統的用戶模式組件仍然駐留在CSRSS中。
盡管遷移到內核大大減少了所需的消耗，但微軟不得不采用一些老辦法，例如在客戶端地址空間的用戶模式部分緩存管理數據結構。事實上，為了進一步避免上下文切換，一些管理結構在歷史上僅以用戶模式存儲。然而，為了消除內核地址泄漏，微軟已經開始實現使用這些結構的用戶模式和內核模式副本的方法，以防止內核地址存儲在用戶模式結構中。
此外，由于Win32k需要一種方法來訪問這些用戶模式結構，并支持一些現有的用戶模式功能，如窗口掛鉤，因此實現了用戶模式回調來促進這些任務。
用戶模式回調允許Win32k回調到用戶模式，并執行諸如調用應用程序定義的掛鉤、提供事件通知以及將數據復制到用戶模式或從用戶模式復制數據等任務。這意味著微軟在實現用戶模式回調和保持數據完整性方面面臨著巨大安全挑戰。
研究發現，在進行用戶模式回調之前，許多對象沒有被正確鎖定，這使得用戶模式代碼可以在用戶模式回調期間銷毀這些對象，從而導致釋放后使用（UAF）漏洞。盡管微軟已經解決了許多問題，但用戶模式回調在今天仍然被濫用。
Windows GUI API
在討論Win32k內部結構之前，我們將簡要介紹一個使用Win32 API創建和銷毀窗口的簡單C程序。這將使我們開始了解圖形窗口是如何以編程方式創建和操作的。它還允許我們檢查定義每個窗口及其菜單的底層結構。
如下圖所示，示例程序首先定義一個窗口類。進程必須先注冊一個窗口類，然后才能創建WNDCLASSEX結構中定義的窗口類型。首先，窗口類對象被聲明為WNDCLASSEX wcx={}，然后填充窗口類結構。
定義窗口類
窗口類的元素如下所示：
cbSize：此結構的大小（以字節為單位），將此成員設置為sizeof（WNDCLASSEX）。
style：窗口類樣式，它可以是類樣式的任意組合。
lpfnWndProc：指向處理類中發送到窗口的所有消息并定義窗口行為的函數的指針。通常，默認窗口過程至少用于某些消息。但是，自定義窗口過程通常用于創建獨特的窗口體驗。
cbClsExtra：在窗口類結構之后要分配的額外字節數，系統將字節初始化為零。
cbWndExtra：在窗口實例之后要分配的額外字節數。系統將字節初始化為零。不要將其與cbClsExtra混淆，后者對該窗口類的所有窗口都是通用的。該值通常為0，但如果不是0，則內存通常用于存儲跨窗口的非恒定數據；
hInstance：包含類的窗口過程的實例的句柄。標識注冊該類的應用程序或.DLL。在此處將hinstance參數分配給WinMain。
hIcon：類的句柄，LoadIcon(NULL, IDI_APPLICATION)加載默認圖標。
hCursor：類光標的句柄，LoadCursor(NULL, IDC_ARROW)加載默認光標。
hbrBackground：類背景筆刷的句柄，GetStockObject (WHITE_BRUSH)返回一個白色筆刷的句柄。返回值必須強制轉換，因為GetStockObject返回的是泛型對象。
lpszMenuName：指向一個以null結尾的字符串的指針，該字符串指定類菜單的資源名稱，該名稱顯示在資源文件中。如果不需要菜單欄，則此字段可以為NULL。
lpszClassName：用于標識此窗口類結構的類名。
hIconSm：小類圖標的句柄。
既然窗口類的屬性已經定義好了，我們需要使用RegisterClassEx()在應用程序中注冊，如下圖所示。如果失敗，RegisterClassEX()返回0。否則，它返回一個惟一標識所注冊類的類原子。注冊窗口類將定義該類及其關聯的結構成員到Windows。
正在注冊的窗口類
創建窗口
一旦注冊了窗口，我們就可以通過調用CreateWindowExA()來創建窗口類的實例，如下圖所示。
創建窗口的代碼
CreateWindowEX的參數如下圖所示。
CreateWindowExA函數原型
下面列出了每個參數的簡要說明：
dwExStyle：正在創建的窗口的擴展窗口樣式，在這種情況下，我們將其設置為WS_EX_LEFT的默認窗口常數，這為窗口提供了通用的左對齊屬性。
lpClassName：類名，取自調用RegisterClassEX時聲明的wcx.lpszClassName。
lpWindowName：窗口名稱。
dwStyle：所創建窗口的樣式，在本例中，我們使用WS_OVERLAPPEDWINDOW，它創建了一個頂層(父)窗口。
X：窗口的初始水平位置。對于重疊窗口或彈出窗口，x參數是以屏幕坐標表示的窗口左上角的初始x坐標。對于子窗口，x是窗口左上角相對于父窗口客戶區左上角的x坐標。如果x設置為CW_USEDEFAULT，系統將選擇窗口左上角的默認位置，并忽略y參數。
Y：與上述相同，但適用于Y坐標。
nWidth：窗口的寬度。
nHeight：窗口的高度。
hWndParent：正在創建的窗口的父窗口或所有者窗口的句柄。
hMenu：菜單的句柄，或指定子窗口標識符，具體取決于窗口樣式。對于重疊或彈出窗口，hMenu標識要與該窗口一起使用的菜單；如果要使用類菜單，則它可以為NULL。
hInstance：要與窗口關聯的模塊實例的句柄。
lpParam：傳遞給窗口的窗口過程的額外信息。如果沒有要傳輸的額外信息，則傳遞NULL。
一旦調用CreateWindowEx()創建了窗口，就在內部創建了窗口，也就是說，已經分配了內存并填充了其結構，但沒有顯示。為了顯示窗口，我們調用ShowWindow()函數。
ShowWindow()獲取從CreateWindowEXW()調用獲得的句柄和從WinMain()獲得的狀態變量nCmdShow。nCmdShow變量確定窗口在屏幕上的顯示方式，例如，它是正常的、最大化的還是最小化的。
ShowWindow()僅控制應用程序窗口的顯示方式。這包括諸如標題欄、菜單欄、窗口菜單、最小化按鈕等元素。客戶端區域是應用程序顯示數據的區域，例如在文本編輯器中輸入文本的區域。客戶端區域是通過調用UpdateWindow()函數繪制的。
如果將WS_VISIBLE窗口樣式指定為CreateWindowEXW()函數的dwStyle參數，則不需要調用ShowWindow()函數，Windows會為用戶調用它。同樣，如果不指定WS_VISIBLE樣式，也不調用ShowWindow()函數，窗口將對視圖保持隱藏狀態。
窗口消息和窗口過程
調用UpdateWindow()之后，窗口就完全可見并可以使用了。在為Windows編寫更簡單的控制臺應用程序時，該應用程序會根據控制臺中的用戶輸入進行顯式函數調用。
在窗口應用程序中，用戶通常可以通過輸入文本、點擊按鈕和菜單或僅僅通過移動鼠標來與應用程序交互。這些操作中的每一個都有自己的特殊功能。為了實現這一點，微軟實現了一個事件驅動系統，該系統將用戶輸入（如鍵盤、鼠標或觸摸）的消息中繼到每個應用程序中的各個窗口。這些消息由每個窗口內的函數處理，稱為窗口過程。
Windows為每個線程維護一個消息隊列，該隊列將中繼任何影響窗口狀態的用戶輸入事件。然后，Windows將這些事件轉換為消息，并將它們放入消息隊列。應用程序通過執行類似于下面中的代碼來處理這些消息。
窗口消息隊列循環
GetMessage()函數用于從消息隊列中檢索下一條消息。MSG參數是一個結構，它包含所分配的窗口過程正確處理消息所需的消息信息。
MSG結構的成員中包括其窗口過程接收消息的窗口的句柄（hwnd），以及包含標識符的消息，該標識符確定對窗口過程的請求內容。例如，如果消息包含一個WM_PAINT消息，它會告訴窗口過程窗口的工作區已更改，必須重新繪制。
TranslateMessage()函數可將虛擬密鑰消息轉換為字符消息，但這對于當前的討論并不重要。DispatchMessage()將消息發送到由msg結構中的窗口句柄標識的窗口，由該窗口類定義的窗口過程處理。
到目前為止，通過執行以下操作，示例代碼已經完成了定義窗口類：
注冊窗口；
創建由窗口類定義的窗口實例；
在屏幕上顯示窗口；
進入消息循環；
窗口過程決定了顯示什么以及如何響應用戶輸入。Windows提供了一個默認的窗口過程來處理應用程序未處理的任何窗口消息，并且它為任何窗口正常運行提供了最基本的功能。
窗口過程是定義窗口的所有功能的地方，且它們可能會非常復雜。不過，我們目前只對Microsoft的默認窗口過程DefWindowProc()感興趣。
窗口結構
如上所述，Windows現在通過Win32k.sys在內核中管理GUI對象，如菜單、窗口等。當創建窗口對象時，會在稱為tagWND的數據結構中跟蹤其屬性。
不過，微軟刪除了許多Win32k調試符號，這使得獲得這些結構的透明度變得更加困難。基于一些逆向工程，下圖顯示了Windows 10版本21H1中的結構。
標記WND父結構
在調用xxxCreateWindowEx期間查看HMAllocObject，其中發生了結構的分配，我們可以確認該結構的大小為0x150（336）字節。
在調用HMAllocObject之前的WinDbg輸出如下圖所示。你可以看到第四個參數，它表示分配大小，存儲在r9寄存器中，等于0x150。
WinDbg輸出顯示HMAllocObject的輸入參數
tagWND結構在線程環境塊(TEB)的Win32ClientInfo條目中被引用，為了防止內核模式地址泄露，它已被刪除了。
內核tagWND結構中的第一個條目是窗口句柄。在內核中，每個窗口都有一個與之相關聯的代表性tagWND結構。
在分析CVE-2022-21882期間，此結構將很重要，但現在，我們將重點關注偏移量0x28。我將其標記為*pWND，因為微軟不再提供符號。此外，微軟不再為這個結構提供名稱，在過去它被稱為state或WW。據微軟稱，這些名稱已被棄用，不再在內部使用。要知道它是tagWND數據的用戶模式版本，不包括內核地址，且它的結構與其父tagWND結構不同。這個子結構既存在于內核中，也存在于用戶模式中。這就是Windows管理數據的方式，以避免泄露內核地址，因為任何用戶模式應用程序都將使用位于用戶模式桌面堆上的tagWND結構的副本，因此將無法看到任何內核模式地址。
接下來繼續將子結構稱為tagWND結構，不過，它的結構與上面的父tagWND結構不同，但在其他研究中仍然通常稱為tagWND。
子標簽WND結構如下圖所示，通過逆向工程確定了元素及其偏移量。
在關于創建窗口的部分中討論的WNDCLASSEX結構的許多元素可以在tagWND結構中看到。因此，很明顯，當創建窗口時，通過WNDCLASSEX結構分配的屬性被傳遞給內核并存儲在tagWND結構中。然后將屬性傳播到內核和用戶模式桌面堆中的用戶副本。
tagWND結構的用戶模式安全副本
下面兩個圖分別顯示了父tagWND和用戶模式安全tagWND結構的內核副本。
父tagWND結構的內存轉儲
上圖是父tagWND，你可以看到句柄(偏移量0x00)與下面的復制tagWND的句柄相同。你還可以看到父結構具有內核地址，而用戶模式安全副本僅具有用戶模式地址。最后，注意父tagWND+0x28是指向子tagWND副本地址的指針。
子tagWND結構的內存轉儲
有幾種方法可以泄露窗口對象的內核模式地址，Win32k中存儲由用戶模式代碼設置的屬性的所有對象（例如，窗口、菜單）通常被稱為用戶對象。
所有用戶對象（tagWND結構的用戶模式副本是眾多對象之一）都在通常稱為UserHandleTable的每個會話句柄表中進行索引。盡管tagWND結構并不總是用戶模式安全的副本，并且曾經包含內核地址。
過去，可以通過UserHandleTable用User32.dll中名為gSharedInfo的可導出結構來定位tagWND對象。從Windows 10版本1703起，這個方法將不再有用。由于微軟不斷努力消除內核地址泄露，他們已經從UserHandleTable中刪除了桌面堆中對象的內核地址。
窗口管理器使用位于User32.dll中的非導出函數HMValidateHandle驗證句柄。在Windows 10版本1803之前，窗口管理器返回內核模式指針，指向要驗證其句柄的對象，該指針通常用于泄露此地址。盡管內核地址泄漏已經被修復，但當我們稍后查看這兩個漏洞時，這種方法將非常重要。
從Windows 10版本1703開始，任何由SetWindowLong寫入的字節都不再寫入內核。這個修復有效地消除了這種創建任意寫入的技術。
確定感興趣的對象在內核中的位置，以繞過內核地址空間布局隨機化（KASLR）。因此，非常需要知道桌面堆的位置。從Windows 10 1607版本開始，微軟就開始添加緩解措施，試圖阻止漏洞編寫者在內核中定位桌面堆及其相關對象。這些緩解措施包括從UserHandleTable中刪除內核地址，如上所述，以及在每個進程的線程環境塊(TEB)中的Win32ClientInfo結構中刪除對桌面堆的內核指針引用。此外，HMValidateHandle現在為傳遞給它的任何對象句柄返回用戶模式（相對于內核模式）指針。
用戶模式回調
由于windows子系統主要位于windows內核中，而windows本身在用戶模式下運行，因此Win32k必須頻繁地從內核調用到用戶模式。用戶模式回調提供了一種機制來實現諸如應用程序定義的掛鉤、事件通知以及從用戶模式向內核復制/從內核復制數據等項目。
當進行用戶模式回調時，Win32k調用KeUserModeCallback，并使用它想要調用的用戶模式函數的關聯ApiNumber。ApiNumber是位于USER32 .dll (USER32!apfnDispatch)中的函數表的索引。在每個進程的User32.dll初始化期間，該表的地址被復制到進程環境塊(PEB) (PEB. kernelcallbacktable)。
在即將進行的漏洞分析中，我們將展示如何通過KernelCallback表鉤住用戶模式回調，并展示該表在WinDbg中的樣子。KeUserModeCallback的函數原型及其相關參數如下圖所示。
KeUserModeCallback函數原型
用戶模式回調輸入參數通過InputBuffer傳遞，而回調函數的輸出在OutputBuffer中返回。在調用系統調用時，ntdll!KiSystemService或ntdll!KiFastCallEntry在內核線程堆棧上存儲一個trap幀(TRAP_FRAME)，以保存當前線程上下文，并在返回到用戶模式時啟用寄存器恢復。
為了在用戶模式回調中轉換回用戶模式，KeUserModeCallback首先使用線程對象持有的trap幀信息將InputBuffer復制到用戶模式堆棧。然后創建一個新的trap幀，EIP設置為ntdll!KiUserCallbackDispatcher，替換線程對象的TrapFrame指針，最后調用ntdll!KiServiceExit將執行返回給用戶模式回調調度程序。
KiUserCallbackDispatcher函數原型
一旦用戶模式回調完成，就會調用NtCallbackReturn以恢復內核中的執行。此函數將回調的結果復制回原始內核堆棧，并恢復保存在kernel_stack_CONTROL結構中的trap幀（PreviousTrapFrame）和內核堆棧。在跳轉到它先前停止的位置之前(在ntdll!KiCallUserMode中)，內核回調堆棧被刪除。
函數原型
如果Win32k在調用用戶模式回調時沒有釋放資源，并且該用戶模式回調允許應用程序凍結GUI子系統，則Win32k將無法在GUI子系統被凍結時執行其他任務。因此，Win32k總是在調用用戶模式回調時釋放資源。在從用戶模式回調返回時，Win32k必須確保引用的對象仍然處于不受信任的狀態。在未執行適當檢查或對象鎖定的情況下對此類對象進行操作可能也確實會造成安全漏洞。事實上，研究人員確定了這些類型漏洞的多個實例。
總結
本文介紹了如何使用Win32 API創建GUI對象，如窗口和菜單，還介紹了用于管理這些對象的用戶模式和內核模式數據結構。
翻譯自：https://unit42.paloaltonetworks.com/win32k-analysis-part-1/
昨天，我坐在咖啡店，在我的Windows電腦上安裝了兩個Linux發行版。不是虛擬機，也不是雙系統，不需要查找下載頁面和解壓縮安裝程序文件的路徑。 相反，我去了Windows Store，搜索了Linux，選了我想要的發行版，然后點擊了安裝。 一旦下載完畢，我需要做的就是打開終端窗口并添加用戶名和密碼。曾經的不可思議，現在一切都是可能的。
因為我正在運行即將推出的Windows 10 Fall Creators Update的最新預覽版本，它為Windows子系統Linux（WSL）添加了新功能。 在Windows 10周年紀念版更新版本（1609版）中推出，并在最近發布的Windows 10創作者更新（版本1703）中進行了顯著更新，WSL是微軟對“如何讓程序員再次使用Windows”的回答。
微軟如何讓程序員選擇Windows？
“如何讓程序員再次使用Windows？”的答案很簡單：站到程序員的位置上。
但是讓Windows實現答案并不簡單。程序員在MacOS和Linux上，使用命令行工具在云中的Linux服務器上工作。他們已經擁有與Docker，GitHub，Jenkins，Ansible，Chef和TravisCI等服務合作的工具鏈，應用程序和腳本。那么如何將這些程序員帶到Windows上呢？
第一步是以無縫的方式將Unix帶到熟悉的Windows桌面。MacOS具有Unix用戶的內在優勢，因為它基于BSD Unix的微內核實現，通過每個Mac上的終端應用程序訪問。
但是，Windows本身是NT內核，也不必要必須構建熟悉的工具的新版本，然后重新編譯成Windows可運行的版本，為什么不直接在Windows上運行Linux二進制文件呢？使用Project Astoria，為Windows Phone和Windows 10提供已取消的Android兼容性層，Microsoft可以提供一個新的子操作系統，將Linux系統調用轉換為Windows，允許代碼運行而無需任何更改。
與Ubuntu合作的初始版本提供了一個運行在Windows熟悉的終端中的Bash shell（由cmd和PowerShell使用）。為Windows內部人員構建的第一個測試，毫不奇怪，還很有限，但隨著Windows 10周年更新接近發布，他們進行了快速改進，允許復雜的控制臺應用程序運行，支持Ubuntu的apt-get安裝程序，以快速訪問工具庫和服務。通過創作者更新，Microsoft和Canonical能夠將WSL移動到Ubuntu最新的16.04長期支持版本。
WSL：Linux控制臺中的Linux二進制文件
從技術上講，WSL僅適用于控制臺應用程序，可為開發人員提供外殼支持，并遠程訪問在內部和公共云中運行的Linux服務器。用戶已經安裝并運行基于X的GUI應用程序，使用Windows X服務器為WSL帶來完整的Linux桌面體驗。
使用任何WSL就像使用本機Linux。你可以訪問一個shell，并通過命令行，安裝應用程序就像使用Ubuntu上的apt-get或Suse上的yast andzypper一樣簡單。當Fedora進入Windows時，程序員將使用yum。
早期的WSL構建在運行某些應用程序時遇到問題，因為不支持密鑰依賴關系。但是從Windows 10周年紀念更新版本開始，它已經很簡單了，現在甚至支持像Docker這樣復雜的軟件包安裝和運行。
程序員可通過WSL獲得需要的工具，在PC上進行跨平臺開發和管理。
今年晚些時候，隨著本地Linux容器來到Windows Server，WSL將成為企業系統工具集的關鍵組件之一。（Windows Server上的WSL將不支持大型Linux工作負載或服務器，但它將為程序員提供托管的Linux容器的直接管理連接，支持現有的管理腳本和工具。）
如何整合Linux和Windows工具鏈？
程序員可以使用WSL默認用戶從Windows命令行調用Linux二進制文件，可以從Bash調用Windows二進制文件（并且可以從Visual Studio代碼中的終端訪問Bash，程序員可測試Unix代碼，而不用離開開發工具，不用離開Windows）。
提示：WSL將Windows目錄視為掛載文件系統，因此可能需要將鏈接設置為常用文件或將Windows程序文件目錄添加到Bash路徑。
程序員應該都很高興看到Visual Studio code支持WSL的工具。如果微軟要將其平臺帶入到程序員中，其工具就需要將Windows和Linux的最佳方式融合在一起。很容易想象將來發布的完整的Visual Studio托管Linux終端，并呼吁在WSL中運行的服務上的webhooks和其他API。
WSL正在擴展Windows運行Linux發行版
現有的Ubuntu版本：OpenSuse和Suse Enterprise Server。這兩個Suse版本都在Windows Store中，可供內部人員使用。
隨著Suse，Fedora加入WSL，程序員可以使用Linux工具、服務和熟悉的工作方式，將腳本和二進制文件從現有工具鏈轉移到Windows PC。WSL甚至可以同時托管幾個Linux任務，每個都在一個單獨的終端中。
支持許多不同的Linux發行版很有意義。在過去幾年中，不同的供應商和團隊專注于不同的用例，從同一虛擬套件中構建不同的平臺。像Fedora和Ubuntu這樣的舊版本是非常通用的操作系統，從開發人員的角度來看，使用它們是有意義的。
程序員不妨盡情想象，如果將來WSL支持更專門的版本，就像容器集中的CoreOS，豈不是很有趣？