软件学报  2018, Vol. 29 Issue (5): 1275-1287   PDF    
基于模式生成的浏览器模糊测试技术
霍玮1,2,3,4, 戴戈1,2,3,4, 史记1,2,3,4, 龚晓锐1,2,3,4, 贾晓启1,2,3,4, 宋振宇1,2,3, 刘宝旭1,2,3,4, 邹维1,2,3,4     
1. 中国科学院 信息工程研究所, 北京 100195;
2. 中国科学院 网络测评技术重点实验室(中国科学院 信息工程研究所), 北京 100195;
3. 网络安全防护技术北京市重点实验室(中国科学院 信息工程研究所), 北京 100195;
4. 中国科学院大学 网络空间安全学院, 北京 100049
摘要: 模糊测试被广泛应用于浏览器的漏洞挖掘,其效果好坏的决定因素之一是测试者编写的测试模式.针对特定测试模式实现成本高、生存时间短等问题,提出了一种基于模式生成的浏览器模糊测试器自动构造方法,通过解析已知漏洞触发样本,自动提取测试模式,对模式中每个模块应用传统的变异策略,完成畸形样本的自动生成.实验结果表明:针对5款浏览器的1 089个已知漏洞触发样本,平均仅用时11.168s即可完成1 089个不同模糊测试器的自动构建,远低于人为编写的时间消耗;随机选取其中10个模糊测试器分别对IE 10、IE 11、Firefox 54.0的全补丁版本进行测试,共产生57个不同的崩溃样本,发现1个高危未知漏洞,证明该方法具有较好的未知漏洞发现能力.
关键词: 模糊测试     漏洞挖掘     浏览器     模式    
Browser Fuzzing Technique Based on Pattern-Generation
HUO Wei1,2,3,4, DAI Ge1,2,3,4, SHI Ji1,2,3,4, GONG Xiao-Rui1,2,3,4, JIA Xiao-Qi1,2,3,4, SONG Zhen-Yu1,2,3, LIU Bao-Xu1,2,3,4, ZOU Wei1,2,3,4     
1. Institute of Information Engineering, The Chinese Academy of Sciences, Beijing 100195, China;
2. Key Laboratory of Network Assessment Technology(Institute of Information Engineering, The Chinese Academy of Science), The Chinese Academy of Sciences, Beijing 100195, China;
3. Beijing Key Laboratory of Network Security and Protection Technology(Institute of Information Engineering, The Chinese Academy of Sciences), Beijing 100195, China;
4. School of Cyber Security, University of Chinese Academy of Sciences, Beijing 100049, China
Foundation item: Program of Key Laboratory of Network Assessment Technology, the Chinese Academy of Sciences; Program of Beijing Key Laboratory of Network Security and Protection Technology; Foundation of Key Laboratory of Network Assessment Technology, the Chinese Academy of Sciences (CXJJ-17S049); National Key Research and Development Program of China (2016QY071405)
Abstract: Fuzzing is widely used for browser vulnerability mining, and one of the key factors determining its effectiveness is the test pattern written by the tester.Considering that the test pattern is written with high cost and short survival time, in this article, an automatic construction of fuzzy tester based on pattern-generation is presented.By analyzing the known vulnerability samples and extracting the test pattern automatically, the traditional mutation strategy is then applied to each module in the pattern to complete the automatic generation of the abnormal samples.Experimental results show that in average it takes only 11.168 seconds to finish the automatic construction of 1 089 different fuzzy testers based on 1 089 known vulnerabilities for five browsers, which has much lower time-consumption than that required by testers themselves.Applying on IE 10, IE11 and Firefox 54.0 Web browser with randomly selected 10 fuzzy testers, the new method discovered a total of 57 different bugs, including a high-risk unknown vulnerability.This demonstrates that this method has better capability at finding the unknown vulnerability.
Key words: fuzzing     vulnerability mining     browser     pattern    

随着互联网技术的发展与普及, 已经有越来越多的人加入互联网的行列.据《每日邮报》报道(http://www.dailymail.co.uk/sciencetech/article-3960180/Almost-half-world-online-end-2016-poorer-countries-lag-report-shows.html), 截至2016年底, 全球网民数量已达到35亿, 约占总人数的一半.而浏览器作为互联网的主要入口, 几乎所有的网络行为都离不开浏览器.

正因为浏览器的广泛使用, 使得浏览器所引发的安全问题危害巨大.据新华网2010年对IE浏览器极光漏洞的报道(http://news.xinhuanet.com/tech/2010-03/10/content_13141841.htm), 金山网盾共拦截数百万次通过IE极光零日漏洞进行的攻击, 实际潜在受影响用户保守估计在千万级.据安全机构Flexera Software统计[1], 在2016年, 主流浏览器漏洞数量达到713个, 这些漏洞以高危漏洞为主, 意味着一旦被利用, 将造成严重的损失.

浏览器漏洞挖掘是一个经久不衰的话题, 被广泛关注.不同于其他软件漏洞挖掘, 浏览器经过20余年的发展, 其代码和结构已非常完善, 目前, 浏览器的漏洞挖掘难度也越来越高.首先, 大量漏洞的修补, 使得传统的漏洞类型已很少出现; 其次, 浏览器厂商对其产品的大规模测试, 使得一般的测试方法很难再产生较好的测试效果; 再次, 漏洞奖励计划的实施, 让大量的安全研究者加入到浏览器漏洞挖掘中, 使得浏览器漏洞挖掘出现“僧多粥少”的局面.

如今, 对浏览器漏洞挖掘的主要方法是模糊测试(fuzzing)[2], 其基本的思想是:给目标软件提供大量特殊构造的数据作为输入, 并同时监控目标软件运行过程中触发的异常, 辅之以对异常信息的人为分析, 从而确认目标软件中存在的漏洞.然而, 当前对浏览器进行模糊测试的效果好坏几乎都依赖于测试者编写的模糊测试器, 而浏览器模糊测试器的“骨架”是对网页元素处理的流程, 本文称其为测试模式.不同于其他软件的安全测试, 浏览器的模糊测试需不断地修改测试模式来保证持续的测试效果, 而由于浏览器组成的复杂性及安全机制的完善性, 测试模式的设计与调整对测试者的要求很高且实现复杂, 致使测试模式的产生效率很低.

针对上述问题, 本文提出了一种基于模式生成的浏览器模糊测试方法, 通过对测试模式组成的分析与形式化定义, 实现从已有的网页样本中测试模式的自动化提取, 基于该测试模式自动产生模糊测试器, 并完成测试数据构造.本文的主要贡献如下:

(1) 依据浏览器漏洞的类型与特征对浏览器模糊测试的测试模式进行模块抽象, 并使用BNF范式对其进行规范化定义, 作为不同模糊测试器的识别标准;

(2) 提出了一种测试模式自动提取方法及测试器自动构建方法, 使用不同的漏洞触发样本作为输入, 自动生成不同的测试模式, 并通过样本生成器产生大量的测试样本, 形成一个新的模糊测试器;

(3) 实现了一个浏览器模糊测试工具autofuzzy, 能够用于实际的浏览器模糊测试; 通过实验验证了本文提出的方法能够快速产生有效的测试模式和在零日漏洞的挖掘方面的有效性.

本文第1节介绍模糊测试的相关研究进展.第2节通过对现有浏览器模糊测试方法的分析, 提出本文的测试方法.第3节阐述测试模式的提取方法.第4节描述样本生成器构造方法及运行原理.第5节进行实验与结果分析.第6节总结全文并展望未来的工作.

1 相关研究

浏览器作为一种组成复杂的软件, 针对其不同结构的漏洞挖掘需采用不同的模糊测试方法[3, 4].

针对浏览器中所依赖的第三方库, 主要使用基于变异的模糊测试方法.该方法基于已有的输入样本(种子), 使用随机数据变异的方式产生测试数据.Lcamtuf提出的使用覆盖率指导数据变异的模糊测试工具afl (american fuzzy lop)[5]被认为是最有效的模糊测试器之一.它通过在测试过程中实时统计所产生的覆盖路径来指导数据的变异策略, 提高了代码覆盖率, 发现了上百个浏览器所使用图形库和字体库的漏洞; LibFuzzer[6]关注于Chrome浏览器中使用的开源库的测试, 该方法通过对接口函数中的参数进行变异来完成对给定函数的模糊测试, 发现了如Freetype, Ffmpeg等开源库的漏洞.

针对浏览器的ActiveX控件以及JavaScript解释引擎的漏洞挖掘, 也是研究的热点.Hodován等人[7]通过构建一种图结构来描述JavaScript引擎中的类型信息, 实现对JavaScript引擎API的测试, 该方法相对于已有的方法在覆盖率上有了大规模的提升; Ruderman[8]实现了一个对JavaScript引擎测试的工具jsfunfuzz, 通过随机构造大量的JavaScript语句操作来进行测试, 发现了280个Firefox浏览器JavaScript引擎[9]的漏洞.

针对浏览器渲染引擎的测试是当前最热门的研究点之一, 同时也是本文的关注点.X-Fuzzer[10]是由Katoch开发的一款轻量级的浏览器模糊测试工具, 通过对设置好的HTML标签属性进行随机赋值, 以实现对浏览器的测试; Google安全研究人员Zalewski开发的cross_fuzz[11], 其思想对浏览器模糊测试产生了深远的影响, 基于该方法及其衍生的其他浏览器模糊测试方法, 发现了上百个的浏览器安全漏洞.该方法采用递归式的浏览器测试方式, 首先生成浏览器DOM元素, 然后随机产生冗长的DOM操作序列对DOM进行操作并以新生成的DOM元素作为下一轮操作的对象, 从而完成递归测试; Lin等人[12]通过对相关的浏览器模糊测试工具和框架的整合, 提出一种新的测试数据生成方法, 通过动态挑选种子样本文件以及调整基础数据的变异方式来生成样本, 从而实现对浏览器渲染引擎[13]的测试; nduja[14]和fileja[15]是Valotta基于grinder[16]实现的一个测试数据生成的文件, 是近年来引领性的研究成果.其中,

●   nduja关注对DOM的测试, 它制定了一系列的新建、修改、删除DOM元素的规则, 通过随机选择的方式产生不同的测试样本来对浏览器进行测试.

●   fileja则提出了两个新维度的测试:时间维度引入时间的依赖关系以发现条件竞争等漏洞; 空间维度上考虑新版本的向下兼容所出现的错误.Valotta使用该方法在为期5个月的测试中发现15个浏览器安全漏洞.

对浏览器所依赖的开源库使用的变异的模糊测试方法, 尽管在对开源的图形库、字体库的测试中表现良好, 但在对输入有严格语法和语义规范的目标来说, 例如浏览器的渲染引擎、JavaScript引擎, 随机变异所产生的数据基本上在一开始就会被摒弃, 从而无法达到预期的测试效果.而如今, 对浏览器渲染引擎的测试需要测试者对目标本身以及目标所接受的输入数据规范有一定的了解, 因此测试的成本和起点很高; 并且单个测试工具(方法)的测试模式单一且有很强的时效性, 在经过一段时间的测试之后, 基本不再具备漏洞发现的能力.经过对nduja和fileja的分析发现, 其中nduja的核心代码有1 307行, fileja的核心代码有2 970行, 且完全由测试者手工构造; 并且现在将其直接用于浏览器模糊测试也已不能产生好的测试效果[17].

2 方法概述

针对浏览器渲染引擎的模糊测试器, 核心在于针对不同的漏洞模式和漏洞可能存在的问题点构造不同的测试样本, 测试样本的准确程度和时效性对测试效果的好坏有决定性作用.一个测试样本通常由元素构建、事件监听、方法操作、属性操作等主要操作类组成, 每一个操作类中随机选择具体的操作, 从而生成测试样本.本文将测试样本中操作类的选择及组合顺序称为测试模式, 在测试模式中决定了该选取哪类操作以及该如何组合, 构成了测试样本的“骨架”.

2.1 测试模式实例分析

下面以X-Fuzzer[10]和Nduja[14]这两款具有代表性的浏览器模糊测试器为例, 分析其构建原理, 总结出测试模式的概念与作用.

X-Fuzzer主要针对于HTML标签和属性进行测试.通过对其源代码进行分析后, 归纳出该工具的主要测试流程, 如图 1所示.X-Fuzzer的测试流程从整体上看是由创建元素节点对象、添加元素节点、Outer-innerHTML、删除对象这4类操作按照一定的组合顺序构成, 最后生成一个HTML样本来对浏览器进行测试.

Fig. 1 Test flow of X-Fuzzer 图 1 X-Fuzzer测试流程

Ndjua是一种针对于浏览器DOM结构进行模糊测试的方法, 并基于Grinder实现.通过对其分析, 总结其测试流程, 如图 2所示.从整体上看, Ndjua的测试模式是以创建元素节点、添加元素节点到DOM树中、添加事件监听、设置属性和属性值、特殊元素及对象的操作这5类操作按照一定的组合顺序构成, 最后生成一个HTML样本, 完成对浏览器的测试.

Fig. 2 Test flow of Nduja 图 2 Nduja测试流程

2.2 基本概念

从第2.1节的分析中可以得出:测试者在对浏览器进行模糊测试时, 测试流程的组成和所涉及的操作存在相似之处.根据测试者对浏览器运行原理的分析和理解, 从HTML网页的全部组成操作类中, 如创建元素对象、添加事件监听、属性的设置等, 挑选若干个类作为构建的基本组成, 然后使用若干种排列方法进行组合, 这些操作类和排列方法构成一个完整的测试流程.

为了下文描述方便, 本文给出3个基础定义.

●  模块:HTML网页构建中的1个操作类, 称为1个模块.模块包括创建元素对象、方法设置、属性设置等类别, 是测试模式中的最小组成结构.

●  逻辑:模块的排列顺序.例如, 给定了模块M1, M2, M3, 其中一种排列组合, 如M1M2M3或者M3M2M1即分别为一种逻辑.

●  测试模式:指定的模块按照特定的逻辑构成的测试流程.

2.3 方法介绍

为了能够低成本、高时效地构建一个测试模式, 本文提出了一种自动生成测试模式的方法, 并基于该模式产生测试样本.该方法首先分析已知漏洞触发样本, 通过模块识别和逻辑确定两步, 完成测试模式的自动提取, 然后, 利用所设计的可以解析测试模式并变异基本操作的样本生成器, 在基础数据集的支持下产生大量新的测试样本, 完成模糊测试, 主要流程如图 3所示.下文针对测试模式提取及样本生成两个主要步骤进行具体介绍.

Fig. 3 Test flow of method 图 3 方法测试流程

3 测试模式提取

从样本文件中提取测试模式的关键在于对模块的识别以及对逻辑的确定.本节将对模块进行划分与抽象后, 对样本文件中的模块进行静态识别; 并通过动态执行的方式获取各模块之间的依赖以确定逻辑; 最后, 依据识别的模块以及模块之间的依赖关系形成测试模式.

3.1 模块划分与抽象

一个浏览器模糊测试样本中一般存在上千个HTML元素构建、CSS样式操作以及JavaScript语句操作, 如果将每一项操作或者每一条语句作为模块, 则将会导致模块数量过多, 造成模块描述困难, 测试模式的产生效率过低; 若对模块的区分过于松散, 则会导致失去原始样本的漏洞触发特性, 难以得到预期的测试效果.因此, 需要在合理的粒度下对浏览器所能支持的操作进行模块抽象, 使测试模式的产生更加适合与高效.

模块抽象需要考虑以下两个因素.

(1) 基于软件缺陷产生, 构造测试模式对目标进行测试的核心目标在于发现软件缺陷, 因此, 模块抽象必须以此目标作为前提.需要考虑的包括软件缺陷的产生模式以及各个组成部分等.

(2) 基于测试范围, 需要保证浏览器的核心部分都能被测试, 如X-Fuzzer仅关注HTML标签的测试, 然而对于浏览器来说, 还有CSS样式的测试以及DOM树的测试等.

通过对典型浏览器模糊测试方法的分析, 如Pair-Fuzz[18]、cross_fuzz[11]、chromefuzzer[19]等, 结合对浏览器的历史漏洞样本分析之后, 总结出浏览器在处理过程中的核心操作、易出现安全问题的部分以及对出现软件缺陷存在影响的部分.主要分为3个方面的操作:HTML标签对象的操作、CSS样式的操作以及DOM树的操作.

1) HTML标签对象的操作

HTML标签对象的操作主要测试由于HTML标签的操作所导致的浏览器处理错误, 分为HTML标签元素的静态创建、HTML对象的动态创建、HTML对象的释放以及特殊标签元素的创建, 共计4个模块.

(1) HTML标签元素的静态创建是基于HTML语言语法对元素进行创建.在测试样本加载之后, 浏览器的HTML解析器将会对这部分创建进行解析, 包括用于表格的标签table, 用于超链接的标签a等.

(2) HTML对象的动态创建是基于JavaScript语法对HTML对象进行创建.基于JavaScript引擎对JavaScript代码进行解析后, 将依据指定的类型动态分配一块内存区域存储创建好的HTML对象.

(3) HTML对象的释放是基于JavaScript语法对指定的对象进行释放.该模块普遍出现于释放后重用漏洞(use after free)以及双重释放漏洞(double free)样本之中.

(4) 特殊标签元素的创建.基于对历史漏洞的分析后发现, 存在复杂的操作逻辑的特殊标签元素, 也是漏洞出现的集中点, 如range, form, iframe等, 因此, 这部分需要重点考虑.

具体描述见表 1.

Table 1 Module abstraction of HTML tag object manipulation 表 1 HTML标签对象操作的模块抽象

2) CSS样式的操作

CSS样式的操作用于针对性发现浏览器处理样式时所存在的缺陷, 分为CSS样式的初始化设置和对CSS样式的动态操作两个模块.CSS样式的初始化设置是基于CSS语法来进行样式设定, 主要关注测试浏览器的CSS解析引擎; CSS样式的动态操作是指依赖于JavaScript代码动态对CSS样式所做的设定、修改和删除等操作.具体描述见表 2.

Table 2 Module abstraction of CSS style operation 表 2 CSS样式操作的模块抽象

3) DOM(document object model)树的操作

DOM[20], 称为文档对象模型, HTML DOM定义了所有HTML元素的对象和属性以及通过JavaScript访问它们的方法.

浏览器在加载页面时, 会将页面中的元素、属性、文本等解析为一个树形结构, 即DOM树.页面中的元素、属性、文本等则作为DOM树中的树节点存在.JavaScript对页面的操作则是基于DOM树结构, 因此对DOM树的操作是浏览器的核心部分, 也是漏洞频发的位置.

DOM树的操作是一个很复杂的过程, 本文将对DOM树的操作分为DOM树的修改、属性和属性值的设置、方法的设置以及事件的监听这4个模块.

(1) DOM树的修改, 基于HTML DOM提供给JavaScript的接口方法, 能够在DOM树中添加节点、删除节点、替换节点等.旨在通过对DOM树结构的改变来触发浏览器对DOM树处理的错误.

(2) 属性和属性值的设置, 通过DOM树支持的属性节点操作, 设置属性来添加属性节点, 修改属性值来改变属性节点中的内容等来进行测试.

(3) 方法的设置, 针对不同的元素对象和节点对象, HTML DOM提供了上百个不同的操作方法, 如对于MediaRecorder对象, HTML DOM提供start方法用于开始记录, 提供stop方法用于终止记录等.这些方法在执行过程中也会间接或直接对DOM树进行操作, 从而有可能引发处理的错误.

(4) 事件的监听, 通过对HTML DOM支持的事件接口注册事件, 实现对浏览器事件机制的测试.事件响应的顺序对DOM树的操作产生影响.

具体描述见表 3.

Table 3 Module abstraction of DOM tree operations 表 3 DOM树操作的模块抽象

3.2 模块识别

在给定一个HTML网页形式的漏洞触发样本后, 模块识别算法将逐行处理, 输出其中存在的模块, 具体处理流程如算法1所示.

算法1. DOM树操作的模块抽象.

Input: sample: Sample After Normalize.

Output: ModelList: Model List.

1        HTMLLines:=NULL

2        CSSLines:=NULL

3        JSLines:=NULL

4        Lines:=getLinesFromSample(sample)

5        for each line in Lines

6                  if isLineBelongHTML(line) then

7                           HTMLLines.append(line)

8                  else if isLineBelongCSS(line) then

9                           CSSLines.append(line)

10                else if isLineBelongJS(line) then

11                         JSLines.append(line)

12      ModelList:=NULL

13      for each line in HTMLLines

14                tags, property, event:=getTagsProEvent(line)

15                if tags!=NULL then

16                         ModelList.append(Mapping(tags, property, event))

17      for each line in CSSLines

18               selector, property:=getSelectorProperty(line)

19                if selector!=NULL then

20                         ModelList.append(Mapping(selector, property))

21      for each line in JSLines

22                for function ModelFeature in ModelFeatureList

23                         model:=ModelFeature(line)

24                         if model!=NULL then

25                                  ModelList.append(model)

26                                  break

27      return ModelList

●  第1行~第4行定义了3个变量, 分别用于记录输入样本中的HTML, CSS, JavaScript部分; 并从输入样本中按照每行为单位读入.

●  第5行~第11行, 依次访问每一行代码, 依据相应的特征将其分配到HTML, CSS, JavaScript中3个类别中, 其余成分不进行分析.

●  第13行~第16行, 针对HTML类别中的每一行代码, 识别静态HTML代码中标签名、属性、以及注册事件等模块, 识别函数为getTagsProEvent.

●  第17行~第20行, 针对CSS类别中的每一行代码, 识别出CSS样式的选择器、属性类型等模块, 识别函数为getSelectorProperty.

●  第21行~第26行, 针对JavaScript类别中的每一行代码, 根据识别函数确定其所属模块, 识别函数为ModelFeatureList.

本文使用BNF格式对模块特征进行规范化定义, 并作为getTagsProEvent, getSelectorPropertyModelFeatureList等核心识别函数实现的依据.BNF规范是推导规则的集合, 表示为⟨符号⟩ :=⟨表达式⟩ ,符号是非终结符, 表达式则是一个符号序列用于对左侧符号的描述.本文所使用的基本语法符号见表 4.

Table 4 Introduction to BNF symbols 表 4 BNF符号介绍

依据BNF的基础符号规范, 对抽象后的模块描述见表 5.

Table 5 Abstract module and BNF description 表 5 抽象的模块与BNF描述

3.3 逻辑确定

逻辑的确定, 关键在于识别出各模块之间的依赖关系.对于一个HTML样本来说, CSS和HTML代码属于一开始加载的, 而JavaScript的执行才包含执行的顺序, 因此, 逻辑的确定主要关注JavaScript代码.经过规范后的样本, 其JavaScript代码完全处于⟨script⟩标签内, 因此, 这将是我们进行动态逻辑识别的前提.识别依据代码插桩的思想, 在关键位置设置标识, 本文中设置为⟨script⟩标签位置以及function函数位置; 然后, 实际运行修改后的样本, 通过标识位置从而确认执行的顺序.具体流程图如图 4所示.

Fig. 4 Logical acquisition process 图 4 逻辑获取流程

4 样本生成器

样本生成器用于依据获取到的测试模式来构造大量的测试样本, 主要包含两个部分:第1部分是人工构造的一个基础的数据集, 第2部分是构造出测试样本.

4.1 数据集

针对每一个模块, 人工构造了一个与之对应的数据集, 包含该模块所对应的操作集合.这将是样本生成的基础数据来源.

4.2 测试样本生成

测试样本生成以数据集为基础, 当输入一个测试模式之后, 将按照测试模式的模块组成和逻辑顺序, 产生新的测试样本.流程如图 5所示.

Fig. 5 Test cases generation process 图 5 测试样本生成流程

当输入一个测试模式之后, 样本生成器将把测试模式依据模块之间的依赖将其划分为模块序列, 每一个模块将依据相应的模块数据集随机获取相应的操作, 并在各个模块之间填充随机操作来优化测试效果.最终, 组合所有操作生成新的测试样本.

5 实验与结果分析

针对于上述提出的模糊测试方法, 本文设计并实现了一个全新的浏览器模糊测试器——autofuzzy, 并通过相关实验来验证本文提出方法的有效性.

5.1 实验环境

本文中测试的机器均为Windows 7旗舰版, 内存4G, 处理器为Intel Xeon E312xx(Sandy Bridge) 2.40GHz(2处理器).开发语言为Python 2.7.

5.2 实验样本集

本文通过网络爬虫模块从packetstorm, guanting中依据浏览器相关的关键字(Internet explorer, IE, firefox, opera, chrome, edge, browser)一共爬取了1 545个样本, 经过筛选(去除非HTML样本), 一共得到1 089个已知漏洞触发样本作为种子输入, 用于验证测试模式的产生效率以及实际的测试实验.

5.3 实验结果分析

为了验证本文中提出的方法的有效性, 本文提出了3个问题并通过实验来验证.

1) 本文的测试模式产生效率如何, 能否优于人为的测试模式编写?

2) 本文提出的模式生成的方法是否有发现新的浏览器漏洞的能力?

3) 将本文提到的模糊测试方法应用于实际的浏览器模糊测试中, 测试效果如何?

针对上述3个问题, 本文一共设计了3个实验来进行验证与分析.

(1) 问题1

测试模式的产生为从样本文件作为输入, 经过测试模式提取器后输出测试模式这一过程.通过对1 089个有效的种子文件进行测试模式提取, 得到如表 6所示的结果.

Table 6 Test pattern extraction time consumption 表 6 测试模式提取时间消耗

另外, 通过对1 089个种子文件测试模式提取时间进行统计, 平均每个测试模式获取用时为11.168s, 远快于人为构造的数千行代码的时间消耗.

(2) 问题2

通过设计实验对IE浏览器UAF漏洞CVE-2012-4792进行模式提取后形成的模糊测试器, 对IE8 8.0.7601. 17514进行了为期2天的测试, 最终发现了33个相同模式的软件异常, 其中包括用于提取模式的漏洞样本.并经过确认其中包含CVE-2012-4792之后出现的两个已知的安全漏洞, CVE-2013-1347和CVE-2013-3189.具体信息见表 7.

Table 7 Vulnerabities details 表 7 漏洞详细信息

下面将对CVE-2013-1347的发现进行分析, 以验证本文所提方法在理论上也具备发现其他漏洞的能力.

图 6所示, 当输入样本CVE-2012-4792之后, 通过我们的测试模式提取器将得到右侧所示的测试模式, 其表示方式对应于模块的BNF描述.我们的样本生成器将会按照右侧的测试模式构造大量的数据样本来对浏览器进行测试.

Fig. 6 Crash sample and test patterns of CVE-2012-4792 图 6 CVE-2012-4792异常样本及测试模式

图 7为我们精简过后的异常样本CVE-2013-1347, 将我们的异常样本的测试模式与原始种子样本的测试模式进行对比之后发现, 两者的测试模式基本一致, 其中, 异常样本中多的一次style_operate操作为样本生成器中所产生的随机操作, 而原始样本中多的模块也在精简过程中被去除了.因此从理论上看, 我们也能够依据原始样本的测试模式得到相应的漏洞样本, 因此, 本文的测试方法具备发现新漏洞的能力.

Fig. 7 Crash sample and test patterns 图 7 异常样本及测试模式

(3) 问题3

为了验证本文的测试方法在实际的浏览器测试过程中也能产生一定的效果, 本文从爬取的测试样本中随机选取10个作为种子文件作为模式提取, 并产生10个模糊测试器用于全补丁的浏览器模糊测试.通过对Internet Explorer, Firefox浏览器进行为期10天的测试, 为了提高测试效率, 采用并行方式开展测试.测试过程中, 发现了57个软件异常, 其中包含1个高危漏洞(firefox UAF), 漏洞样本简单分析.测试结果见表 8.

Table 8 Test results 表 8 测试结果

通过对全补丁的浏览器进行测试, 能够发现一定数量的软件异常, 说明本文提到的方法在对实际的浏览器模糊测试中也是有效的.

6 结论与展望

本文提出了一种浏览器模糊测试方法.立足于浏览器模糊测试的核心点在于如何构造合适的测试样本, 而测试样本的构造核心依靠构造测试样本的逻辑算法, 即测试模式.本文通过对样本文件中测试模式的提取, 达到了测试模式快速产生的目的, 弥补了现今浏览器模糊测试过程中测试模式产生对人的过度依赖、时间消耗过大等缺陷.最后, 通过3个实验来验证本文所提出的测试方法的确能够快速产生有效的测试模式; 并且还能在对已有漏洞样本测试模式提取的基础上使用产生的模糊测试器测试发现新的漏洞; 最后, 在应用于实际的浏览器测试也能产生一定的测试效果.

然而, 本文中提到的测试方法仍具有以下不足之处:一是对获取的测试模式并未有一个很好的管理和反馈机制; 二是本文主要关注浏览器渲染引擎的测试, 而缺少对JavaScript解析引擎的支持; 三是本文实现的模糊测试器——autofuzzy中的样本生成器仅为一个雏形, 还需添加更多的基础数据来满足样本的生成.随着浏览器的功能逐渐复杂化以及浏览器各类安全机制的出现, 如何能够有效、快速地对浏览器进行测试, 将会是未来工作的重点, 机器学习、深度学习等智能化技术也将会在未来逐渐引入到浏览器模糊测试中.

参考文献
[1]
Flexera Software. Vulnerability review 2017. Research Report, 2017. 20-22.
[2]
Sutton M, Greene A, Amini P, Wrote; Huang L, Yu LL, Li H, Trans. Fuzzing: Brute Force Vulnerability Discovery. Beijing: China Machine Press, 2009(in Chinese).
[3]
Wu SZ, Guo T, Dong GW, Zhang P. Software Vulnerability Analysis Technology. Beijing: Science Press, 2014. 215-246(in Chinese).
[4]
Miller C, Peterson ZNJ. Analysis of mutation and generation-based fuzzing. Technical Report, Independent Security Evaluators, 2007. https://www.defcon.org/html/links/dc-archives/dc-15-archive.html#Miller
[5]
Zalewski M. American fuzzy lop. 2017. http://lcamtuf.coredump.cx/afl/
[6]
libFuzzer-A library for coverage-guided fuzz testing-LLVM 3. 9 documentation. 2017. http://llvm.org/docs/LibFuzzer.html
[7]
Hodován R, Kiss Á . Fuzzing JavaScript engine APIs. In: Proc. of the Int'l Conf. on Integrated Formal Methods. Springer Int'l Publishing, 2016. 425-438. [doi: 10.1007/978-3-319-33693-0_27]
[8]
Ruderman J. Introducing jsfunfuzz. 2015. http://www.squarefree.com/2007/08/02/introducing-jsfunfuzz/
[9]
[10]
[11]
Zalewski M. cross_fuzz. 2011. http://lcamtuf.coredump.cx/cross_fuzz/
[12]
Lin YD, Liao FZ, Huang SK, Lai YC. Browser fuzzing by scheduled mutation and generation of document object models. In: Proc. of the Int'l Carnahan Conf. on Security Technology. IEEE, 2016. 1-6. [doi: 10.1109/CCST.2015.7389677]
[13]
Zhu YS. WebKit Technology Insider. Beijing: Electronic Industry Press, 2014: 15-63.
[14]
Valotta R. Taking browsers fuzzing to the next (DOM) level. 2012. 1-40.
[15]
Valotta R. Fuzzing browsers in 2014. SyScan360. 2014. 1-43.
[16]
Fewer S. Grinder. 2014. https://github.com/stephenfewer/grinder
[17]
Qian WX. White Hat Talks about Browser Security. Beijing: Electronics Industry Press, 2016: 229-231.
[18]
Qu B, Lu R. Power in Pairs: How one fuzzing template revealed over 100 IE UAF vulnerabilities. In: Proc. of the Blackhat EUROPE 2014. 2014. 1-28.
[19]
demi6od. ChromeFuzzer. 2015. https://github.com/demi6od/ChromeFuzzer
[20]
[2]
Sutton M, Greene A, Amini P, 著; 黄陇, 于莉莉, 李虎, 译. 模糊测试: 强制性安全漏洞发掘. 北京: 机械工业出版社, 2009.
[3]
吴世忠. 软件漏洞分析技术. 北京: 科学出版社, 2014. 215-246.
[13]
朱永盛. WebKit技术内幕. 北京: 电子工业出版社, 2014.
[17]
钱文祥. 白帽子讲浏览器安全. 北京: 电子工业出版社, 2016.