基于二进制代码特征的第三方组件漏洞检测方法与流程

本发明涉及一种第三方组件漏洞检测方法，尤其涉及一种基于二进制代码特征的第三方组件漏洞检测方法。

背景技术：

目前大多数的软件应用，无论是移动应用还是桌面应用，为了降低开发成本、提高开发效率，或多或少都使用了开源代码用于接口或功能的开发。开源代码引入软件项目的途径是多种多样的，直接将开源代码引入项目作为软件功能的一部分是最常见的一种情况，另外，软件研发人员有时会使用某些商业组件。

开源组件大多经过封装后，为用户提供相应的接口、属性和方法，用户能够使用组件却无法看到源代码。使用开源组件的研发者将重心放在了组件的功能上，很少会有人对其进行深入研究，关心其是否存在安全问题。然而，根据cve统计，开源组件时常被曝光存在安全漏洞，进而导致使用该组件的软件产品存在潜在安全隐患。例如，在2014年4月8日被曝光的opensslheartbleed漏洞(cve-2014-0160)，允许攻击者窃听通信、窃取数据，影响版本有openssl1.0.2-beta和openssl1.0.1-openssl1.0.1f，如果开发者使用了这些版本的openssl，便存在严重的安全漏洞。

此外，开源组件包含自己的开源许可协议，在其使用过程中，会有一定的约束和限制。任何使用开源组件的个人或单位组织，都必须遵循相应开源许可协议的规定，否则将存在侵权的法律风险。目前流行的开源许可协议已经有近百种，其目的是保护开源项目的知识产权状况和原著作者的合法权益。

使用开源代码确实可以提高研发者的工作效率，同时达到了知识共享与发展的目的。但是，由于一些开源代码使用者没有遵循其包含的开源协议，尤其是一些开发商，在部分商用的软件产品或组件中使用开源代码，却没有向客户透漏相关信息，这种情况会导致开发者对自身项目的开源代码使用情况造成误判。美国blackduck公司在2016公布的数据中我们可以得知，平均每个现代应用使用了105个开源组件，比开发者自认为使用的开源组件的数目多了基本一倍。

目前对于软件程序成分检测的现状来看，主要依赖于程序分析方法，主要可以分两大类：静态分析和动态分析。静态分析主要在不执行程序代码的情形下对源代码或编译后二进制文件进行分析，基本可以覆盖全部的代码路径。动态分析方法主要是对程序运行过程中的监控检测与调试，结果通常比静态分析方法更加准确，但其缺点是很难覆盖所有的代码执行路径，需要大量的工作去创建测试用例。两类分析方法都有各自的优缺点，相互弥补。

对于开源代码来源检测，目前大多数的研究是基于源代码的静态检测方法，通常用于代码的克隆检测，目前主要可以归为基于文本、基于词法、基于语法和基于语义这四类检测方法，但是对于海量数据下如何从二进制文件中高效检测开源组件，公开的技术资料中少有涉及，因此这方面的研究很有价值。

有鉴于上述的缺陷，本设计人，积极加以研究创新，以期创设一种基于二进制代码特征的第三方组件漏洞检测方法，使其更具有产业上的利用价值。

技术实现要素：

为解决上述技术问题，本发明的目的是提供一种基于二进制代码特征的第三方组件漏洞检测方法。

本发明的基于二进制代码特征的第三方组件漏洞检测方法，其中：

步骤一，抽取第三方组件的多维度特征，构建第三方组件的特征库。步骤二，抽取待检测文件的二进制代码特征，搜索匹配到相应的第三方组件。步骤三，根据更细维度的特征，确定组件版本号。

进一步地，上述的基于二进制代码特征的第三方组件漏洞检测方法，其中，所述步骤一中，抽取第三方组件中的二进制代码特征，选择从源代码与编译到二进制代码这一过程中的不变量，存储于特征库中，所述不变量包括常量字符串、数字常量、函数签名数字化向量中的一种或是多种。

更进一步地，上述的基于二进制代码特征的第三方组件漏洞检测方法，其中，所述步骤一中，根据第三方组件源码的语言类型，选择对应的词法分析器抽取字符串常量和数字常量特征，所述词法分析器，根据源代码语言类型，从源文件中提取字符串常量及数字常量特征，并将其作为主键，包含该特征的组件列表作为值，存储于倒排索引的特征库中。

更进一步地，上述的基于二进制代码特征的第三方组件漏洞检测方法，其中，所述语法分析器，分析每一个文件包含的函数个数，每一个函数包含的参数个数，形成一个数字向量，同样存储于特征库中。

更进一步地，上述的基于二进制代码特征的第三方组件漏洞检测方法，其中，所述步骤二中，通过定位jump指令，并查看参数压栈条数，得出函数签名的数字化常量特征。

更进一步地，上述的基于二进制代码特征的第三方组件漏洞检测方法，其中，所述步骤二中，对每个匹配到的特征评分，再对每一个找到特征的组件，将其所有特征的评分加起来作为组件评分，采用如下公式：

其中，s为找到的特征，length(s)是特征字符串的长度，pkg(s)为包含s的开源组件数目，α是一个常量，当包含s的组件数目提升时，分母数值会快速提升，分数快速降低。

再进一步地，上述的基于二进制代码特征的第三方组件漏洞检测方法，其中，所述步骤三中，通过进一步细粒度，匹配不同版本的控制流程图。

借由上述方案，本发明至少具有以下优点：

将搜索引擎中采用的倒排索引以及打分排名的方式，应用到特征匹配这一过程中，提高海量第三方组件的检测效率，实现快速检测二进制代码中使用的第三方组件。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下以本发明的较佳实施例并配合附图详细说明如后。

附图说明

图1是基于二进制代码特征的第三方组件漏洞检测方法的流程示意图。

图2是基于二进制代码特征的第三方组件漏洞检系统结构示意图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

如图1、图2的基于二进制代码特征的第三方组件漏洞检测方法，其与众不同之处在于包括以下步骤：

首先，抽取第三方组件的多维度特征，构建第三方组件的特征库。具体来说，抽取第三方组件中的二进制代码特征，选择从源代码与编译到二进制代码这一过程中的不变量，存储于特征库中，不变量包括常量字符串、数字常量、函数签名数字化向量中的一种或是多种。在此期间，根据第三方组件源码的语言类型，选择对应的词法分析器抽取字符串常量和数字常量特征。在实施期间，可通过语法分析器，抽取函数签名数字化向量。本发明采用词法分析器，可根据源代码语言类型，从源文件中提取字符串常量及数字常量特征，并将其作为主键，包含该特征的组件列表作为值，存储于倒排索引的特征库中。并且，采用的语法分析器，在处理期间，分析每一个文件包含的函数个数，每一个函数包含的参数个数，形成一个数字向量，同样存储于特征库中。

结合实际的实施过程来看，基于倒排索引的特征数据库的表结构如下t_signature表所示：

hbase是采用keyvalue的列存储，根据rowkey(主键)来进行查询检索，通过找到某个rowkey(或者其范围)所在的region，然后将查询请求转发到该region获取目标数据，rowkey最长支持64kb。

为了保持hbase的读性能，其主键长度不易过长，然而开源代码中的常量字符串特征有时会过长，需进行分段处理，对于长度超过32kb的特征，设其长度为xkb，可将其均分为x/32段，分别存入hbase以待检索。

之后，抽取待检测文件的二进制代码特征，搜索匹配到相应的第三方组件。由于二进制文件格式中存在一个“常量区”的概念，因此抽取出字符串常量和数字常量比较容易。而对于函数签名数字化常量来说，由于汇编代码中函数调用时会进行参数传递到特定寄存器，然后通过jump指令跳转到函数代码位置去执行相应逻辑。在处理期间，通过定位jump指令，并查看参数压栈条数，得出函数签名的数字化常量特征。

为了提高特征找寻的精确度，可对每个匹配到的特征评分，再对每一个找到特征的组件，将其所有特征的评分加起来作为组件评分，采用如下公式：

其中，s为找到的特征，length(s)是特征字符串的长度，pkg(s)为包含s的开源组件数目，α是一个常量，当包含s的组件数目提升时，分母数值会快速提升，分数快速降低。值得一提的是，当一个特征在同一个开源组件中被找到多次时，当作一次匹配处理。同时，这种评分方式可以充分利用倒排索引的匹配特点，提高效率，并且不会进行特征去重而导致丢失特征信息。

随后，根据匹配到的所有组件的分数进行排名，设置阈值来截断排名列表。在阈值之上的，可以认为其存在与该二进制待检测文件中。通过控制打分参数α和阈值threshold来控制该检测算法的精度。

接着，根据更细维度的特征，确定组件版本号。在此期间，通过进一步细粒度，匹配不同版本的控制流程图(cfg)。

由此，实现基于倒排索引的打分排名算法。基于倒排索引的打分排名算法，根据特征来定位不同的第三方组件，通过分数来量化匹配程度，最后通过调节打分参数和阈值来控制精度。使得检测算法只跟待检测文件中的特征数量有关，不随特征库的规模增大而增加。若基于传统的正排索引，对整个特征库中的特征构建前缀树trie，逐一匹配或计算相似度。这样随着特征库的扩大，检测算法耗时将越来越久。

结合本发明一较佳的实施方式来看，

步骤(1)：建立第三方组件特征库与组件信息库。

在这一步骤中，我们需要获取第三方组件的源码或者二进制代码，以及证书信息、漏洞信息等有效信息。其中组件信息存储的字段如下：

而组件特征抽取，我们主要抽取常量字符串特征，辅以控制流图(cfg)等特征信息以及函数向量特征。

选择常量字符串特征作为主要特征，主要是由于其具有如下的优点：

(1)提取过程简单高效，可以从源代码中或者编译后的二进制代码中提取。从源代码中提取可以实现自动化，迅速扩充特征库。

(2)由于不需要开源组件被编译，常量字符串特征是独立于操作系统、编译器和处理器架构的，应用范围广，对于不同操作系统的应用，甚至是移动平台程序，如android应用，都是可以检测的。

(3)常量字符串通常是跨版本通用的，往往一个开源组件不断更新的过程中，它很多的常量字符串也是不变的。

基于常量字符串特征的检精度依赖于足够的特征质量。如果开源组件中包含很少的字符串或者包含的字符串都很短，没有辨识度，那么常量字符串特征会难以生效或者产生误报。

将常量字符串特征从第三方组件中抽取出来后，按照倒排索引的方式存储于hbase中，存储格式如下：

步骤(2)：实现第三方组件检测的核心检测算法。

对于一个待检测文件，首先我们抽取出其中所包含的所有常量字符串的集合s，然后对s中的每一条常量字符串str来搜索匹配我们特征库中的组件，按照公式1来进行为包含该特征的待匹配组件加上相应的分数：

对中所有的常量字符串都进行了一遍搜索匹配之后，根据参数α和threshold的值来进行过滤，得分在threshold之上的组件，该检测算法认为其包含于待检测文件中。由于运用倒排索引的存储，因此查找常量字符串我们认为是与特征库规模无关的常量时间内完成。因此总的时间复杂度为o(m)，其中m为待检测文件中抽取出的常量字符串特征的数量。

本发明的工作原理如下：

基于字符串匹配算法和基于倒排索引匹配的特征存储方式各有利弊，在检索速度上前者不如后者，但是在特征的删除或修改上后者比较麻烦，如果要删除某个开源组件的所有特征，则需要遍历整个特征库。然而，特征的删除和修改工作通常比较少，而且对用户的使用没有直接影响，因此基于倒排索引匹配的特征存储方式更合适实际使用。

使用倒排索引匹配有个前提是，二进制可执行文件必须可以独立提取出特征，然后将特征分别在倒排索引数据库中搜索。因此不可以直接使用二进制文件的字节流，而是提取出二进制文件的常量字符串作为待匹配特征。

具体来说，打分排名算法是在开源组件的源代码中可以提取出众多常量字符串特征，其中很多特征包含于所个组件之中，例如“outofmemory”、“outofmemory”、“％s”这种常量字符串会经常出现。因此需要一个组件的评分标准，在找到诸多潜在的开源组件后，通过匹配过程中的信息为每个开源组件进行评分，再通过一个阈值进行筛选，这样便可以减少大量的误判。

在基于字符串匹配算法(包括多模式匹配)的匹配过程中，逐个匹配每个组件，可以得到每个组件匹配到的特征，由于每个组件的总特征数不一样，因此本文不使用匹配到的特征数目作为评分，而是使用匹配到的特征数目占总特征数的比例作为评分，范围从0到1。另外，如果总特征数太少，导致匹配到的特征数目很少时也评分很高，是不合理的，因此设定一个匹配特征数目的门槛值α，当数目低于α时，评分为0。基于字符串匹配算法(包括多模式匹配)的匹配评分公式见公式4-3。

开源组件之间的相同特征会影响该评分公式的使用效果，如果对所有组件的特征进行去重后，会显著提升检测准确性。在不同的去重率下，我们需要对匹配特征数目的门槛值α和评分阈值进行调整。

在基于倒排索引的特征匹配过程中，本发明使用了评分公式(公式4-4)对每个匹配到的特征评分，再对每一个找到特征的组件，将其所有特征的评分加起来作为组件评分。这种评分方式可以充分利用倒排索引的匹配特点，提高效率，并且不会进行特征去重而导致丢失特征信息。

其中s为找到的特征，length(s)是特征字符串的长度，pkg(s)为包含s的开源组件数目，α是一个常量，当包含s的组件数目提升时，分母数值会快速提升，分数快速降低。值得一提的是，当一个特征在同一个开源组件中被找到多次时，当作一次匹配处理。

当开源组件库中存在内部克隆现象时，会导致评分失效。例如组件a包含了组件b，如果待检测文件使用了组件b，在计算评分的时候，组件a的评分也会很高，导致误判。

最佳的解决办法是检测开源组件库内部的克隆现象，有针对性的划分特征归属，可以利用现有的基于源代码的克隆检测方法进行检测。不过，这种方法开销很大，可以采用另外一种折衷的办法：在添加开源组件特征时，如果两个组件的特征重复比例超过一个阈值(代表存在克隆现象)，那么重复部分的特征归属于独立特征少的组件。

简单来说，组件a包含了组件b，组件a必然有组件b之外的代码实现其它功能，组件a也就包含着比组件b多的独立特征，两者重复的特征很大概率是属于组件b的。我们利用这一特性，在建立特征库时，就可以检测出自克隆问题，从而保证特征库中，组件之间不会存在自克隆问题。

在实际实施时，可将本发明实施的方式结合到基于二进制的开源组件来源检测系统中。

通过上述的文字表述并结合附图可以看出，采用本发明后，拥有如下优点：将搜索引擎中采用的倒排索引以及打分排名的方式，应用到特征匹配这一过程中，提高海量第三方组件的检测效率，实现快速检测二进制代码中使用的第三方组件。

以上所述仅是本发明的优选实施方式，并不用于限制本发明，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变型，这些改进和变型也应视为本发明的保护范围。