殺毒軟件江湖：排斥與兼容的戰爭（上）

文/肖新光

需要指出的是，絕大多數情況下，反病毒產品之間的兼容性沖突問題，都是技術與協調的問題，有其工作機理上的必然性，并往往具有一定的不可避免性。

反病毒產品兼容沖突問題

反病毒產品從最開始的行命令掃描工具發展至今，已經形成了帶有文件、注冊表、內存等多種本地監控機制；瀏覽器、郵件客戶端等多種保護環節；以及整合了主機防火墻、入侵檢測機制、主動防御機制的綜合型產品。而其核心價值早在上世紀末，就已經從最開始的靜態的文件掃描檢測，變成實時化的主機防護。而實時化的防護推動了反病毒產品使用更多的服務、驅動等底層技術，運行于更接近系統內核的位置，這也為反病毒產品產生相互兼容性問題打下了伏筆。

隨著操作系統的復雜化，威脅的不斷離散化等影響，反病毒的監控保護點也日趨復雜，又加之反病毒廠商數量也在增加，而操作系統廠商并沒提供比較標準的技術規范，因此反病毒產品因互不兼容，發生共存沖突等問題越來越多，并間接影響了用戶對反病毒產品的信任。

目前己經發現并被報道過的兼容性問題包括：

造成系統崩潰和其他嚴重故障：從2 0 0 0年以來，根據公開報道，已經出現多起因反病毒產品之間相互沖突，而導致系統藍屏、死鎖等事件。

資源占用：反病毒掃描、監控和其他防護機制，都會帶來系統資源的占用。如病毒庫的內存展開對內存的資源使用，文件監控、定時掃描可能導致更多的I/O開銷、以及各種保護機制對C P U時間片的占用等等。這些對用戶操作有一定影響，如系統延遲、文件復制操作時間變長等等。而由于消息傳遞等機制，有可能在多種反病毒產品共存時，其對資源和時間的影響不是簡單的線性疊加，而是出現明顯的性能惡化。

失效：由于監控機制之間的沖突，多種監控機制共存時，有可能造成其中之一失效，或者部分機制雙雙失效的風險。上述后果，可以在兼容性測試中被復現。

相互誤報：由于廠商之間互信互通機制尚不夠通暢，以及少數惡意的“誤報構造”攻擊的存在，廠商之間出現相互誤報的情況，也時常發現。由于被報警為病毒而嚴重地影響了用戶對產品的信心，因此，各廠商對被誤報的問題也均比較敏感。

但需要指出的是，絕大多數情況下，反病毒產品之間的兼容性沖突問題，都是技術與協調的問題，有其工作機理上的必然性，并往往具有一定的不可避免性。相關問題多數并不是由商業競爭引發的，商業競爭也不是反病毒產品兼容沖突問題的本質。本文主要介紹當前反病毒產品沖突的主因，以澄清公眾誤解。

下文中涉及到安天實驗室和兄弟廠商產品所使用的技術點，均用于說明反病毒產品之間兼容性沖突的必然性，不是對實現水平進行評價。

主要沖突點詳細解析

實時監控、主動防御等技術的發展是一柄雙刃劍，一方面隨著監控點的增加能應對新的安全威脅，另一方面也使反病毒產品的穩定性遇到挑戰，測試難度普遍加大。反病毒產品自身的穩定性壓力都在呈現幾何級數增長，相互之間的兼容則變得更加困難。以下從文件監控、防火墻、瀏覽器防護、主動防御四個主要技術點，描述導致反病毒產品自身的穩定性下降、與操作系統之間和相互之間出現嚴重沖突問題的成因。

文件監控的潛在兼容性問題

文件監控是反病毒廠商普遍采用的技術手段，其主要機理是對文件的創建、讀取、關閉等行為進行監控觸發對文件病毒檢測，以阻斷病毒的執行和部分相關行為。

文件監控的實現方式主要有以下兩大類型：

1. A P I掛鉤。

根據鉤掛A P I的層次不同我們又可以分為 ：

(a) Ring3文件監控。

多采用inline hook的方式修改文件操作相關函數的前幾個字節，跳轉到自己的函數，然后對將要操作的文件和緩沖區進行檢測。

由于實現跳轉的方式有多種，所以不同軟件的實現策略有所不同，很難保證多個軟件共存時前一軟件修改后不影響到后一個軟件，而且很可能導致相關進程崩潰。

由于此類技術也多被惡意軟件使用，一些安全軟件不會在執行完自己的代碼后執行修改前的自己，而是采用從原始文件中讀取、分析、執行的方式，導致多個安全軟件同時監控一個API時，只有一個生效。

出于性能考慮，不傳遞給原API處理而采用自己實現的代碼完成該A P I的相應功能，那么也不會將相關信息傳遞給其他軟件。

部分軟件在執行完自己的函數后會把修改后的字節還原，然后調用原系統A P I完成功能后再次修改、掛鉤。兩個使用此實現的軟件同時工作則可能造成互相調用導致死鎖，程序沒有響應。

(b) Ring0文件監控。與ring3的情況類似，但是后果更加嚴重。

由于inline hook不同實現造成的不兼容性很可能導致系統API無法正常工作，導致系統藍屏。

例如：安天客戶端產品（A n t i yGhostbusters４.0）早期版本采用大量inlinehook，后因與其他產品嚴重沖突放棄；360安全衛士中inline hook有幾種不同實現方式共存的現象，并且與360安全瀏覽器有重合的監控點；

掛鉤之間相互調用，會導致死鎖，系統死機；

采用替換S S D T的方式，則只有自己的掛鉤有效，其他軟件的掛鉤均無效。

例如：360安全衛士等產品采用替換SSDT的方式，與其共存的安全軟件通過標準方法獲取的S S D T是無效的，導致其他安全軟件功能出現缺失；

V i s t a以后微軟對內核進行保護，部分對內核函數的修改會導致系統藍屏。

例如：多個產品在內測和對外版本都出現過對關鍵內核函數進行修改，但是并沒有仔細判斷版本，導致兼容性出現問題而使系統藍屏。

2. 文件過濾驅動

FileSystemFilterDrivers

FileSystemMinifilterDrivers

過濾驅動的本質依然是掛鉤，但微軟為了方便廠商調用，對其進行了封裝，屬于官方的技術。此類技術本身已經力求穩定與兼容，多數都提供了一定的兼容性保障。微軟自己的安全產品在驅動層面也多使用類似的方式。

但是在安全產品的實際應用中，多層監控逐層傳遞會造成效率的降低，一些廠商在實現時會繞過后續的過濾驅動，直接將I R P請求發給下一層驅動完成相關的功能，如表1和表2。

防火墻的潛在兼容性問題

目前反病毒產品普遍使用單機防火墻技術來過濾出入數據，應對來自網絡的威脅。

目前防火墻的實現方式包括：

在以WindowsXP為主的時期，多數防火墻選擇前三者中的某一種或者某兩種結合的方式。在實際應用的過程中，同樣存在多個共存無法同時生效的現象。其原因有：

1.過濾時出于效率考慮，直接將允許通過的包交給下層驅動處理，而不是后續的防火墻驅動。

2.由于NDIS和IP Filter比TDI更接近底層，前兩者實現的防火墻會對TDI層造成影響。

3.X P自帶的IPFilter存在誰先設置誰先生效的問題。安天盾防火墻與金山防火墻某版本同時使用該方式，如果同時安裝在用戶的機器中，則出現誰先啟動誰先生效的現象。

表1

?

表3 主流安全防護軟件監控點

WFP和Winsock Kernel是自Vista之后引入的方式，兼容性相對而言更好，只要實現得當，一般沒有兼容性的問題。特別是WFP 針對防火墻和IDS 類軟件做了設計上的考慮，兼容性問題得到了較好的解決。這也說明，操作系統提供相對規范的接口是解決安全產品沖突的較好方式。

瀏覽器防護的潛在兼容性問題

瀏覽器防護多使用ring3 API HOOK。下面結合網頁防護類的主流產品分析其潛在的兼容性問題。

使用ring3 api hook實現的瀏覽器保護，不可避免的要遇到和文件監控一樣的問題。在實際對抗中，網馬不斷發展升級，已經開始將瀏覽器中的ring3hook摘除，為了對抗此類威脅，主流軟件多會采取不斷檢測自己的h o o k是否存在，發現不存在則重新將函數掛鉤。造成多款軟件爭搶一個API的現象，導致瀏覽器無響應或者響應緩慢。特別是與CreateProcesss相關的。

在瀏覽器防護軟件進行行為分析的時候，由于其他瀏覽器防護軟件的參與會對瀏覽器的行為造成一定影響，這些影響可能是對堆棧的影響（由于多了一層Hook，實際調用的堆棧可能會增加一層）。以某瀏覽器防護軟件為例，其堆棧檢測只會向上追溯5層，如果同時共存3個軟件，那么其想要檢測的那層調用，則會由原來的第5層變為第7層，原來的檢測方式就失效了。

例如：360和金山網盾共存時，網馬在創建進程時3 6 0進行檢測。如果放行則會通過3 6 0的函數調用系統A P I，進而再次調用金山的進程創建檢測，此時金山追溯堆棧會發現是3 6 0的模塊調用，而不是J S腳本解釋引擎調用，予以放行。

即使不考慮對堆棧的影響，由于不同瀏覽器防火軟件都進行了攔截，對瀏覽器的行為也就產生了影響，造成相互的行為分析干擾，無法正確分析惡意行為，進而出現漏報或者誤報的現象。

例如：金山網盾在腳本解釋層根據特征檢出了惡意腳本，構筑在其上層的其他防護的行為分析就無法發現該惡意腳本的行為。

再例如：3 6 0網盾會不斷檢測監控點是否存在，而檢測的機制是基于二進制比較的，如果發現其他軟件進行了H O O K，則用自己的進行替換，導致其他軟件失效。

(本文作者系武漢大學客座教授)