• 我的位置：
  • 首頁
  • -
  • 漏洞預警
  • -
  • 操作系統(tǒng)
  • -
    • Microsoft Windows condrv.sys內(nèi)存損壞漏洞分析
    • CNNVD編號：未知
    • 危害等級： 高危 
    • CVE編號：未知
    • 漏洞類型： 內(nèi)存損壞
    • 威脅類型：未知
    • 廠       商：未知
    • 漏洞來源：深信服
    • 發(fā)布時間：2021-01-22
    • 更新時間：2021-01-29

    漏洞簡介

    1、組件介紹

    Windows 10是Microsoft生產(chǎn)的一系列個人計算機操作系統(tǒng)，是Windows NT系列操作系統(tǒng)的一部分。它于2015年7月29日發(fā)布。Windows 10持續(xù)不斷地發(fā)布新版本，用戶無需支付額外費用。截至2017年11月，該操作系統(tǒng)在超過6億臺設備上運行。

    2、漏洞描述

    近日，深信服安全團隊監(jiān)測到一則Windows 10 condrv.sys存在內(nèi)存損壞漏洞的信息，漏洞等級：高危。該漏洞是由于Windows 10中condrv設備不正確的錯誤檢查導致異常，攻擊者可利用該漏洞，通過在瀏覽器的地址欄中打開特定路徑或構造惡意快捷方式進行釣魚攻擊，最終導致Windows 10藍屏崩潰。

    3、外部披露 

    Windows安全研究員 Jonas Lykkegaard 研究發(fā)現(xiàn)一條路徑，測試發(fā)現(xiàn)低權限用戶也可直接通過該路徑與設備進行交互，在Chrome瀏覽器地址欄中輸入該路徑時會導致Windows 10藍屏。


    連接到該設備時，開發(fā)人員應傳遞“attach”擴展屬性與該設備正確通信。由于不正確的錯誤檢查而嘗試不通過屬性而連接到路徑，引發(fā)異常，從而導致Windows 10藍屏崩潰。


    目前尚不確定此漏洞是否可用于遠程代碼執(zhí)行或提升特權，但確定可以造成拒絕服務攻擊。


    Lykkegaard與BleepingComputer共享了一個Windows 快捷方式文件（.url），其URL設置指向

    \\.\globalroot\device\condrv\kernelconnect

    下載文件后，Windows 10會嘗試從有問題的路徑中顯示URL文件的圖標，并自動使Windows 10崩潰。


    4、漏洞復現(xiàn)：

     瀏覽器觸發(fā)：chrome（或msedge）地址欄輸入：

    \\.\globalroot\device\condrv\kernelconnect

    觸發(fā)BSOD，可以看到發(fā)生錯誤的文件為condrv.sys


    查看crash文件

    查看函數(shù)調(diào)用棧（通過msedge觸發(fā)）：

    查看函數(shù)調(diào)用棧（通過msedge觸發(fā)）：

    ## 代碼觸發(fā)#include <Windows.h>#include<stdio.h>#define MAX_EXTS 12
    int main(){  HANDLE hDev[MAX_EXTS] = {0};  const wchar_t* Ext = L"\\KernelConnect";  //wchar_t* pDevName = (wchar_t*)LocalAlloc(LMEM_ZEROINIT, (MAX_PATH * 2) + 2);  wchar_t* pDevName = (wchar_t*)L"\\\\.\\globalroot\\device\\condrv\\kernelconnect";  HANDLE hDevXX = 0;  if (pDevName)   {    //wcscpy(pDevName, L"\\Device\\ConDrv");    //wcscat(pDevName, Ext);    wprintf(L"Opening: %s\r\n", pDevName);    int ret == OpenDevice(pDevName,&hDevXX);    if ((ret < 0) || (hDevXX == INVALID_HANDLE_VALUE))       printf("Can't open device, ERROR: %X\r\n", ret);    LocalFree(pDevName);    CloseHandle(hDevXX);   }}

    函數(shù)調(diào)用棧如下

    從這里可以看到，該漏洞的觸發(fā)與瀏覽器并無關系，初步判斷與設備的關閉有關。

    我們從 condrv!CdpDispatchCleanup 入手。


    漏洞公示

    觸發(fā)

    0: kd> ba e1 condrv!CdpDispatchCleanup0: kd> gBreakpoint 0 hitcondrv!CdpDispatchCleanup:fffff804`1d55af50 4883ec28        sub     rsp,28h

    通過動態(tài)調(diào)試condrv!CdpDispatchCleanup代碼的邏輯，發(fā)現(xiàn)在condrv!CdpDispatchCleanup+0x1f的位置發(fā)生了crash，這里讀取rcx位置處的值并賦值給rax，因為在前面的步驟中rcx的值為0，所以在讀取0地址處位置時發(fā)生了內(nèi)存錯誤，0內(nèi)存是不可讀的，造成BSOD。

    ida反編譯查看偽代碼，可以推斷出對v3進行引用的時候發(fā)生了錯誤，地址不可訪問。

    下面貼上在reactos查詢的_FILE_OBJECT的結(jié)構體，方便更加了解該漏洞的相關數(shù)據(jù)結(jié)構

     typedef struct _FILE_OBJECT {   CSHORT Type;   CSHORT Size;   PDEVICE_OBJECT DeviceObject;   PVPB Vpb;   PVOID FsContext;   PVOID FsContext2;   PSECTION_OBJECT_POINTERS SectionObjectPointer;   PVOID PrivateCacheMap;   NTSTATUS FinalStatus;   struct _FILE_OBJECT *RelatedFileObject;   BOOLEAN LockOperation;   BOOLEAN DeletePending;   BOOLEAN ReadAccess;   BOOLEAN WriteAccess;   BOOLEAN DeleteAccess;   BOOLEAN SharedRead;   BOOLEAN SharedWrite;   BOOLEAN SharedDelete;   ULONG Flags;   UNICODE_STRING FileName;   LARGE_INTEGER CurrentByteOffset;   volatile ULONG Waiters;   volatile ULONG Busy;   PVOID LastLock;   KEVENT Lock;   KEVENT Event;   volatile PIO_COMPLETION_CONTEXT CompletionContext;   KSPIN_LOCK IrpListLock;   LIST_ENTRY IrpList;   volatile PVOID FileObjectExtension; } FILE_OBJECT, *PFILE_OBJECT;

    跟蹤執(zhí)行流

    根據(jù)棧回溯，向上分析相關的執(zhí)行邏輯

    IofCallDriver，這里面通過將result返回到最終的condrv!CdpDispatchCleanup函數(shù)中，將參數(shù)中的Irp傳入到condrv!CdpDispatchCleanup函數(shù)中，我們繼續(xù)追蹤下前面的函數(shù)：

    IopCloseFile，在第97行進行IofCallDriver函數(shù)的調(diào)用，v16作為第二個參數(shù)傳入，逆向分析發(fā)現(xiàn)v16為irp對象，我們通過逆向condrv!CdpDispatchCleanup可知需要的得到Irp->Tail.Overlay.CurrentStackLocation->FileObject->fsContent，在這里將v17為v16->Tail.Overlay.CurrentStackLocation，而v17->FileObject = a2，所以最終的訪問fsContent時造成了BSOD，而這個fsContent正是a2!!

    觀察反匯編代碼，可以看到在IopCloseFile+0x14b的位置，將rbx的值傳遞給了FileObject，也就是說，某個Irp->Tail.Overlay.CurrentStackLocation對象的FileObject成員的地址為a2

    而根據(jù)在condrv!CdpDispatchCleanup中得到的信息，F(xiàn)ileObject+0x18位置處為FsContext成員，我們動態(tài)調(diào)試觀察下這個Irp對象的成員如何交由condrv!CdpDispatchCleanup處理并造成BSOD

    動態(tài)調(diào)試

    下面對剛剛的分析進行動態(tài)調(diào)試驗證：

    調(diào)試進入nt!IopCloseFile函數(shù)中，在偏移0x14b的位置處，對Irp->Tail.Overlay.CurrentStackLocation->FileObject進行賦值，此時Irp->Tail.Overlay.CurrentStackLocation->FileObject->fsContent為0。

    直接調(diào)試到終點，發(fā)現(xiàn)此時rcx已經(jīng)被賦值為0，當訪問該地址時將會造成內(nèi)存錯誤。

    根據(jù)上面的調(diào)試結(jié)果，猜測出現(xiàn)該漏洞可能的原因是IopCloseFile在關閉設備對象時并沒有檢查Irp->Tail.Overlay.CurrentStackLocation->FileObject->fsContent的值是否為空（實際上也根本沒必要檢查，因為對象已經(jīng)要被關閉了），而最終調(diào)用 condrv!CdpDispatchCleanup 函數(shù)時也沒有對fsContent進行檢查就調(diào)用，導致出現(xiàn)了內(nèi)存錯誤，猜測微軟如果會發(fā)布更新包的話應該會檢查condrv!CdpDispatchCleanup函數(shù)中fsContent的值是否為空。

    參考網(wǎng)站

    暫無

    受影響實體

    目前受影響的操作系統(tǒng)版本：Windows 10

    補丁

    1、官方修復建議

    當前官方暫未發(fā)布受影響版本的對應補丁，建議受影響的用戶及時關注更新官方的安全補丁（及時更新升級到最新版本）。鏈接如下：

    https://www.microsoft.com/zh-cn/software-download/windows10

    2、臨時修復建議

    建議不要點擊不明鏈接以及下載陌生壓縮文件。
    3、深信服解決方案

    【深信服下一代防火墻】預計2021年1月20日以后，可輕松防御此漏洞，建議部署深信服下一代防火墻的用戶更新至最新的安全防護規(guī)則，可輕松抵御此高危風險。

    【深信服云盾】預計2021年1月20日以后，從云端自動更新防護規(guī)則，云盾用戶無需操作，即可輕松、快速防御此高危風險。

    【深信服安全感知平臺】預計2021年1月20日以后，可檢測利用該漏洞的攻擊，實時告警，并可聯(lián)動【深信服下一代防火墻等產(chǎn)品】實現(xiàn)對攻擊者ip的封堵。

    【深信服安全運營服務】深信服云端安全專家提供7*24小時持續(xù)的安全運營服務。對存在漏洞的用戶，檢查并更新了客戶防護設備的策略，確保客戶防護設備可以防御此漏洞風險。