CVE-2016-7293兼谈浏览器fuzz

  打印

近期,锦行科技从微软方面获悉,之前报告的某个IE漏洞已经得到了修补,对应的致谢页面微软也补上了关于CVE-2016-7293的信息。

尽管CVE官网对这个漏洞的描述尚未实时更新,但从微软的网站上可以看到相关的IE产品更新,我们对此手工测试,也发现最近一个补丁确实解决了这个潜在问题。

1

锦行科技发起成立的天工实验室长期致力于漏洞挖掘与攻击防御方面的工作,积极与同各大厂商合作,努力提高产品安全性,维护一个安全的网络环境。

这次微软对我们的致谢,首先是对团队成绩的肯定,同时也是一种鞭策和鼓励,未来我们将继续携手各大厂商,为提升网络安全体验做出更大的贡献。

长期以来,浏览器安全一直都是网络安全的焦点问题。在过去的几年里,仅微软方面就修补了上百个关于IE的各种漏洞。

值得注意的是,自2014年下半年起,IE浏览器漏洞总体数量呈下降的趋势,最主要的原因是微软Use-After-Free形成机制做了针对性防御,普通的Use-After-Free漏洞只能造成一个空指针引用而退化成为稳定性问题。

微软希望通过一个巨大的机制更新,一劳永逸解决这种类型的漏洞,确实取得了很好的效果。但我们也看到,尽管数量大幅度减少,但仍有不少的浏览器漏洞被发现和报告,这也引起我们思考:首先,浏览器是否还值得fuzz?如果是,我们应该寻求哪些方面的漏洞?

对于第一个问题,答案是显而易见的。每个月IE浏览器依然能贡献两位数的CVE,无疑它还是一个热点。那么第二个问题也就顺理成章了,微软堵住了一条大路,研究者们仍有很多小路可以走。

从漏洞的类型上,微软仅针对Use-After-Free类型,那么寻找其它类型的漏洞便成为一种可能,fuzz的模板可以偏向性地尝试去发现越界读写,类型混淆甚至未初始化内存等问题。

从范围上看,微软主要针对的是DOM,这样我们可以将重心转向脚本语言,多媒体或者插件上。

从深度上看,微软针对普通的Use-After-Free问题,那么一些隐藏较深的问题也许不在保护范围内。

前两方面是目前成果最多的,从微软的漏洞描述可以发现,浏览器脚本引擎问题层出不穷,类型混淆和内存越界访问问题也时常发生。

相对应的寻找深度漏洞则不然,我们从友商的漏洞POC分析结果可以看到,大部分漏洞的形成机制较为简单,也就是说,这些漏洞能被fuzz工具提供的足够广度所覆盖。

这个的推论是大家还在拼机器而不是拼思路,限于篇幅我们就不一一列举实例而是直接给出我们的想法,即fuzz需要考虑“选择”的问题,fuzz需要避免“枚举”的问题

简单来说,fuzz的“选择”是保证覆盖率的基本,fuzz需要选择元素,选择元素的构造方法,选择脚本执行的地点,执行的时间和频率,选择元素的操作,选择元素操作的组合,在这基础上还需要选择页面的组合方式、页面的调用关系等。“选择”构建了一个足够大的样本池,这个样本池能覆盖到浏览器解析部分代码的所有角落。

公开的fuzz工具大多采用枚举的方法来达到这个覆盖率,这是一个错误,因为枚举的顺序性使得覆盖率的广度不成问题,但对于分支的覆盖率确实表现平平。这个很容易从代码覆盖率来解释,枚举对于指令覆盖不成问题,但是对于MC/DC覆盖来说,基本不可能实现,更不用说更高程度的多重条件覆盖。

在软件漏洞日益难寻的今天,通过更严格的覆盖率才能找到更深的漏洞已经成为共识,相应的fuzz也应该借鉴白盒测试的经验,通过尝试“选择”而非“枚举”生成更多的页面,提高页面的实际复杂度,以期覆盖更多的分支及分支的组合。

回到CVE-2016-7293,这也是天工实验室对更复杂页面的一种尝试,实践也证明这个方法确实有效

从MAPP的消息来看,微软并没有同安全厂商共享这个漏洞的样本代码,因此我们这里不便公布代码,而重点讨论研究的思路。

作为研究和交流,有兴趣的研究者可以与我们的官方渠道进行沟通,我们也很乐意以妥当的方式,与研究者分享各种代码和我们的发现。