网络空间安全:行业资讯、技术分享、法规研讨、趋势分析……

“游侠安全网”创建了网络安全从业者QQ大群(群号:1255197) ,欢迎各位同仁加入!有其它问题如合作等,请联系站长“网路游侠”,QQ:55984512


安天实验室:反病毒产品的兼容性问题白皮书

2010-08-19 20:34 推荐: 浏览: 71 views 字号:

摘要: ·反病毒产品兼容冲突问题概述     反病毒产品从最开始的行命令扫描工具发展至今,已经形成了带有文件、注册表、内存等多种本地监控机制;浏览器、邮件客户端等多种保护环节;以及整合了主机防火墙、入侵检测机制、主...

·反病毒产品兼容冲突问题概述

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

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

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

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

·主动防御的潜在兼容性问题

    目前反病毒产品也普遍采用了一些不依赖于内容规则的,综合的行为判断和阻断机制,一般通称为主动防御技术。

    在多款软件共存的情况下,主动防御的兼容性问题尤为严重。主动防御主要可以分

联系站长租广告位!

中国首席信息安全官