CN113238937B - 一种基于代码精简与误报过滤的编译器模糊测试方法 - Google Patents

Abstract

本发明公开了一种基于代码精简和误报过滤的编译器模糊测试方法。所公开的方法包括使用多个编译器对测试用例集进行差分测试，在多个编译器每执行完一个测试用例后，如果编译器的执行结果不一致，将这个用例标记为可疑用例；之后利用基于语法块或基于代码行的代码精简技术对可疑用例内容进行精简构建可疑用例集；再以决策树的形式，利用误报过滤数据库对可疑用例的执行结果进行过滤构成误报过滤数据库，最后通过人工分析可疑用例集和误报过滤数据库发现bug。本发明的方法实现了高效，快速，准确的定位出错位置，减少了测试人员发现编译器漏洞的时间，提高了编译器测试的效率。

Description

一种基于代码精简与误报过滤的编译器模糊测试方法

技术领域

本发明属于软件自动化测试领域，特别涉及一种基于代码精简和误报过滤的模糊测试方法。

背景技术

软件模糊测试技术最早起源于1988年美国威斯康星大学巴顿·米勒教授的研究生课程项目，近年来更是被业界所广泛应用，挖掘软件中潜在的安全漏洞。模糊测试是一种自动化的编译器测试技术，其核心思想是自动或半自动地将生成数据输入到被测试系统中，通过监视程序的异常表现，如断言，崩溃，输出错误等，发现软件中潜在的漏洞。其中断言和崩溃的执行结果较容易被检测，而输出错误结果的漏洞较难被发现。通常为了检测编译器的输出错误，会引入差分测试思想，即将测试用例同时执行在多个编译器上，如果某一编译器与大多数编译器的执行结果不一致，则认为可能触发了此编译器的漏洞。

软件模糊测试技术的关键点在于自动化生成测试用例并对被测软件进行测试，因此高质量测试用例的生成尤为重要，为此学术界和工业界已经给出了多种有效的解决方案。例如当前应用较为广泛的AFL工具已发现了大量的软件漏洞，AFL以代码覆盖率指标来指导测试用例的生成，但由于变异策略的不完善，其发现bug的效率较低。此后，研究人员基于AFL的框架，设计出多种改善的Fuzzer工具，已取得显著的研究成果。Montage将测试用例的语法树切割为片段，利用神经网络模型学习语法子树之间的关系，自动地替换测试用例的语法子树从而完成对测试用例的变异。Jsfunfuzz是一个比较出名的测试工具，其根据人工定义的语法规则，生成语法正确的测试用例，目前已经发现了Mozilla FirefoxJavaScript引擎的一千多个缺陷或漏洞。

虽然以上基于生成或者基于变异的测试工具已经取得了巨大成功，但由于测试用例生成的随机性，不可避免地出现大量重复的测试用例，导致同一种非漏洞测试结果需要被多次人工分析与确认，将这些重复的非漏洞执行结果定义为误报，分析误报会浪费测试人员大量的时间和精力。并且触发漏洞的代码往往只有几行，而测试用例内容过于复杂，需要测试人员手工完成大量的代码精简工作，影响漏洞分析的效率。

发明内容

针对现有技术的缺陷或不足，本发明提供了一种基于代码精简与误报过滤的编译器模糊测试方法。为此，本发明提供的方法包括：

(1)构建多个被测试编译器的测试集；对测试集中的各测试集用例进行差分测试；对于每一个测试集用例，将其同时输入多个被测试编译器中进行差分测试，将出现编译器崩溃或超时执行的测试集用例和差分测试结果为多数编译器执行结果相同和少数编译器执行结果不同的将测试集用例标记为可疑用例；

(2)对所有可疑用例进行精简处理；对于每一个可疑用例，对该可疑用例进行语法树解析，如该可疑用例可以被解析则基于语法子树进行精简，否则基于代码行进行精简；所有精简后的可疑用例构成可疑用例集；

(3)对于步骤(1)中所有可疑用例的少数编译器执行结果进行误报过滤处理；对于每一个执行结果，获取该执行结果对应的编译器名称或编号、该执行结果的错误类型、该执行结果的关键报错信息和该执行结果的相关API，判断所得编译器名称或编号、错误类型、关键报错信息和相关API在误报过滤数据库中是否作为同一条记录存在，如存在则过滤掉该输出结果，否则将该执行结果对应的编译器名称或编号、错误类型、关键报错信息和相关API作为一条记录，保存至误报过滤数据库中；误报过滤数据库初始为空；所有执行结果误报过滤完成后得到的误报过滤数据库构成执行结果集，执行结果集中的每条记录对应一个可疑用例；

所述错误类型至少包括：类型一：执行结果包含错误信息、类型二：执行结果不包含错误信息；

所述关键报错信息为采用第二正则表达式对执行结果进行正则规范化后得到的规范结果；

可疑用例集与执行结果集构成被测试编译器的人工分析集。

可选的，所述编译器执行结果根据执行进程的返回值确定。

可选的，所述语法树解析采用Esprima语法解析器、Clang语法解析器或ast语法解析器进行解析，这些语法解析器均包含能够将代码解析为抽象语法树的API，直接调用API即可完成语法树解析。

进一步，所述基于语法树精简包括：对解析出的语法树的各语法子树依次进行删除，删除顺序包括：先删除隶属当前语法树根节点的语法子树；对于当前语法树根节点有多个语法子树的情况，从右自左依次删除；

对于每一个语法子树，先初步删除该语法子树，每初步删除一个语法子树后，将进行初步删除后的可疑用例同时输入所述多个编译器中，对不改变执行结果的语法子树进行最终删除；所述不改变执行结果为出现步骤(1) 少数情况的编译器不变。

进一步，所述基于代码行的精简包括：从下到上依次删除一行代码，对于每一代码行，先初步删除该代码行，每初步删除一个代码行后，将进行初步删除后的测试集用例同时输入所述多个编译器中，对不改变执行结果的代码行进行最终删除；所述不改变执行结果为出现步骤(1)少数情况的编译器不变。

可选的，所述不改变执行结果为出现步骤(1)少数情况的编译器不变或/和第一关键输出信息不变，所述第一关键报错信息指采用第一正则表达式对可疑用例的执行结果进行正则规范化后得到的规范结果。

有些方案中，所述第一正则表达式与第二正则表达式相同。

进一步本发明的方法还包括：对所述被测试编译器的人工分析结果集进行人工分析确定被测试编译器的漏洞。

本发明一方面通过对对测试用例进行精简，解决了传统的基于随机删除代码行难以删除代码块以及基于二分法难以删除关联语句的问题，实现了更加准确和有效地精简测试用例，节省了测试人员在用例精简上花费的时间，从而间接提高了发现编译器bug的效率。

本发明同时还通过以编译器名称，关键输出信息，API名称，报错类型作为关键字，对编译器执行结果进行规范化，并按照决策树的形式逐步判断该条执行结果是否为误报。从而实现了一个高效且自动化的误报过滤系统，避免了测试人员在分析误报用例上花费大量的时间。

附图说明

图1为本发明代码精简流程图；

图2为误报过滤流程图；

图3为实施例代码精简的示例过程中的语法树。

以下结合附图和实施例对发明作进一步的详细说明。

具体实施方式

除非有特殊说明，本发明中的术语或方法根据相关领域普通技术人员的认识理解或采用已有相关方法实现。

本发明测试集的构建方法采用现有方法或在不违背本发明目的和构思的前提下所改进的方法构建。如可采用基于规则的代码生成工具或基于深度学习的文本生成工具进行构建获取；更具体例如：C语言的csmith开源代码生成工具，OpenCL语言的deepsmith开源代码生成工具，GPT-2文本生成模型等构建获取。

本发明的差分测试是将测试集中的测试集用例依次交由多个编译器执行，并利用差分的思想标记各编译器可疑的执行结果，即执行结果按照少数服从多数的投票机制进行差分分类，将差分测试结果存在“不同于大多数编译器执行结果的少数结果”的测试集用例标记为可疑用例。

本发明差分测试所用编译器为被测试集用例所用编程语言的编译器，常见的如不同公司开发的JS引擎、C语言编译器、Python解释器等。

所述编译器的执行结果是一个具体的编译器对一个具体的测试用例执行情况的表示。常见的输出结果包括：抛出错误、编译器崩溃、执行超过合理时长(如60s)和执行通过。

更具体的方案中，所述编译器执行结果根据执行进程的返回值确定。示例：当执行进程的返回值为-9时，执行结果为“timeout”(即执行超过合理时长)，当执行进程的返回值为非-9的负数时，执行结果为“crash”(即编译器崩溃)，当执行进程的返回值为0时，执行结果为“pass”(即执行通过)，其余情况，执行结果均为“script_error”(即抛出错误)。

进一步，常见的差分测试结果为：①所有编译器输出值相同或都抛出错误；②测试集用例导致了编译器崩溃或执行超过合理时长如60s；③大多数编译器抛出错误，少数编译器执行通过；④大多数编译器执行通过，少数编译器抛出错误；⑤所有编译器执行均通过，但是少数编译器的输出值不正确 (所述编译器的输出值不正确指所有编译器在对测试用例的编译和执行过程中未抛出错误，但是少数编译器对测试用例的执行结果输出值与多数编译器的执行结果输出值不一致)。对于第一种类别，直接过滤，不进行后续人工分析；对于第二-五种类的测试集用例标记为可疑用例。

为了提高之后可疑用例执行的速度，减少用例分析时手工精简代码的工作，本发明对可疑用例的内容进行精简。代码精简的策略为基于语法块的精简，若用例内容不能解析出语法树结构，则采用基于代码行的精简方式。如图1所示，代码精简的方式采用以语法块精简为主，代码行精简为辅的精简策略。

其中基于语法块精简，利用Esprima，Clang，ast等工具将测试用例内容解析为语法树；

解析出测试用例的语法树之后，按照从右向左，从大到小的策略去除不影响执行结果语法子树。

采用从右向左的精简方法，先去除未执行到的内容，提高精简效率；从大到小的精简方法是指当解析出语法树后，先精简根节点的语法子树，去除不改变执行结果的语法子树，再依次将不能被去除的语法子树作为根节点，对它们语法子树进行再精简；如此递归，直至精简到最小单元。从大至小的精简方法好处是，可以准确的一次性删除多行代码，且需要被精简的部分只会被遍历一次，提高了代码精简的准确性，缩短了精简时间。

基于代码行精简按照从下到上的顺序，依次删除一行代码，去除可以被删除的代码行即不改变执行结果的代码行，完成用例精简。

对于上述两种精简方式，不改变执行结果的判断指标是：出错编译器或 /和第一关键输出信息，即通过判断用例精简前后，执行结果中的出错编译器和关键输出信息是否改变决定相应语法块或代码行是否可以被精简。其中：出错编译器是指差分测试结果中可疑用例的少数执行结果对应的编译器，其可取值为差分测试编译器的名称或编号。第一关键输出信息是通过利用第一正则表达式将可疑用例的执行结果进行规范化得到的，即通过比较规范化后的输出信息，判断关键输出信息是否改变。

由于关键报错信息较容易改变，本发明将其设定为可选项指标，一般默认情况下只使用出错编译器作为精简的指标，即如果精简前后出错编译器未改变，认为用例可被精简，反之如果出错编译器改变，我们认为用例不可以被精简。如果选择关键输出信息作为精简指标，则出错编译器或关键输出信息任一值改变时，用例都不能被精简。

本发明的误报过滤阶段的主要目的是去除可疑执行结果中的重复部分，保证同一种类型的可疑执行结果只会被分析一次，图2是本发明误报过滤系统的流程图。

本发明的误报过滤阶段以出错编译器、错误类型、第二关键报错信息和相关API为指标规范化一条可疑执行结果(即一条记录)，判断规范化后的可疑执行结果是否已存在于误报过滤数据库，如果存在，则直接进行过滤，否则，将该执行结果标记为需要手工分析的结果并同步更新到误报过滤数据库中。

其中：错误类型指差分测试结果的类型，通过判断多个编译器对同一测试用例的执行情况得到。

第二关键报错信息指采用第二正则表达式对编译器的执行报错信息进行正则规范化多得到的规范结果，第二正则表达式与第一正则表达式的区别是：相比第一正则表达式，第二正则表达式更加完善，可以从执行结果中提取更详细的关键输出信息。第二正则表达式根据人工分析可疑执行结果时，依据分析经验手工建立起来的。

相关API是指测试用例中包含的编程语言的API，API的获取是通过分析报错信息和查询API列表得到的；首先解析出可疑执行结果中的出错代码行，找到可疑用例中对应的代码，将其解析为语法树；通过遍历语法树，并查询API列表，得到API的相关调用；API列表需要根据编程语言的语法特性手工总结。

依据这四个过滤指标，即可完成可疑执行结果的过滤，保证了每一种可疑结果只被分析一次，避免了在误报结果中浪费过多的分析时间，极大地提高了发现编译器漏洞的效率。根据统计，采用这种方法，可疑执行结果的误报过滤率达到了74.6％，节省了近4倍的用例分析时间。

在进行误报过滤后，本发明进一步对未过滤掉的可疑执行结果进行人工分析，挖掘编译器的漏洞。在进行分析时，可参考针对编程语言设计的实现规范，例如C语言的C11标准，JavaScript语言的ECMA-262标准。

实施例：

该实施例的多个被测试编译器为10个JS引擎，其名称分别为：V8、 SpiderMonkey、ChakraCore、JavascriptCore、Hermes、Quickjs、JerryScript、 Rhino、Nashorn和Graaljs；

在本实施例中测试集的构建方法是：以test262测试集及V8, ChakraCore,JavaSctiptCore,Hermes,JerryScript,Rhino六个JS引擎的回归测试用例集作为语料库，利用GPT2模型生成了256023条测试集用例。

在本实施例中，实验平台是一台搭载了主频3.30GHz的Intel i9-9940X 处理器和Ubuntu 18.04(内核版本5.4.0)操作系统的高性能服务器。服务器内存为128GB，图形显示卡为三张RTX 2080Ti。

采用本发明的方法对上述被测试编译器进行测试：

对10个JS引擎进行了长达15天的差分测试，在进行差分测试时，该实施例将投票机制的阈值默认设定为60％(即为多数)，即对测试集中的每一个测试用例，利用10个编译器进行测试，有6个以上的编译器执行结果一致，此执行结果将被视为正确结果，与此结果不一致的执行结果标记为可疑结果，相对应的测试集用例标记为可疑用例；

在进行可疑用例精简时该实施例采用Esprima提供的API将一段 JavaScript代码解析成节点语法树；

一个JS引擎的测试用例基于语法块精简的情况，基于从右向左，从大 到小的精简方案，首先会提取到用例(a)的语法树(如图3所示)，并将 其分为四个语法模块，包括三个变量定义模块，以及一个语句表达式模块， 此时，从右向左依次遍历四个模块，可完成对第四个模块print函数的精简； 然后再遍历第一个语法模块的子树，继续完成对prefix变量定义的精简， 其余的模块均不可删除。最终，经过转换得到精简后的用例(b)。

用例(a)：

用例(b)：

该实施例设计的四个第一正则表达式如下：

regex_error＝"(([a-zA-Z]*Error|timeout):.*？)(\\.\\s|\\n|\\.$)"

regex_hermes_error＝"(error:.*？)(\\.|\\n|\\.$)"

regex_note＝"(note:.*？)(\\.\\s|\\n|\\.$)"

regex_elegent＝"[a-zA-Z]+Error:.*"

这四个正则表达式可以匹配到JS引擎可疑用例的执行结果中的第一关键报错信息。

该实施例的误报过滤处理过程中，共定义了23个第二正则表达式完成报错信息的规范化，其中的9个正则表达式示例如下：

regex1＝"^TypeError:{var}is not an Object$"

regex2＝"^TypeError:{var}is null$"

regex3＝"^TypeError:Unable to delete property'{var}$"

regex4＝"^ReferenceError:{var}is not defined$"

regex5＝"^SyntaxError:Invalid regular expression:{var}$"

regex6＝"^TypeError:Cannot set property'{var}'of null$"

regex7＝"^ReferenceError:Property'{var}'doesn't exist$"

regex8＝"^ReferenceError:Can't find variable:{var}$"

regex9＝"^TypeError:{var}is undefined$"

利用第二正则表达式可以匹配到JS引擎可疑用例的执行结果的第二关键报错信息。

该实施例通过手工解析ES2019标准和MDN文档得到了共计415个API，共分为类方法、构造方法、原型方法和其他方法四种类型；API列表中的7 个API示例：

Array.prototype.fill()

Date.prototype.getUTCDate()

Number.prototype.toString()

String.prototype.match()

Math.abs()

Number()

escape()

该实施例定义了三种错误类型，分别包括：可疑执行结果包含错误信息，错误类型为“1”；可疑执行结果不包含错误信息，而其它大多数编译器执行结果包含错误信息，错误类型为“2”；可疑执行结果不包含错误信息，且其它大多数编译器执行结果也均不包含错误信息，但可疑结果与大多数执行结果不一致，错误类型为“3”。

该实施例关键报错信息获取示例：一条v8引擎对于一个测试用例的原始报错信息如下：

经过第二正则表达式规范化，去除冗余部分，提取关键信息，转换为了其关键报错信息：

RangeError:toString()radix argument must be between 2and 36

经过用例精简和误报过滤，得到包含7880个可疑用例的可疑用例集；

经过统计，25万多条的测试集用例在执行过程中，按照执行结果，共组建了一个包含7907条记录的执行结果集，其中用例被过滤的次数之和高达31143次，即共过滤掉23236次误报，过滤率高达74.6％；

所构建可疑用例集和执行结果集中包含7907条需要进行人工分析的数据。

该实施例参考ECMA-262标准文档，对人工分析集进行分析，寻找编译器的bug。ECMA-262标准对String.prototype.search函数的定义示例：

经过人工分析后，最终在其中的4个JS引擎上共发现20个bug，如表 1所示，其中被引擎厂商确认的有15个，确认且被修复的有12个。

表1发现bug情况

JS引擎	提交数量	确认数量	修复数量
				ChakraCore	3	2	2
JavaScriptCore	2	2	1
				JerryScript	6	5	5
Rhino	9	6	4
				总计	20	15	12

引擎厂商确认为bug的测试用例示例：

一个JavaScriptCore引擎关于Array.prototype.push函数的bug

测试用例1：

var array＝[0,1,2]；

var str＝"asdadc"；

Array.prototype.push.apply(str,array)；

print(str.length)；

print(str)；

在执行该测试用例时，JavaScriptCore引擎输出了6和“asdadc”，按照ECMA-262标准规定，Array.prototype.push函数在实现时会触发this 对象length属性值的改变，而string类型的length属性值是不能被改变的，故JS引擎对该用例正确的执行结果应该是抛出TypeError错误。此bug 被已经被JavaScriptCore开发人员确认并修复。

一个JerryScript引擎关于Object.getOwnPropertySymbols函数的 bug

测试用例2：

varNISLFuzzingFunc＝function(){

var p＝true；

Object.getOwnPropertySymbols(p)；

}；

NISLFuzzingFunc()；

在执行该测试用例时，JerryScript引擎抛出了TypeError错误，提示Object.getOwnPropertySymbols函数的参数类型不是一个object类型。而根据ECMA-262标准规定，当Object.getOwnPropertySymbols函数的参数不是object类型时，应首先将其转换为object类型，而不是抛出错误。此 bug已经被JerryScript的开发人员确认并修复。

Claims (6)

1.一种基于代码精简与误报过滤的编译器模糊测试方法，其特征在于，包括：

(1)构建多个被测试编译器的测试集；对测试集中的各测试集用例进行差分测试；对于每一个测试集用例，将其同时输入多个被测试编译器中进行差分测试，将出现编译器崩溃或超时执行的测试集用例和差分测试结果为多数编译器执行结果相同和少数编译器执行结果不同的将测试集用例标记为可疑用例；

(2)对所有可疑用例进行精简处理；对于每一个可疑用例，对该可疑用例进行语法树解析，如该可疑用例可以被解析则基于语法子树进行精简，否则基于代码行进行精简；所有精简后的可疑用例构成可疑用例集；

所述基于语法子树进行精简包括：

对解析出的语法树的各语法子树依次进行删除，删除顺序包括：先删除隶属当前语法树根节点的语法子树；对于当前语法树根节点有多个语法子树的情况，从右自左依次删除；

对于每一个语法子树，先初步删除该语法子树，每初步删除一个语法子树后，将进行初步删除后的可疑用例同时输入多个编译器中，对不改变执行结果的语法子树进行最终删除；所述不改变执行结果为出现步骤(1)少数情况的编译器不变；

所述基于代码行的精简包括：

从下到上依次删除一行代码，对于每一代码行，先初步删除该代码行，每初步删除一个代码行后，将进行初步删除后的测试集用例同时输入多个编译器中，对不改变执行结果的代码行进行最终删除；所述不改变执行结果为出现步骤(1)少数情况的编译器不变；

(3)对于步骤(1)中所有可疑用例的少数编译器执行结果进行误报过滤处理；对于每一个执行结果，获取该执行结果对应的编译器名称或编号、该执行结果的错误类型、该执行结果的关键报错信息和该执行结果的相关API，判断所得编译器名称或编号、错误类型、关键报错信息和相关API在误报过滤数据库中是否作为同一条记录存在，如存在则过滤掉该执行结果，否则将该执行结果对应的编译器名称或编号、错误类型、关键报错信息和相关API作为一条记录，保存至误报过滤数据库中；误报过滤数据库初始为空；所有执行结果误报过滤完成后得到的误报过滤数据库构成执行结果集，执行结果集中的每条记录对应一个可疑用例；

所述错误类型至少包括：类型一：执行结果包含错误信息、类型二：执行结果不包含错误信息；

所述关键报错信息为采用第二正则表达式对执行结果进行正则规范化后得到的规范结果；

可疑用例集与执行结果集构成被测试编译器的人工分析集。

2.如权利要求1所述的基于代码精简与误报过滤的编译器模糊测试方法，其特征在于，所述编译器执行结果根据执行进程的返回值确定。

3.如权利要求1所述的基于代码精简与误报过滤的编译器模糊测试方法，其特征在于，所述语法树解析采用Esprima语法解析器、Clang语法解析器或ast语法解析器进行解析，这些语法解析器均包含能够将代码解析为抽象语法树的API，直接调用API即可完成语法树解析。

4.如权利要求1所述的基于代码精简与误报过滤的编译器模糊测试方法，其特征在于，所述不改变执行结果为出现步骤(1)少数情况的编译器不变或/和第一关键输出信息不变，所述第一关键输出信息指采用第一正则表达式对可疑用例的执行结果进行正则规范化后得到的规范结果。

5.如权利要求4所述的基于代码精简与误报过滤的编译器模糊测试方法，其特征在于，所述第一正则表达式与第二正则表达式相同。

6.如权利要求1所述的基于代码精简与误报过滤的编译器模糊测试方法，其特征在于，还包括：对所述被测试编译器的人工分析结果集进行人工分析确定被测试编译器的漏洞。

Images