CVE-2021-33739 EOP漏洞分析

背景

??CVE-2021-33739是一個UAF漏洞，成因是由于在物件CInteractionTrackerBindingManagerMarshaler與物件CInteractionTrackerMarshaler雙向系結的前提下，再對雙方系結進行解綁，CInteractionTrackerMarshaler指向前者的指標雖被清除，但CInteractionTrackerBindingManagerMarshaler中指向CInteractionTrackerMarshaler的指標仍然存在，之后釋放CInteractionTrackerMarshaler物件，CInteractionTrackerBindingManagerMarshaler中的指標仍然指向被free的內核地址，從而導致UAF漏洞，

分析

??首先創建一個CInteractionTrackerBindingManagerMarshaler（id=1）和兩個CInteractionTrackerMarshaler物件資源（id=2、3），創建方式是利用用戶態win32u.dll模塊的匯出函式NtDCompositionProcessChannelBatchBuffer，通過和信道關聯的緩沖區pMappedAddress指定創建資源型別（ResourceType）和指令（nCmdCreateResource），在內核中創建指定id的相應資源，信道通過呼叫函式NtDCompositionCreateChannel創建，

??系統呼叫NtDCompositionProcessChannelBatchBuffer支持的指令如下，每個指令都有自己不同的緩沖區大小和格式，當前漏洞涉及到了其中的nCmdCreateResource（1）、nCmdReleaseResource（3）、nCmdSetResourceBufferProperty（12），

??nCmdCreateResource指令對應的緩沖區（pMappedAddress）格式和大小：

??呼叫后，執行至win32kbase!DirectComposition::CApplicationChannel::CreateResource，再根據isSharedResource引數執行CreateInternalSharedResource或CreateInternalResource，漏洞在CreateInternalResource中，

??win32kbase!DirectComposition::CApplicationChannel::CreateInternalResource根據Resource Type創建不同資源物件，

??物件全部創建成功后，指定處理指令nCmdSetResourceBufferProperty，將兩種不同型別指令進行系結，緩沖區格式如下：

??該指令將執行至CInteractionTrackerBindingManagerMarshaler::SetBufferProperty，該函式位于CInteractionTrackerBindingManagerMarshaler物件偏移0xA8處，

??如果CInteractionTrackerBindingManagerMarshaler沒有系結物件，且nCmdSetResourceBufferProperty指令對應pMappedAddress中由用戶指定的EntryID（Data偏移+0x8處）不為0，則將TrackerManager（CInteractionTrackerBindingManagerMarshaler）和兩個Tracker（CInteractionTrackerMarshaler）互相系結，

??由TrackerManager向Tracker的系結方式是創建一個TrackerEntry結構，指標放在TrackerManager偏移+0x38處，TrackerEntry結構大小為32位元組：
pTracker1(QWORD) | pTracker2(QWORD) | entry_id(QWORD) | 1(QWORD)
??系結后的TrackerManager：

??而從Tracker向TrackerManager的系結由SetBindingManagerMarshaler函式實作，該函式先判斷Tracker偏移0x190處指標是否指向待系結的TrackerManager，在確認未系結的條件下先將TrackerManager偏移0x14處的資源參考值加1，接著在Tracker物件偏移0x190處寫入TrackerManager物件指標值，實作系結，

??指令完成后，再次執行上一步nCmdSetResourceBufferProperty指令操作，不過變動是需要指定EntryID為0（szBuff+0x8），

??再次執行至SetBufferProperty，此時流程將進入另一分支，因為此時在TrackerManager物件偏移0x50處值由0變成1，應該和TrackerEntry關聯，之后又根據用戶給的Tracker1和Tracker2二者ID從channel物件關聯的pMappedAddress中取出各自對應下標的指標值，和TrackerManager中TrackerEntry系結的兩個Tracker ID進行比較，相同則繼續，不同則跳轉至系結分支，

??順利執行下來，又對用戶指定的EntryID判斷為0的話，將呼叫RemoveBindingManagerReferenceFromTrackerIfNecessary，該函式將解除TrackerManager和Tracker的系結關系，然而漏洞就是出現在此處，因為RemoveBinding...函式只是將Tracker中的TrackerManager指標值置0，而TrackerManager中的TrackerEntry仍然存在，

??之后釋放（nCmdReleaseResource）兩個Tracker資源，再呼叫NtDCompositionCommitChannel提交channel資料后將觸發BSOD，可以看到，最終是在呼叫CInteractionTrackerBindingManagerMarshaler::EmitBoundTrackerMarshalerUpdateCommands發生錯誤，

利用

目前公開的POC，是利用構造的Palette物件去占用被釋放的兩個Tracker的原本空間，之后再借助NtDCompositionCommitChannel觸發利用，

??每釋放一個Tracker，就緊接著通過大量創建Fake_Palette物件的方式去占用目標空間，為了能準確地實作占用，構造的Fake_Palette物件大小應和原本被釋放的Tracker物件大小一致，可以在之前的windbg中使用命令!pool中看到Tracker的size為0x1A0，

??在分析部分，可以知道最終是在CInteractionTrackerBindingManagerMarshaler::EmitBoundTrackerMarshalerUpdateCommands函式除觸發的BSOD，
??查看該函式，可以看到會呼叫 (*pTracker)+0x50 地址處的函式，應該是原本已釋放Tracker的虛表函式呼叫，

??通過構造Palette，可指定函式呼叫，POC中選用了nt! SeSetAccessStateGenericMapping，可將16位元組內容寫入可控地址，可用于替換_KTHREAD中的PreviousMode（1：usermode；0：kernelmode），內核中的完整性檢查是在previousmode為1前提下，意味著previousmode被覆寫為0可進行跟高權限操作，

??查看nt!SeSetAccessStateGenericMapping，其中rdx指向channel緩沖區的偏移0xB8處的16位元組，多次除錯后發現該位置前8位元組為一個不明指標值，后8位元組為0值，因此覆寫時，向后移動了9位元組，以保證0值覆寫previousmode欄位，

??POC代碼中似憾訓嘗試修改Token，但是rdx不可控，似乎沒起作用，
??另外在EmitBoundTrackerMarshalerUpdateCommands中，需要TrackerEntry的ID不為0方才能呼叫虛表中的函式，但是解綁Tracker2和Tracker3時，TrackerEntry被重新設定為了0，因此POC除了創建Tracker2和Tracker3，還需要創建第三個Tracker（Tracker4），在系結和釋放Tracker2和Tracker3且Fake_Palette成功占用二者原來空間后，再系結Tracker4和TrackerManager，指定TrackerEntry不為0，如POC中的0xffff，

??成功占用后的空間情況，可以看到都是大小為0x1A0的相同連續空間分布，

??PreviousMode覆寫前后：

??之后將shellcode注入winlogon.exe，啟動system權限的cmd.exe，

參考

https://www.anquanke.com/post/id/245427
https://www.zerodayinitiative.com/blog/2021/5/3/cve-2021-26900-privilege-escalation-via-a-use-after-free-vulnerability-in-win32k
https://github.com/Lagal1990/CVE-2021-33739-POC/blob/fbbba006a610f4f269c9aefdf060562d86459bf5/CVE-2021-26868 %26 CVE-2021-33739/exp/exp.cpp

標籤：其他

上一篇：企業必看｜如何挑選好用的PaaS平臺？一定注意這六點

下一篇：GAMP學習日志1—GAMP除錯