完美世界txt下载,我欲封天耳根小说零

我的位置：

Microsoft Windows condrv.sys內(nèi)存損壞漏洞分析

CNNVD編號：未知
危害等級：高危
CVE編號：未知
漏洞類型：內(nèi)存損壞
威脅類型：未知
廠商：未知
漏洞來源：深信服
發(fā)布時間：2021-01-22
更新時間：2021-01-29

漏洞簡介

1、組件介紹

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

2、漏洞描述

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

3、外部披露

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

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

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

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

\\.\globalroot\device\condrv\kernelconnect

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

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

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

\\.\globalroot\device\condrv\kernelconnect

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

查看crash文件

查看函數(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ā)與瀏覽器并無關(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

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

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

下面貼上在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，這里面通過將result返回到最終的condrv!CdpDispatchCleanup函數(shù)中，將參數(shù)中的Irp傳入到condrv!CdpDispatchCleanup函數(shù)中，我們繼續(xù)追蹤下前面的函數(shù)：

IopCloseFile，在第97行進(jìn)行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)試

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

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

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

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

參考網(wǎng)站

暫無

受影響實(shí)體

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

補(bǔ)丁

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

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

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

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

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

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

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

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

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

返回漏洞列表