杀毒软件江湖：排斥与兼容的战争（上）

文/肖新光

需要指出的是，绝大多数情况下，反病毒产品之间的兼容性冲突问题，都是技术与协调的问题，有其工作机理上的必然性，并往往具有一定的不可避免性。

反病毒产品兼容冲突问题

反病毒产品从最开始的行命令扫描工具发展至今，已经形成了带有文件、注册表、内存等多种本地监控机制；浏览器、邮件客户端等多种保护环节；以及整合了主机防火墙、入侵检测机制、主动防御机制的综合型产品。而其核心价值早在上世纪末，就已经从最开始的静态的文件扫描检测，变成实时化的主机防护。而实时化的防护推动了反病毒产品使用更多的服务、驱动等底层技术，运行于更接近系统内核的位置，这也为反病毒产品产生相互兼容性问题打下了伏笔。

随着操作系统的复杂化，威胁的不断离散化等影响，反病毒的监控保护点也日趋复杂，又加之反病毒厂商数量也在增加，而操作系统厂商并没提供比较标准的技术规范，因此反病毒产品因互不兼容，发生共存冲突等问题越来越多，并间接影响了用户对反病毒产品的信任。

目前己经发现并被报道过的兼容性问题包括：

造成系统崩溃和其他严重故障：从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，则用自己的进行替换，导致其他软件失效。

(本文作者系武汉大学客座教授)