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

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

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

(資料圖片僅供參考)

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

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

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

火絨安全

2023年8月15日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

此前BUG用戶反饋圖如下: