2023年8月11日，火絨安全收到大量用戶反饋：在同時(shí)安裝火絨與卡巴斯基的終端上，出現(xiàn)關(guān)機(jī)后反復(fù)重啟、無法正常進(jìn)入系統(tǒng)桌面的情況。經(jīng)過火絨安全工程師本地排查和測(cè)試確認(rèn)，此問題由卡巴斯基近期升級(jí)存在Bug導(dǎo)致。

升級(jí)后的卡巴斯基驅(qū)動(dòng)程序（klupd_klif_ 版本號(hào)：）會(huì)攔截火絨虛擬沙盒驅(qū)動(dòng)模塊正常的內(nèi)部程序邏輯，導(dǎo)致火絨獲取到錯(cuò)誤的物理地址數(shù)據(jù)，進(jìn)而發(fā)生系統(tǒng)異常。

此外，卡巴斯基的驅(qū)動(dòng)程序（klupd_klif_ 版本號(hào)：）還存在其他Bug，造成火絨產(chǎn)品其他功能也存在無法正常使用的情況。

(資料圖片僅供參考)

針對(duì)本次情況，火絨安全已與卡巴斯基反饋，目前還未得到有效回復(fù)。為保障用戶不受到卡巴斯基產(chǎn)品Bug的影響，火絨產(chǎn)品已采取臨時(shí)規(guī)避措施，但該調(diào)整會(huì)影響火絨查殺速率和查殺率，還請(qǐng)用戶注意。

未同時(shí)安裝火絨和卡巴斯基的用戶不會(huì)受到該調(diào)整影響。我們會(huì)繼續(xù)與卡巴斯基官方嘗試溝通以解決該問題。

另：今年4月卡巴斯基也曾因?yàn)镠OOK了火絨驅(qū)動(dòng)，影響到火絨產(chǎn)品查殺效率，該問題現(xiàn)已解決。

火絨安全

2023年8月15日

附文中所述卡巴斯基Bug的具體分析：

此次用戶系統(tǒng)大面積崩潰的關(guān)鍵原因是因?yàn)榭ò退够尿?qū)動(dòng)程序(klupd_klif_) HOOK了火絨驅(qū)動(dòng)()IAT里的MmGetPhysicalAddress函數(shù)導(dǎo)致的。如下圖：

在對(duì)卡巴斯基驅(qū)動(dòng)(klupd_klif_)進(jìn)行分析后發(fā)現(xiàn)，klupd_klif_會(huì)對(duì)火絨驅(qū)動(dòng)()進(jìn)行IRP HOOK和IAT HOOK，相關(guān)代碼如下：

安裝IAT HOOK相關(guān)代碼如下圖:

卡巴斯基驅(qū)動(dòng)會(huì)根據(jù)驅(qū)動(dòng)文件信息判斷是否需要進(jìn)行IAT HOOK，相關(guān)代碼如下圖：

如果驅(qū)動(dòng)IAT表內(nèi)存在以下函數(shù)就會(huì)被IAT HOOK，如下圖：

卡巴斯基驅(qū)動(dòng)(klupd_klif_) 對(duì)MmGetPhysicalAddress函數(shù)進(jìn)行IAT HOOK后的相關(guān)代碼如下圖：

在此能發(fā)現(xiàn)他會(huì)對(duì)參數(shù)一BaseAddress進(jìn)行判斷，相關(guān)代碼如下圖：

在上圖check_prot_physical_addr 函數(shù)里能發(fā)現(xiàn)有一組列表，當(dāng)被HOOK的驅(qū)動(dòng)程序想使用MmGetPhysicalAddress訪問某一地址時(shí)會(huì)拿BaseAddress和列表內(nèi)的數(shù)據(jù)進(jìn)行比較，判斷是否在列表的訪問范圍內(nèi)。如果是在訪問范圍內(nèi)會(huì)被拒絕。

通過windbg查看后得知此列表內(nèi)保存的地址是所有驅(qū)動(dòng)程序的開始地址和結(jié)束地址，如下圖：

此時(shí)不難看出，當(dāng)火絨驅(qū)動(dòng)()在被HOOK后調(diào)用 MmGetPhysicalAddress函數(shù)訪問自身程序地址時(shí)會(huì)被拒絕并返回0。

卡巴斯基的驅(qū)動(dòng)程序(klupd_klif_)在初始化時(shí)會(huì)保存所有驅(qū)動(dòng)程序的開始地址和結(jié)束地址，對(duì)于后續(xù)加載的驅(qū)動(dòng)程序會(huì)在PsSetLoadImageNotifyRoutine回調(diào)里也進(jìn)行保存。最終形成一個(gè)保護(hù)表，被IAT HOOK的驅(qū)動(dòng)里使用MmGetPhysicalAddress函數(shù)訪問被保護(hù)的驅(qū)動(dòng)程序的地址時(shí)，MmGetPhysicalAddress會(huì)返回物理地址0，后續(xù)火絨虛擬沙盒的虛擬化邏輯被破壞，進(jìn)而導(dǎo)致系統(tǒng)崩潰（即使火絨判斷返回的物理地址0，也會(huì)導(dǎo)致邏輯失敗進(jìn)而導(dǎo)致火絨反病毒引擎業(yè)務(wù)邏輯出現(xiàn)問題）。驅(qū)動(dòng)程序獲取自身鏡像或分配的內(nèi)存的物理地址屬于正常操作，而卡巴斯基的HOOK本質(zhì)上是破壞了第三方程序的業(yè)務(wù)邏輯，進(jìn)而導(dǎo)致第三方程序或系統(tǒng)出現(xiàn)異常。

火絨驅(qū)動(dòng)()使用 MmGetPhysicalAddress獲取火絨自身代碼頁、數(shù)據(jù)頁物理地址（實(shí)現(xiàn)虛擬沙盒相關(guān)邏輯使用）相關(guān)代碼如下圖：

同時(shí)卡巴斯基的驅(qū)動(dòng)程序(klupd_klif_)也會(huì)對(duì)火絨驅(qū)動(dòng)()設(shè)備對(duì)象“\\Device\\HR::Actmon“的IRP_MJ_DEVICE_CONTROL進(jìn)行HOOK，相關(guān)圖如下：

安裝IRP HOOK相關(guān)代碼如下圖:

卡巴斯基驅(qū)動(dòng)程序會(huì)根據(jù)字符串特征來判斷當(dāng)前驅(qū)動(dòng)是否需要安裝IRP HOOK，相關(guān)代碼如下圖：

最后獲取并保存設(shè)備對(duì)象“\\Device\\HR::ActMon“，相關(guān)代碼如下:

卡巴斯基的驅(qū)動(dòng)程序(klupd_klif_)安裝完IRP HOOK后會(huì)攔截修改火絨驅(qū)動(dòng)()相關(guān)功能，并且造成影響，相關(guān)代碼如下圖：

但這里依舊出現(xiàn)了BUG，”\\Device\\HR::ActMon”設(shè)備對(duì)象的IoControlCode值0x220044是屬于其他功能模塊的。但通過分析發(fā)現(xiàn)此處是在判斷文件路徑，而在火絨驅(qū)動(dòng)()設(shè)備對(duì)象” \\Device\\SysDiag::IOKit”里的0x220044是驅(qū)動(dòng)刪除文件功能。猜測(cè)他是想保護(hù)自身文件不被火絨劍刪除，但他卻判斷錯(cuò)了設(shè)備對(duì)象。判斷文件路徑相關(guān)代碼如下圖：

早在2023年4月卡巴斯基的IRP HOOK在代碼上存在bug、導(dǎo)致誤攔截了部分IOCODE消息、從而導(dǎo)致火絨部分功能失效。如下圖:

此前BUG用戶反饋圖如下: