摘要: ·反病毒产品兼容冲突问题概述 反病毒产品从最开始的行命令扫描工具发展至今,已经形成了带有文件、注册表、内存等多种本地监控机制;浏览器、邮件客户端等多种保护环节;以及整合了主机防火墙、入侵检测机制、主...
·反病毒产品兼容冲突问题概述
反病毒产品从最开始的行命令扫描工具发展至今,已经形成了带有文件、注册表、内存等多种本地监控机制;浏览器、邮件客户端等多种保护环节;以及整合了主机防火墙、入侵检测机制、主动防御机制的综合型产品。而其核心价值早在上世纪末,就已经从最开始的静态的文件扫描检测,变成实时化的主机防护。而实时化的防护推动了反病毒产品使用更多的服务、驱动等底层技术,运行于更接近系统内核的位置,这也为反病毒产品产生相互兼容性问题打下了伏笔。
随着操作系统的复杂化,威胁的不断离散化等影响,反病毒的监控保护点也日趋复杂,又加之反病毒厂商数量也在增加,而操作系统厂商并没提供比较标准的技术规范,因此反病毒产品因互不兼容,发生共存冲突等带来的问题越来越多,并间接影响了用户对反病毒产品的信任。
目前己经发现并被报道过的兼容性问题包括:
- 造成系统崩溃和其他严重故障:从2000年以来,根据公开报道,已经出现多起因反病毒产品之间相互冲突,而导致系统蓝屏、死锁等事件。
- 资源占用:反病毒扫描、监控和其他防护机制,都会带来系统资源的占用。如病毒库的内存展开对内存的资源使用,文件监控、定时扫描可能导致更多的I/O开销、以及各种保护机制对CPU时间片的占用等等。这些对用户操作有一定影响,如系统延迟、文件复制操作时间变长等等。而由于消息传递等机制,有可能在多种反病毒产品共存时,其对资源和时间的影响不是简单的线性叠加,而是出现明显的性能恶化。
- 失效:由于监控机制之间的冲突,多种监控机制共存时,有可能造成其中之一失效,或者部分机制双双失效的风险。上述后果,可以在兼容性测试中被复现。
- 相互误报:由于厂商之间互信互通机制尚不够通畅,以及少数恶意的“误报构造”攻击的存在,厂商之间出现相互误报的情况,也时常发现。由于被报警为病毒而严重地影响用户对产品的信心,因此,各厂商对被误报的问题也均比较敏感。
但需要指出的是,绝大多数情况下,反病毒产品之间的兼容性冲突问题,都是技术与协调的问题,有其工作机理上的必然性,并往往具有一定的不可避免性。相关问题多数并不是由商业竞争引发的,商业竞争也不是反病毒产品兼容冲突问题的本质。本白皮书主要介绍当前反病毒产品冲突的主因,以澄清公众误解。
下文中涉及到安天和兄弟厂商产品所使用的技术点,均用于说明反病毒产品之间兼容性冲突的必然性,不是对实现水平进行评价。
·主要冲突点详细解析
实时监控、主动防御等技术的发展是一柄双刃剑,一方面随着监控点的增加能应对新的安全威胁,另一方面也使反病毒产品的稳定性遇到挑战,测试难度普遍加大。反病毒产品自身的稳定性压力都在呈现几何级数增长,相互之间的兼容则变得更加困难。以下从文件监控、防火墙、浏览器防护、主动防御四个主要技术点,描述导致反病毒产品自身的稳定性下降、与操作系统之间和相互之间出现严重冲突问题的成因。
·文件监控的潜在兼容性问题
文件监控是反病毒厂商普遍采用的技术手段,其主要机理是对文件的创建、读取、关闭等行为进行监控触发对文件病毒检测,以阻断病毒的执行和部分相关行为。
文件监控的实现方式主要有以下两大类型:
1. API挂钩。根据钩挂API的层次不同我们又可以分为
a) Ring3文件监控。多采用inline hook的方式修改文件操作相关函数的前几个字节,跳转到自己的函数,然后对将要操作的文件和缓冲区进行检测。
- 由于实现跳转的方式有多种,所以不同软件的实现策略有所不同,很难保证多个软件共存时前一软件修改后不影响到后一个软件,而且很可能导致相关进程崩溃。
- 由于此类技术也多被恶意软件使用,一些安全软件不会在执行完自己的代码后执行修改前的自己,而是采用从原始文件中读取、分析、执行的方式,导致多个安全软件同时监控一个API时,只有一个生效。
- 出于性能考虑,不传递给原API处理而采用自己实现的代码完成该API的相应功能,那么也不会将相关信息传递给其他软件。
- 部分软件在执行完自己的函数后会把修改后的字节还原,然后调用原系统API完成功能后再次修改、挂钩。两个使用此实现的软件同时工作则可能造成互相调用导致死锁,程序没有响应。
b) Ring0文件监控。与ring3的情况类似,但是后果更加严重。
- 由于inline hook不同实现造成的不兼容性很可能导致系统API无法正常工作,导致系统蓝屏。
例如:安天客户端产品(Antiy Ghostbusters4.0)早期版本采用大量inline hook,后因与其他产品严重冲突放弃;360安全卫士中inline hook有几种不同实现方式共存的现象,并且与360安全浏览器有重合的监控点。 - 挂钩之间相互调用,会导致死锁,系统死机。
- 采用替换SSDT的方式,则只有自己的挂钩有效,其他软件的挂钩均无效。
例如:360安全卫士等产品采用替换SSDT的方式,与其共存的安全软件通过标准方法获取的SSDT是无效的,导致其他安全软件功能出现缺失。 - Vista以后微软对内核进行保护,部分对内核函数的修改会导致系统蓝屏。
例如:多个产品在内测和对外版本都出现过对关键内核函数进行修改,但是并没有仔细判断版本,导致兼容性出现问题而使系统蓝屏。
2. 文件过滤驱动
- File System Filter Drivers
- File System Minifilter Drivers
过滤驱动的本质依然是挂钩,但微软为了方便厂商调用,对其进行了封装,属于官方的技术。此类技术本身已经力求稳定与兼容,多数都提供了一定的兼容性保障。微软自己的安全产品在驱动层面也多使用类似的方式。
处置方式 |
交给后续过滤函数继续过滤 |
直接交给下层函数处理 |
拒绝访问 |
兼容问题现象 |
扫描次数多、系统变卡、变慢 |
后续过滤不生效,实际上只有一个安全软件在保护主机。 |
后续过滤不生效,只有一个安全软件报告病毒。 |
但是在安全产品的实际应用中,多层监控逐层传递会造成效率的降低,一些厂商在实现时会绕过后续的过滤驱动,直接将IRP请求发给下一层驱动完成相关的功能。
·防火墙的潜在兼容性问题
目前反病毒产品普遍使用单机防火墙技术来过滤出入数据,应对来自网络的威胁。
目前防火墙的实现方式包括:
- TDI
- NDIS
- IP Filter
- Windows Filtering Platform
- Winsock Kernel
在以windows XP为主的时期,多数防火墙选择前三者中的某一种或者某两种结合的方式。在实际应用的过程中,同样存在多个共存无法同时生效的现象。其原因有:
1.过滤时出于效率考虑,直接将允许通过的包交给下层驱动处理,而不是后续的防火墙驱动。
2.由于NDIS和IP Filter比TDI更接近底层,前两者实现的防火墙会对TDI层造成影响。
3.XP自带的IP Filter存在谁先设置谁先生效的问题。安天盾防火墙与金山防火墙某版本同时使用该方式,如果同时安装在用户的机器中,则出现谁先启动谁先生效的现象。
WFP和Winsock Kernel是自vista之后引入的方式,兼容性相对而言更好,只要实现得当,一般没有兼容性的问题。特别是WFP针对防火墙和IDS类软件做了设计上的考虑,兼容性问题得到了较好的解决。这也说明,操作系统提供相对规范的接口是解决安全产品冲突的较好方式。
·浏览器防护的潜在兼容性问题
浏览器防护多使用ring3 API HOOK。下面结合网页防护类的主流产品分析其潜在的兼容性问题。
拦截点 |
金山网盾 |
360网盾 |
锐甲 |
作用 |
BHO |
BeforeNavigate |
BeforeNavigate |
BeforeNavigate |
拦截网址导航 |
wsock32 |
recv |
特征检测 |
||
Ws2_32 |
recv |
特征检测 |
||
WsaSend |
send |
拦截请求的URL |
||
Wininet |
InternetOpenUrl |
|||
InternetQueryDataAvailable |
||||
InternetConnect |
- |
InternetConnect |
拦截请求的URL |
|
InternetOpenUrl |
- |
InternetOpenUrl |
拦截请求的URL |
|
InternetReadFile |
- |
拦截请求的URL |
||
InternetQueryDataAvailable |
- |
拦截请求的URL |
||
HttpOpenRequest |
- |
HttpOpenRequest |
拦截请求的URL |
|
Vbscript.dll / jscript.dll |
compile |
ParseScriptText |
对浏览器执行的脚本进行分析 |
|
Kernel32 |
CreateProcess(Internal) |
CreateProcess(Internal) |
CreateProcess(Internal) |
|
CreateFile/Write/Read |
文件格式溢出检测 |
|||
CopyFile |
CopyFile(Ex)/MoveFile |
|||
LoadLibrary |
- |
LoadLibrary(Ex) |
||
VirtualProtect |
防止内存修改和溢出 |
|||
WinExec |
- |
|||
Ntdll |
NtCreateProcess(Ex)? / ZwCreateProcess(Ex) |
- |
||
Oleaut32 |
SysAllocStringLen |
- |
||
SysAllocStringByteLen |
- |
|||
CoRegisterClassObject |
||||
CoCreateInstance |
CoCreateInstance |
CoCreateInstance |
CLSID检测 |
|
CoGetClassObject |
CoGetClassObject |
CoGetClassObject |
CLSID检测 |
|
Urlmon |
UrlDownloadToFile |
UrlDownloadToFile |
UrlDownloadToFile |
|
UrlDownloadToCacheFile |
UrlDownloadToCacheFile |
UrlDownloadToCacheFile |
||
Advapi32 |
RegQueryValueEx |
|||
CreateProcessAsUser |
||||
Shell32 |
SHCreateProcessAsUserW |
|||
ShellExecute |
||||
ShellExecuteExW |
ShellExecuteEx |
|||
comdlg32 |
GetSaveFileName |
|||
WinTrust |
WinVerifyTrust(Ex) |
数字签名分析 |
||
浏览器行为分析 |
进程创建 |
进程创建 |
进程创建 |
|
模块加载 |
- |
模块加载 |
||
字符串分配(堆喷) |
- |
|||
文件下载 |
文件下载 |
文件下载 |
||
文件拷贝 |
文件拷贝 |
|||
ActiveX对象创建 |
ActiveX对象创建 |
|||
其他 |
内存占坑 + 保护 |
内存溢出防护+栈追溯 |
堆喷防护 |
|
OnDocumentComplete |
搜索结果标识、部分钓鱼识别 |
表格 1 主流安全防护软件监控点
使用ring3 api hook实现的浏览器保护,不可避免的要遇到和文件监控一样的问题。在实际对抗中,网马不断发展升级,已经开始将浏览器中的ring3 hook摘除,为了对抗此类威胁,主流软件多会采取不断检测自己的hook是否存在,发现不存在则重新将函数挂钩。造成多款软件争抢一个API的现象,导致浏览器无响应或者响应缓慢。特别是与CreateProcesss相关的。
在浏览器防护软件进行行为分析的时候,由于其他浏览器防护软件的参与会对浏览器的行为造成一定影响,这些影响可能是对堆栈的影响(由于多了一层Hook,实际调用的堆栈可能会增加一层)。以某浏览器防护软件为例,其堆栈检测只会向上追溯5层,如果同时共存3个软件,那么其想要检测的那层调用,则会由原来的第5层变为第7层,原来的检测方式就失效了。
例如:360和金山网盾共存时,网马在创建进程时360进行检测。如果放行则会通过360的函数调用系统API,进而再次调用金山的进程创建检测,此时金山追溯堆栈会发现是360的模块调用,而不是js脚本解释引擎调用,予以放行。
即使不考虑对堆栈的影响,由于不同浏览器防火软件都进行了拦截,对浏览器的行为也就产生了影响,造成相互的行为分析干扰,无法正确分析恶意行为,进而出现漏报或者误报的现象。
例如:金山网盾在脚本解释层根据特征检出了恶意脚本,构筑在其上层的其他防护的行为分析就无法发现该恶意脚本的行为。
再例如:360网盾会不断检测监控点是否存在,而检测的机制是基于二进制比较的,如果发现其他软件进行了HOOK,则用自己的进行替换,导致其他软件失效。
·主动防御的潜在兼容性问题
目前反病毒产品也普遍采用了一些不依赖于内容规则的,综合的行为判断和阻断机制,一般通称为主动防御技术。
在多款软件共存的情况下,主动防御的兼容性问题尤为严重。主动防御主要可以分