CN111931181B - 基于图挖掘的软件逻辑漏洞检测方法 - Google Patents

Abstract

本发明公开了基于图挖掘的软件逻辑漏洞检测方法，侧重于解决基于SSL/TLS协议软件库的软件逻辑漏洞的检测问题，涉及到漏洞逻辑规则的提取、客户端软件的静态分析与建模；本发明提升了静态分析过程在逻辑漏洞领域的可用性和易用性，针对研究目标简化了应用源程序的表征规模，同时定义一种适合逻辑漏洞检测的抽象建模方式，以丰富语义的系统属性图来对源程序进行描述；本发明还指明了如何在图挖掘技术的支持下进行预定义漏洞规则的匹配来发现潜在的逻辑漏洞，并且能够保证一定的效率。

Description

基于图挖掘的软件逻辑漏洞检测方法

技术领域

本发明属于软件安全的技术领域，具体涉及一种基于图挖掘的软件逻辑漏洞检测方法。

背景技术

使用SSL/TLS协议可以为通信提供安全性保障以达到可认证性和保密性要求，目前主流的使用方法都是借助于OpenSSL、GnuTLS及JSSE等开源协议软件库包来简化开发流程，但这种简化并不能确保基于协议软件库开发的应用程序都是安全的，目前很多软件仓库发行版中的客户端软件依然存在着身份认证相关逻辑漏洞。漏洞的动态分析技术在实践过程中受影响因素太多，不确定性高，此外也不能保证对源码的测试覆盖率；传统的基于二进制漏洞检测缺乏上层的代码结构信息和类型信息故而分析难度大；基于源代码逻辑推理的漏洞检测方法使用到数学推理和证明，但难以对复杂漏洞逻辑进行检测；基于代码相似性的表征包括了文本、度量、标记、树、图表这5种方式，前三种对软件漏洞的描述能力非常不全面且限制条件过多。所以目前树和图更适合用于研究逻辑漏洞模式特征。

发明内容

有鉴于此，本发明提供了一种基于图挖掘的软件逻辑漏洞检测方法，能够实现特定逻辑漏洞的准确检测，并且具有通用性。

实现本发明的技术方案如下：

基于图挖掘的软件逻辑漏洞检测方法，包括以下步骤：

步骤一、加载客户端软件源代码，构建基于源码的抽象语法树(AST)、控制流图(CFG)和程序依赖图(PDG)这三种中间表示，并将AST优化处理获得简化型抽象语法树(SAST)，将PDG增强处理获得增强型程序依赖图(EPDG)；

步骤二、将步骤一获得的SAST、EPDG连同CFG一起整合构建出系统属性图(SPG)，然后将SPG存储到图数据库中；

步骤三、对SSL/TLS协议软件库接口的正确使用模式进行抽象提取，得到接口逻辑规则；

步骤四、将步骤三中的接口逻辑规则采用人工分析的方式，手动构建遵循 SPG规范的图模型；

步骤五、用CQL语言编码步骤四的图模型，在图数据库中将编码后的图模型与步骤二所得的SPG执行规则进行匹配，若匹配成功，则该图模型就是客户端软件SPG的子图，即满足接口逻辑规则而无逻辑漏洞；否则，客户端软件存在逻辑漏洞。

有益效果：

本发明基于软件建模和图挖掘技术，提出了一种专门用于检测SSL/TLS协议软件库接口调用相关逻辑漏洞的新方法。

1、本发明对现有的基于源代码的表征方式进行改进，对抽象语法树和程序依赖图进行了优化处理，在此基础上提出了一种由三类中间表示联合构建出的新型图模型SPG。SPG能够覆盖到检测过程需要的所有语义和结构信息，非常适合对协议软件库的复杂逻辑漏洞得规则进行表征，应用到软件建模中可以极大地方便后续的规则匹配过程。

2、本发明提出了一种针对特定逻辑漏洞的检测方式，检测的结构基础是系统属性图，检测的对象是存储在图数据库中的源码的系统属性图。首先把开发过程中接口的正确调用逻辑提取出来，再按照系统属性图的标准进行构建，获得的是各客户端中特定功能模块系统属性图的子图形式，利用CQL语言描述该子图形式，即可在图数据库上进行规则匹配。该匹配检测方式是目前效率较高的途径，配备达到性能要求的处理器与GPU，即可使得最耗时的部分工作自动化执行，且该方法准确率高。

附图说明

图1为本发明方法流程图。

图2为SPG的构建过程示意图。

具体实施方式

下面结合附图并举实施例，对本发明进行详细描述。

本发明提供了一种基于图挖掘的软件逻辑漏洞检测方法，侧重于解决基于 SSL/TLS协议软件库的软件逻辑漏洞的检测问题，涉及到漏洞逻辑规则的提取、客户端软件的静态分析与建模。本发明提升了静态分析过程在逻辑漏洞领域的可用性和易用性，针对研究目标简化了应用源程序的表征规模，同时定义一种适合逻辑漏洞检测的抽象建模方式，以丰富语义的系统属性图来对源程序进行描述。本发明还指明了如何在图挖掘技术的支持下进行预定义漏洞规则的匹配来发现潜在的逻辑漏洞，并且能够保证一定的效率。

本发明所检测的目标软件都是C语言开发的客户端软件，具体的检测流程如图1所示，包括以下步骤：

步骤一、加载客户端软件源代码，构建基于源码的抽象语法树(AST)、控制流图(CFG)和程序依赖图(PDG)这三种中间表示，并将AST优化处理获得简化型抽象语法树(SAST)，将PDG增强处理获得增强型程序依赖图(EPDG)；

源码的AST简化处理：AST中很多变量节点造成了树结构的复杂化，不同于函数名称、数据类型名称和语句类型名称，变量名称是由开发者自由设定的，同样上下文环境下的同类型的变量可能因为不同开发者而使用不同标识符进行命名，这些无意义命名会影响AST的结构，为了能够降低AST的复杂性，本发明将AST中代表变量的节点中相同类型的那些节点都替代以类型名标记来达到简化的效果。

简化型抽象语法树：在软件源代码静态分析获得的抽象语法树(AST)内，若多个变量节点的code键对应的属性值所表示变量数据结构类型相同，将变量节点进行属性替换，将其code属性内的变量命名替换为数据结构类型名的大写，即得简化型抽象语法树。

源码的PDG增强处理：PDG图中能够直观展示控制依赖和数据依赖，但这些依赖关系都是直接依赖，从PDG中无法直接获得有关同一个关键性变量在其他哪些语句中也被使用，本发明使用共享数据依赖边来对PDG的边集作更深入的优化，使得程序源码元素的一些语义关系能被更精确地建模表示。相比于其他研究中定义的SDDE，本发明添加了一个限制条件保证两节点间只在没有数据依赖边的前提下才会添加SDDE，减小了边的复杂程度，为程序的过程间分析提供了一定的便利，同时也能保证漏洞检测环节的图挖掘过程不受影响且提高一定效率。不同于SDDE带来的语义扩展表达，PDG图中还有相当数量的节点和边是冗余的，而漏洞静态分析并不会关注与结构、语法不相干的冗余节点。初始PDG中会引入系统节点等来辅助生成工具执行，系统节点所及其引出的边、辅助参数节点相关的边、地址依赖边，本发明一并约减处理。

共享数据依赖边：如果程序依赖图G中某个变量var定义在节点Z处，节点P和节点Q都数据依赖于节点Z且使用到相同的变量var，同时节点P、Q之间没有直连的数据依赖边，但相应控制流图中有从P到Q的控制路径，那么添加一条有向边(P,Q)到节点P、Q之间以连接，这条边称为共享数据依赖边。

增强型程序依赖图：在程序依赖图中添加共享数据依赖边，同时约减处理 PDG的系统节点及其引出的边、辅助参数节点相关的边、地址依赖边等，所得为EPDG。

步骤二、将步骤一中优化处理获得的SAST、EPDG连同CFG一起整合构建出系统属性图(SPG)，然后将SPG存储到图数据库中；

图2是针对应用程序源代码作一步步分析构建出SPG过程图，其中数字序号表示了构建的顺序，作为多个表征形式的联合，SPG具备了表征程序语法、结构、依赖关系、控制流等信息的能力。

系统属性图：SAST、CFG和EPDG是构建SPG的基础，将SAST、CFG和 EPDG的属性图分别表示为(N_S,B_S,f_S,g_S)、(N_C,B_C,f_C,g_C)、(N_E,B_E,f_E,g_E)。其中的f 和g分别是标记函数与属性函数，N和B分别是各个中间表示的节点集与边集。定义系统属性图SPG为(N,B,f,g)，SPG需要满足的条件如下：

①N＝N_S；

②B＝B_S∪B_C∪B_E；

③f＝f_S∪f_C∪f_E；

④g＝g_S∪g_E

系统属性图的特征：SPG是综合SAST、CFG、EPDG这几个图结构而建立出的全局视图，相比于这些基于底层代码的唯一性视图，SPG具备更全面的表征能力，在这种丰富语义的基础上，我们可以采用一些常见图挖掘模式来发现漏洞。SPG的节点构成以AST节点为主，各节点都具有多个属性。将code属性为PRED、DECL等位于控制流路径上的节点称为主干节点，主干节点作为原 SAST树的节点，会连接上操作数、运算符等其他SAST节点，同时也是控制流路径上的节点以及PDG各依赖边相互连接交汇的节点。SPG图中不同的节点使用属性值来相互区分，ENTRY和EXIT属性存在于常见的入口出口节点，DECL 属性值存在于变量的声明语句，PRED属性存在于谓词表达式，CALL属性则对应着函数调用语句。

系统属性图的结构：SPG的边包括了SAST边、控制流边、三类依赖边等。边标记是将图中边的类型作为依据，用“A”标记抽象语法树的边，用“F”、“true”、“false”分别标记控制流边的直接执行边、谓词值为真或假的流向边，用“D”标记数据依赖边，用“S”标记共享数据依赖边，用“Ctrue”标记控制依赖边。控制流边将主干节点进行了连接，表达语句的执行关系，从ENTRY出发直到EXIT结束，遇到谓词表达式后会分出两条边；SAST边连接着很多节点，SAST节点是SPG 的节点构成来源；依赖边主要来自EPDG，控制流边以及依赖边一样仅仅连接主干节点。主要关注的变量在其他语句内被使用都会通过数据依赖边进行连接，而共享数据依赖边只描述了特殊的对某个数据的共享关系。

系统属性图的构建：联合处理获得SPG首先要从SAST的属性图(N_S,B_S,f_S,g_S) 开始，借助DMS对树结构添加创建与根节点相连的文件节点的相关规则，帮助表征项目文件的层次，联合过程的一些处理和最后的整合使用到了joern工具， joern的命令行支持编写PDG、CFG的处理规则。需要使用g_S来为特定节点分配一个属性tip，使得节点上的属性能使其与操作符、常量以及变量节点可以相互对应，再给每个节点赋予第二个属性note，用于对SAST结构有序性进行描述，这两个辅助属性便于对方法的声明节点处所用修饰符以及代码位置、行号等信息精确指定。而CFG属性图(N_C,B_C,f_C,g_C)中控制流边标记函数f_C会对满足ΣC＝ {F,true,false}的边集做标签化，通过执行EPDG属性图(N_E,B_E,f_E,g_E)的三种依赖关系标签化处理，可以使得SPG中主干节点都被分配相应的属性符号和条件，其中属性条件用于描述谓词真假值的不同情况，Σ_P＝{D,S,C}中分别对应这三种依赖关系，使用标签函数f_E:E_E→Σ_E来对EPDG的边做最后处理。

步骤三、对SSL/TLS协议软件库接口的正确使用模式进行抽象提取，得到接口逻辑规则；

漏洞模式：很多传统的软件漏洞往往会抽象成漏洞特征，进而被应用到基于特征的匹配技术中，现今的很多检测工具也是在不断完善自身的漏洞特征库，早先的漏洞特征提取技术往往是通过分析应用程序在某些连接请求或模拟攻击情况下的响应信息。漏洞特征的定义和入侵检测技术也息息相关，检测水平往往是由误报率和漏报率来评估。

接口逻辑规则：在应用程序中调用的某些接口需要按照一定的组合顺序或特定的使用模式，才能达到其起初设计的功能，这种对接口使用模式或组合顺序的正确性要求就是接口逻辑规则。与大多数静态检测方法直接构建漏洞的模型不同，由接口的错误组合调用引起的逻辑漏洞所对应的错误模式情况繁多，而接口调用的有效和正确的模式往往很少。而这类正确规则需要开发者在代码编写和功能扩展时严格遵守，需要按照规则来调用接口和编程。

OpenSSL库的主机名验证规则分析:主机名验证的核心就是比较X.509证书中subject字段的CN属性与服务端主机名，验证结果可以告知客户端其收到的证书是不是被颁给了当前请求的服务器。OpenSSL是在假设成功验证完证书链的前提下开展对主机名的验证，实际的验证过程需要客户端自主判定有效主机名是哪些以及主机名信息与证书中特定字段属性的匹配情况，本发明没有关注其中繁琐的细节性接口逻辑，只检查主要的验证接口是否正确使用。根据函数或数据结构的重要程度以及进行主机名验证过程是否必须执行来节选。

接口逻辑规则的提取分析：规则是以伪代码的形式来展示的，代码中保留了关键变量、方法、参数等信息，若要提取规则，需要将身份认证各个阶段中关键的接口组合及其顺序抽离并保存，以便于下一步的建模。以上述身份认证过程为例，首先初始化SSL库和注册算法，执行协议的初始化；接着确定会话过程所采用的SSL/TLS协议，协议是协商后确定的，并且服务端、客户端所选的协议要满足相互兼容的条件；然后申请SSL会话环境，使用不同协议会话环境也不相同；之后建立SSL套接字；然后完成SSL握手；接着获取服务端的证书到X509结构体中，可以从SSL套接字中提取对方的证书信息；随后查明证书是否通过了OpenSSL的检验；再获取证书颁发者相关的多种信息名称集合(其中包含了服务端证书的主机名信息)；之后将对主机名信息的匹配校验；接下来实现对套接字的读写操作来进行安全的数据传输过程；最后关闭SSL套接字，释放SSL套接字并释放SSL会话环境。以上14个步骤就可以按序组合出本方法所需要的接口逻辑规则。

步骤四、将步骤三中的接口逻辑规则采用人工分析的方式，来手动构建为遵循SPG规范的图模型，该图模型有可能是步骤二中SPG的子图；

接口逻辑规则的图模型：SPG中的节点具有非常多的属性，其中大多是从 SAST中继承下来的，本发明中接口逻辑规则对应的模式图只关注核心属性或标签的一部分。SPG图中控制流边连接的两端节点对应的语句或谓词在源码中可能是前后相邻的关系，也可能被其他一条或多条语句隔开，因为很多不太重要语句不是本发明所关注的，所以进行了省略，每个主干节点内除了属性值还标注了特定序号，以方便CQL查询。SPG的简化型抽象语法树边主要在SAST节点之间连接，SAST的节点对函数名、函数参数列表、操作数、运算符等都进行了表征。

人工构建方式：按照SPG的规范，将接口逻辑规则由代码形式手动作图获得其SPG图形式，并分别为节点、边赋予属性和标注标签。

步骤五、用CQL语言编码步骤四手动构建出的图模型，用于在图数据库中对步骤二所得的SPG执行规则的匹配，若匹配成功，则表示接口逻辑规则的图模型是客户端软件SPG的子图，即满足接口逻辑规则而无逻辑漏洞；否则，客户端软件存在逻辑漏洞。

CQL语言：类似于Oracle的数据库语言SQL，Neo4j使用CQL(Cypher QueryLanguage)作为其图数据库的声明模式匹配语言。

CQL编码：本发明通过编写CQL来描述出接口逻辑规则对应的SPG图模式，在存储了应用程序源代码SPG的Neo4j上执行CQL也就启用了模式在源码中的匹配，匹配成功则表示满足了接口逻辑规则，不存在相关逻辑漏洞，反之则有漏洞。由于很多应用程序代码量非常大，如果直接在源码的所有SPG图中执行接口逻辑规则模式图的匹配，将会非常耗时。为了提高匹配检测的效率，本发明首先将会话相关的代码段部分查询出来，在查询结果代码段的基础上再执行规则的匹配。

第一段查询：对软件源码的SSL连接会话进行的大致定位，找出协议的初始化，作为研究会话握手阶段的起始点，该函数所处的叶节点往主干方向可以追溯到语句节点，虽然SPG的图中使用的是属性值为CALL类型进行表示，表示该语句为函数调用，然而实际中可能有开发者在此处调用SSL_library_init函数的同时获取了返回值，那么语句类型将会发生改变，作为控制流路径上的语句节点，该主干节点的属性值也会发生变化。考虑到这个问题，本发明主要使用(head)-[:A*]->({code:SSL_library_init})这种方式来表述某个主干节点能够通过抽象语法树边到达函数名称所在节点，确定了函数名所在位置，也就能确定主干的语句节点是什么功能了。对于tail节点的判断主要看该节点是否执行了 SSL_read()或SSL_write的功能，由于不确定这两个数据传输函数会执行哪一个以及先执行哪一个，所以用OR连接了两种可能性，进而确保tail定义的节点是两者之一。

第二段查询：建立在第一个查询的基础上，首先限定节点范围所表征的语句是处在会话握手过程中的，具体的匹配条件基本都是利用边代表的关系对节点之间的联系进行表征的，主要可以划分为三个部分。第一部分是利用增强型抽象语法树边来对p系列语句主干节点以及他们所在原SAST上的原树节点进行匹配，如果语句对应上这些函数名，那么可以确定各个p节点对应着什么功能的语句；第二部分是利用节点间是否通过控制流边可达来判断的，例如不确定具体某两个节点间的控制流方向，但可以断定它们之间必有边连接，也可以被表示。第三部分是利用数据依赖关系进行节点之间关系的匹配，数据依赖边可以确保其中有争议的节点关系得到修正，保证了这些节点在结构上的准确位置关系。

匹配结果：如果该规则匹配CQL对软件源码执行完毕后并没有返回出节点，则表示客户端软件中不存在满足正确接口调用逻辑规则的代码段，即该使用了 OpenSSL库的软件存在主机名验证漏洞。同样地，OpenSSL库的证书验证、 GnuTLS库的身份认证都可以使用这套技术来进行检测。

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (1)

1.基于图挖掘的软件逻辑漏洞检测方法，其特征在于，包括以下步骤：

步骤一、加载客户端软件源代码，构建基于源码的抽象语法树、控制流图和程序依赖图这三种中间表示，并将抽象语法树优化处理获得简化型抽象语法树，将程序依赖图增强处理获得增强型程序依赖图；

步骤二、将步骤一获得的简化型抽象语法树、增强型程序依赖图连同控制流图一起整合构建出系统属性图，然后将系统属性图存储到图数据库中；

步骤三、对SSL/TLS协议软件库接口的正确使用模式进行抽象提取，得到接口逻辑规则；

步骤四、将步骤三中的接口逻辑规则采用人工分析的方式，手动构建遵循系统属性图规范的图模型；

步骤五、用CQL语言编码步骤四的图模型，在图数据库中将编码后的图模型与步骤二所得的系统属性图执行规则进行匹配，若匹配成功，则该图模型就是客户端软件系统属性图的子图，即满足接口逻辑规则而无逻辑漏洞；否则，客户端软件存在逻辑漏洞。

Images