当浏览器将一个组件加载后，这个组件就成为它的一部分，浏览器被称为“宿主”，根据设计的标准，组件能拥有宿主所拥有的所有权限，也能控制宿主的行为，而且，它更能执行普通程序所拥有的所有功能，简单的说，一个被浏览器加载的组件，除了它的生命周期取决于宿主以外，其他特性与一般应用程序无异，而且，它比一般应用程序还多了一个可以传递参数的交互接口，这样的设计初衷是为了方便浏览器宿主将其加载时进行一些必要的初始化工作，但是，这一部分的数据是通过网页HTML代码以明文的形式写入的，任何人都可以对其进行修改和控制。

　　并且，由于微软自身浏览器的接口标准可以响应ActiveX控件交互，那就意味着，大部分ActiveX控件都可以通过组件的形式载入浏览器，并对其参数进行控制，虽然它可能会由于不符合接口数据返回的规范而不会造成浏览器有任何行为，但是，它已经被加载运行了，数据也已经传递了。

　　正是这个特性，引发了新的一轮网页木马狂潮。

　　早在好几年前，网页木马(WebPage Trojan)的雏形——浏览器MIME解析漏洞结合电子邮件文档EML载体以浏览器子框架IFRAME的形式汹涌来袭，想必经历过那个年代的人都不会忘记“求职信”、“大无极”这些著名的“邮件木马”的可怕吧，实际上它们的本质都是网页木马，只不过是因为Outlook Express等邮件客户端很不幸的支持网页形式浏览罢了，最终导致它们被触发的因素仍然是那幕后为网页显示而工作的IE浏览器控件，我们可以将开启了网页视图的邮件客户端视为一种特殊的网页浏览器，EML就是在浏览器里被解释执行最终将病毒释放出来并执行的。

　　这个入侵狂潮随着IE6的出现而逐渐被历史埋没，但是，有人接过了它们手中的接力棒。

　　当第一个安全研究员发现通过浏览器加载的扩展组件会由于传入的参数检查不严而引发“缓冲区溢出”的现象时，新一代的网页木马正式拉开了序幕，不少安全团体都开始对各种主流的浏览器插件进行调试，然后，他们开始扩大“浏览器插件”的理解范围，最终，许多网页成了一个又一个树桩，长年累月的等待着倒霉的网民往上面“撞”，而这些问题的根源并非来自操作系统和浏览器本身，所以，即使网民们补上了所有系统补丁也无济于事。

　　2007年10月26日，国内安全团队报道了一个由RealPlayer引发的高危漏洞“RealPlayer ActiveX播放列表名称栈溢出”，该漏洞的真正问题文件是MPAMedia.dll，该文件用于处理播放列表的函数传参存在栈溢出漏洞，但是入侵者是通过对RealPlayer用于与浏览器交互的ActiveX组件“IERPCtl”(RealPlayer Control for Internet Explorer)来触发的，它位于RealPlayer目录里的rpplugins文件夹下，对应文件名为“ierpplug.dll”，它平时被用得最多的作用就是在浏览器中显示内嵌的媒体播放器和传递相关内容参数，然而这一次，它被作为一条直达要害的桥梁，以至于浏览器成功下载木马并执行，它也背上了黑锅，而实际上，它只是作为一个数据转接的通道存在而已，真正的元凶是MPAMedia.dll。

　　当RealPlayer ActiveX被载入浏览器后，它的所有参数便能通过HTML代码的形式传递，最常见的就是内嵌于浏览器的播放器，它至少需要一个待播放的媒体文件位置参数，在此基础上，网页设计者还能通过另一个参数来决定它能否自动播放媒体文件，这是大众最经常涉及的交互功能，大家都不会陌生，然而实际上，除了这些大众参数，还有个别极少被使用的参数存在，也许是因为它们“非主流”，RealNetworks没有将它们的安全盘查放在心上，但是，它们毕竟是存在的……

　　于是，漏洞就此出笼。一些安全研究者发现，RealPlayer ActiveX导出的“Import”功能函数中的第二个参数“playlist”是直接提交给内部文件MPAMedia.dll与之对应的函数中的，但不幸的是，该函数存在边界检查不严问题，可引发控件的“缓冲区溢出”，从而导致宿主(ierpplug.dll作为传参者，成为了MPAMedia.dll的宿主，而IE内核的浏览器加载了ierpplug.dll……于是多米诺骨牌效应发生了，一浪推一浪，后浪IE冤大头死在沙滩上……)发生千篇一律的结果：允许执行任何代码，如下载一个恶意程序运行、或直接删除用户数据等，而现在的主流手法自然是前者，也就是所谓的“网页挂马”，入侵者通过各种组件存在的缓冲区溢出漏洞，精心构造指令代码使得一个网页成为“潘多拉魔盒”，只要你打开它，你的世界将永无宁日。

　　为了不让网页的显示出现异常，入侵者通常沿用早期网页木马的隐秘加载形式——浏览器子框架IFRAME实现木马页面的读取，入侵者首先通过各种手段入侵一个网站(如社会工程学、SQL注入、服务器漏洞等)，然后修改这个网站中访问量相对较多的网页文件(例如首页或各个网页必须调用的网页头部框架等)，在里面加入一个高和宽均为“0”的IFRAME元素代码，内容指向入侵者在自己拥有的网络空间里放置的带毒网页文件，这个步骤就是“挂马”(为了确保自己的木马文件和带毒页面不被删除或供人随便就能研究，入侵者很少会直接将这两个文件一起放入受害网站的服务器上)，在这以后，当用户访问这个被入侵者做过手脚的网页时，他实际已经访问了两个网页：原本浏览的网页、以及入侵者放置的带毒页面。带毒页面一经加载则启动相应的浏览器ActiveX组件，并将入侵者构造的参数读取执行，最终，用户会面临两种结局，一种是由于用户没有安装相应功能程序导致组件不存在或组件版本已经经过漏洞更新，从而导致浏览器无任何异常或者发生崩溃(溢出失败最常见的后果：组件崩溃导致浏览器异常退出的“拒绝服务”)，在这时候用户是丝毫不知道自己刚躲过一劫的;而另一种则是比较符合国情的后果，即所有可令用户遭遇入侵的漏洞条件均存在，漏洞代码得以执行，导致用户浏览器下载执行了一个恶魔程序，最后恶魔可能被用户系统中的安全工具检测并消灭，也可能就此安居并将安全工具设为傀儡，从此用户上网将毫无防范——当然，这一切，用户都是毫不知情的。

　　其实，早在RealPlayer引发大面积的木马事件之前，国内就有好几个程序出了类似漏洞，例如国内下载新秀“迅雷”以及它的附属产品“迅雷看看”，都分别出现过参数检查不严导致溢出而带来的任意代码执行漏洞，但是随着RealPlayer漏洞创下的一次大面积撒网事件，第三方厂商的插件漏洞才开始被更多人注意并研究，到目前为止，国内已知的第三方插件漏洞几乎覆盖了大部分厂商，分别是PPStream PowerPlayer.DLL ActiveX 控件栈溢出漏洞、联众ConnectAndEnterRoom ActiveX控件栈溢出漏洞、超星阅览器Pdg2 ActiveX控件栈溢出漏洞、迅雷ActiveX控件DownURL2方式远程缓冲区溢出漏洞、Web迅雷ThunderServer.webThunder.1控件任意文件下载漏洞、百度超级搜霸BaiduBar.dll ActiveX控件远程代码执行漏洞、Qvod Player 2.0控件任意文件下载漏洞等，这一切，都让用户防不胜防。

　　这些漏洞的共同点都是依赖于用户机器的浏览器加载存在漏洞的组件来实现下载木马本体执行的功能，在相关厂商未出有效的安全更新之前，我们能做的只有通过某种手段预防漏洞危害，那就是利用浏览器自身提供的一个小功能将发生问题的控件暂时屏蔽。细心的用户在阅读一些安全小组的漏洞分析报告时，经常会看到这么一句：“在软件厂商未发布安全补丁之前，我们建议用户对该控件设置Killbit”。那么，什么是“Killbit”?微软编号Q240797的知识库文章《如何禁止 ActiveX 控件在 Internet Explorer 中运行》一文对此做出了诠释：Internet Explorer 有一项安全功能，可用于禁止 Internet Explorer HTML 呈现引擎加载某个 ActiveX 控件。此功能可通过进行注册表设置来完成，这种设置叫做设置“killbit”。一旦设置了“killbit”，该控件即永远不可加载，即使将其完全安装也是如此。此设置可以确保，即使有漏洞的组件被引入或重新引入系统中，它也不具活性，没有破坏力。

　　实际上，这一设置的本质是将存在漏洞的控件在浏览器里的兼容性标识设置为“不安全”，于是在预先设定的浏览器加载逻辑里，这一“不安全”的控件就不会被加载，从而保证浏览器不会携带着这个问题控件运行，其相关漏洞自然也就没有了入口。

　　兼容性标识位于系统注册表的HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\下，其子键为各个ActiveX控件的CLSID(有关CLSID概念请参见本文上半部分)，每个CLSID项里都有一个名为“Compatibility Flags”的DWORD类型值，当它的值为“0x00000400”即十六进制400或十进制1024时，浏览器就会认为这个控件不安全而将其忽略，同时微软还提供了“兼容的安全CLSID替代”功能，用于在对某个问题控件使用Killbit后指定的另一个功能替代控件，它是通过用户建立一个名为“AlternateCLSID”的字符串实现的，其内容为功能替代控件的CLSID。

　　只是，要让一般用户来操作这些东西，实在有种赶鸭子上架的感觉，你不能指望一个对Word操作都有点陌生的用户立即去理解注册表，去理解漏洞原因，所以，这是一种无奈的避难手段。

　　2008年，或许将会是个“浏览器插件漏洞年”。

上一页  [1] [2] [3] 下一页