Microsoft Windows condrv.sys內(nèi)存損壞漏洞分析
  • CNNVD編號(hào)：未知
  • 危害等級(jí)： 高危 
  • CVE編號(hào)：未知
  • 漏洞類型： 內(nèi)存損壞
  • 威脅類型：未知
  • 廠       商：未知
  • 漏洞來(lái)源：深信服
  • 發(fā)布時(shí)間：2021-01-22
  • 更新時(shí)間：2021-01-29

漏洞簡(jiǎn)介

1、組件介紹

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

2、漏洞描述

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

3、外部披露 

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


連接到該設(shè)備時(shí)，開(kāi)發(fā)人員應(yīng)傳遞“attach”擴(kuò)展屬性與該設(shè)備正確通信。由于不正確的錯(cuò)誤檢查而嘗試不通過(guò)屬性而連接到路徑，引發(fā)異常，從而導(dǎo)致Windows 10藍(lán)屏崩潰。


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


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

\\.\globalroot\device\condrv\kernelconnect

下載文件后，Windows 10會(huì)嘗試從有問(wèn)題的路徑中顯示URL文件的圖標(biāo)，并自動(dòng)使Windows 10崩潰。


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

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

\\.\globalroot\device\condrv\kernelconnect

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


查看crash文件

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

查看函數(shù)調(diào)用棧（通過(guò)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ā)與瀏覽器并無(wú)關(guān)系，初步判斷與設(shè)備的關(guān)閉有關(guān)。

我們從 condrv!CdpDispatchCleanup 入手。


漏洞公示

觸發(fā)

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

通過(guò)動(dòng)態(tài)調(diào)試condrv!CdpDispatchCleanup代碼的邏輯，發(fā)現(xiàn)在condrv!CdpDispatchCleanup+0x1f的位置發(fā)生了crash，這里讀取rcx位置處的值并賦值給rax，因?yàn)樵谇懊娴牟襟E中rcx的值為0，所以在讀取0地址處位置時(shí)發(fā)生了內(nèi)存錯(cuò)誤，0內(nèi)存是不可讀的，造成BSOD。

ida反編譯查看偽代碼，可以推斷出對(duì)v3進(jìn)行引用的時(shí)候發(fā)生了錯(cuò)誤，地址不可訪問(wèn)。

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

 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ù)棧回溯，向上分析相關(guān)的執(zhí)行邏輯

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

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

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

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

動(dòng)態(tài)調(diào)試

下面對(duì)剛剛的分析進(jìn)行動(dòng)態(tài)調(diào)試驗(yàn)證：

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

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

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

參考網(wǎng)站

暫無(wú)

受影響實(shí)體

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

補(bǔ)丁

1、官方修復(fù)建議

當(dāng)前官方暫未發(fā)布受影響版本的對(duì)應(yīng)補(bǔ)丁，建議受影響的用戶及時(shí)關(guān)注更新官方的安全補(bǔ)?。皶r(shí)更新升級(jí)到最新版本）。鏈接如下：

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

2、臨時(shí)修復(fù)建議

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

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

【深信服云盾】預(yù)計(jì)2021年1月20日以后，從云端自動(dòng)更新防護(hù)規(guī)則，云盾用戶無(wú)需操作，即可輕松、快速防御此高危風(fēng)險(xiǎn)。

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

【深信服安全運(yùn)營(yíng)服務(wù)】深信服云端安全專家提供7*24小時(shí)持續(xù)的安全運(yùn)營(yíng)服務(wù)。對(duì)存在漏洞的用戶，檢查并更新了客戶防護(hù)設(shè)備的策略，確?？蛻舴雷o(hù)設(shè)備可以防御此漏洞風(fēng)險(xiǎn)。