CN104573503A - 一种内存访问溢出的检测方法及装置 - Google Patents

Abstract

本申请公开了一种内存访问溢出的检测方法及装置，对源代码进行预处理、词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树；针对不同的检测场景建立多种检测模型，并根据多种检测模型分析控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态空间遍历，输出检测结果；根据检测结果判断源代码中是否存在内存访问溢出，并对检测出的内存访问溢出进行反馈输出。这样，通过追溯源代码的控制流图、数据依赖图以及抽象语义树，定义多种检测模型，实现表达式迭代以及状态机分析，可以充分挖掘源代码中存在的内存访问溢出，并且可以减少遍历状态空间所花费的空间和时间代价，减少对于内存访问溢出的漏报和误报。

Description

一种内存访问溢出的检测方法及装置

技术领域

本申请涉及计算机编译领域，特别是涉及一种内存访问溢出的检测方法及装置。

背景技术

内存访问溢出是导致C语言程序出现漏洞的根本原因之一，它通常表现为数组越界访问、栈溢出等关键问题。这些关键问题可能导致程序在运行期出现很难预测的结果，既可能正常运行，也可能导致程序崩溃，这将在测试时给程序员带来极大的困扰。归其原因，它们都是由于程序未按照理想约束条件下进行内存访问。因此，如何尽可能的检测、判断可能存在漏洞，并尽可能的减少误判率是目前的研究热点和难点。

一般而言，内存访问溢出检测分为静态检测与动态检测两部分的内容，内存访问溢出的静态检测是将内存访问溢出的问题转换为约束求解问题，并配合模型检验方法来建立约束，模型检验方法具有很高的可靠性和完备性，理论上能保证没有误报和漏报，并且能全自动地实施。已有的内存访问溢出的静态检测方法，都是通过遍历状态空间，将所有可能存在内存访问溢出的代码全部检测出，并将这些代码进行报告。

然而，现实情况下，状态空间由于循环结构、跳转分支可能无穷大，而遍历状态空间所花费的空间和时间代价却是无法承受，而且由于源代码中的函数、循环较多，现有的检测方法可以处理简单循环，但无法处理递归等复杂结构，很难在资源受限的条件下遍历全部的状态空间，因此存在较高的漏报和误报。

发明内容

有鉴于此，本申请实施例提供一种内存访问溢出的检测方法及装置，以减少遍历状态空间所花费的空间和时间代价，且减少对于内存访问溢出的漏报和误报。

为了实现上述目的，本申请实施例提供的技术方案如下：

一种内存访问溢出的检测方法，包括：

对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树；

针对不同的检测场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态空间遍历，输出检测结果；

根据所述检测结果判断所述源代码中是否存在内存访问溢出，并对检测出的内存访问溢出进行反馈输出。

优选地，所述对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树，包括：

对所述源代码进行词法分析和语法分析，并基于词法分析和语法分析的结果进行语义分析以及上下文分析，生成抽象语义树；

根据所述源代码的分支跳转和函数调用关系，将所述源代码切分为多个基本块，并分析每个基本块之间的跳转关系，根据所述跳转关系生成控制流图；

分析所述源代码的变量之间的数据依赖关系，生成数据依赖图。

优选地，所述针对不同场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态空间遍历，包括：

针对不同的检测场景定义多种检测模型，所述检测模型包括：指针操作模型、数组访问模型、标准库函数模型和循环体与抽象迭代模型；

对所述控制流图和所述数据依赖图进行剪裁，沿所述控制流图和所述数据依赖图中的路径将常量节点依次向后继节点传递，并计算常量表达式，通过操作符连接并迭代内存访问操作的输入条件，进行表达式迭代并得到所述输入条件的迭代结果；

扫描所述抽象语义树的结构，对所述抽象语义树中的指针和数组变量的声明、赋值、访问以及标准库函数的节点进行关键词标记，并查找所述抽象语义树中与所述多种检测模型中相匹配的节点以及分支；

建立状态机，并分析内存访问操作和所述输入条件的迭代结果，判断当前的内存访问操作是否在全量环境下有效。

优选地，所述对所述控制流图和所述数据依赖图进行剪裁，包括：

分析所述抽象语义树中被标记节点所在基本块对应于所述控制流图上的节点，删除其余节点，重新建立节点之间的连接关系；

保留所述控制流图中被保留下的节点以及内存访问操作的变量在所述数据依赖图中的依赖关系，删除所述数据依赖图中的其余依赖关系。

优选地，所述根据所述检测结果判断所述源代码中是否存在内存访问溢出，包括：

如果当前的内存访问操作在全量环境下有效，则判断不存在内存访问溢出，如果当前的内存访问操作不是在全量环境下有效，则判断存在内存访问溢出。

一种内存访问溢出的检测装置，包括：

分析模块，用于对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树；

检测模块，用于针对不同的检测场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态空间遍历，输出检测结果；

输出模块，用于根据所述检测结果判断所述源代码中是否存在内存访问溢出，并对检测出的内存访问溢出进行反馈输出。

优选地，所述分析模块，包括：

分析单元，用于对所述源代码进行词法分析和语法分析，并基于词法分析和语法分析的结果进行语义分析以及上下文分析，生成抽象语义树；

切分单元，用于根据所述源代码的分支跳转和函数调用关系，将所述源代码切分为多个基本块，并分析每个基本块之间的跳转关系，根据所述跳转关系生成控制流图；

生成单元，用于分析所述源代码的变量之间的数据依赖关系，生成数据依赖图。

优选地，所述检测模块，包括：

定义单元，用于针对不同的检测场景定义多种检测模型，所述检测模型包括：指针操作模型、数组访问模型、标准库函数模型和循环体与抽象迭代模型；

裁剪单元，用于对所述控制流图和所述数据依赖图进行剪裁，沿所述控制流图和所述数据依赖图中的路径将常量节点依次向后继节点传递，并计算常量表达式，通过操作符连接并迭代内存访问操作的输入条件，进行表达式迭代并得到所述输入条件的迭代结果；

扫描单元，用于扫描所述抽象语义树的结构，对所述抽象语义树中的指针和数组变量的声明、赋值、访问以及标准库函数的节点进行关键词标记，并查找所述抽象语义树中与所述多种检测模型中相匹配的节点以及分支；

判断单元，用于建立状态机，并分析内存访问操作和所述输入条件的迭代结果，判断当前的内存访问操作是否在全量环境下有效。

优选地，所述裁剪单元，包括：

分析子单元，用于分析所述抽象语义树中被标记节点所在基本块对应于所述控制流图上的节点，删除其余节点，重新建立节点之间的连接关系；

保留子单元，用于保留所述控制流图中被保留下的节点以及内存访问操作的变量在所述数据依赖图中的依赖关系，删除所述数据依赖图中的其余依赖关系。

优选地，所述输出模块，具体用于，如果当前的内存访问操作在全量环境下有效，则判断不存在内存访问溢出，如果当前的内存访问操作不是在全量环境下有效，则判断存在内存访问溢出。

应用本申请的技术方案，对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树；针对不同的检测场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态空间遍历，输出检测结果；根据所述检测结果判断所述源代码中是否存在内存访问溢出，并对检测出的内存访问溢出进行反馈输出。这样，通过追溯源代码的控制流图、数据依赖图以及抽象语义树，定义多种检测模型，实现表达式迭代以及状态机分析，可以充分挖掘源代码中存在的内存访问溢出，并且可以减少遍历状态空间所花费的空间和时间代价，减少对于内存访问溢出的漏报和误报。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种内存访问溢出的检测方法的流程图；

图2为本申请实施例提供的另一种内存访问溢出的检测方法的流程图；

图3为本申请实施例提供的又一种内存访问溢出的检测方法的流程图；

图4为本申请实施例提供的一种内存访问溢出的检测装置的结构示意图。

具体实施方式

相关术语解释:

内存访问溢出(Buffer Overflow)是指由于程序对某个内存对象的写操作，使系统错误地改变了另一个内存对象；

控制流图(Control flow graph，CFG)是用在编译器中的一个抽象数据结构。它是一个过程或程序的抽象表现，由编译器在内部维护。每个在控制流图中的节点代表一个基本块，例如，没有任何跳转或跳转目标的基本块；跳转目标以一个块开始，和以一个块结束。每条在控制流图中的有向边，用于代表控制流中的跳转方向，或基本块之间的跳转关系。

数据依赖图(data dependence)是指语句之间存在的数据约束关系，如果两个运算操作之间不占用同一变量，又或者它们只读同一变量进行连续的读写，那么执行结果与它们的执行顺序无关，数据依赖图(Data DependenceGraph，DDG)就是描述了不同语句间，同一变量或数据之间的数据依赖关系。

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

为了使本技术领域的人员更好地理解本申请方案，使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

图1为本申请实施例提供的一种内存访问溢出的检测方法的流程图。

参照图1所示，本申请实施例提供的内存访问溢出的检测方法，包括：

步骤S11：对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树；

在本申请实施例中，不仅通过对源代码进行语法、词法、语义分析，构建静态检测过程中适用的多种结构，还针对指针和数组变量的声明、赋值、访问，以及标准库函数的调用进行分析，搜集代码中与指针数组以及库函数相关的信息，对常规控制流图、数据依赖图以及抽象语义树进行剪裁。

具体的，本申请提供的内存访问溢出的检测方法，参照图2，对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树，包括：

S111：对所述源代码进行词法分析和语法分析，并基于词法分析和语法分析的结果进行语义分析以及上下文分析，生成抽象语义树；

S112：根据所述源代码的分支跳转和函数调用关系，将所述源代码切分为多个基本块，并分析每个基本块之间的跳转关系，根据所述跳转关系生成控制流图；

S113：分析所述源代码的变量之间的数据依赖关系，生成数据依赖图。

本申请实施例涉及的对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树，是基于开源编译框架GCC(GNU C Compiler)实现的，但并不局限于此，诸如开源分析工具Splint等均可实现替代功能。

以开源编译框架GCC(GNU C Compiler)为例，本申请实施例对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树的流程，具体步骤如下：

GCC编译器的内置预处理工具，首先实现对源代码中include部分的加载，以及宏定义的替换；

GCC编译器的前端分析部分，调用开源词法、语法分析工具yacc以及lex，对源代码进行了词法、语法分析；

GCC编译器的前端分析部分，基于词法、语法分析的结果，继续进行语义层以及上下文分析，并生成抽象语义树(Abstract Semantic Tree,AST)；

GCC编译器的前端分析部分，根据分支跳转、函数调用等将源代码切分为多个基本块，并分析这些基本块之间的跳转关系，生成控制流图(ControlFlow Graph,CFG)；

GCC编译器的前端分析部分，分析变量之间的写后读、读后写、写后写以及存储相关四种数据依赖关系，生成数据依赖图(Data Dependence Graph,DDG)；

本申请实施例提供的后续内存访问溢出的检测方法等操作均是基于AST、CFG、DDG这三个图实现。

步骤S12：针对不同的检测场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态机分析，输出检测结果；

现有技术中，对于内存访问溢出的静态检测是指在源程序不被执行的条件下，通过将内存访问溢出的问题转换为存储访问约束，并配合模型定义来建立约束，实现对内存访问访问漏洞的检测。理论上，静态检测可以通过有限状态机分析出全部的可能，但由于C语言极其复杂，而工具模型上为了兼顾效率，设计过程中可能会做一些近似处理，或由于多线程和控制流变化导致高的误判率，而且循环结构下分析通常代价较高。导致上述问题的主要原因在于：

控制流图上节点之间的连接关系是依托路径而存在，而静态分析获得的路径可能在动态时是不可达的。

循环体结构是一种动态表现，它带来的状态逻辑膨胀，导致静态分析的代码和难度均较高。

现有较成熟的开源静态代码检测工具，如Splint、CBMC等在轻量级代码检测方面取得了突出的成果，但它们在面向过程间分析、循环体、复杂结构下的数组、指针访问溢出的检测上出现了瓶颈，并未提出较好的解决方案。表1为三段内存访问溢出的代码，其中，代码片段(a)为一段常量访问溢出的代码，整型数组buffer包含10个元素，可以清楚地看到程序对buffer[10]的写操作发生了越界，而代码片段(b)和(c)则是由于指针、循环等操作导致的隐式内存访问溢出。以开源软件Splint为例，它可以检测出(a)中漏洞，但无法对(b)和(c)中的漏洞给出警告。

表1

表2展示两段内存访问的代码片段，如果针对(a)中所示代码，就可能导致误报，但实际上ptr[-1]是对buffer[0]的访问，它是有效的。如果针对代码(b)，常规工具通过循环展开可以在一定程度上判定(b)中的代码合法，但如果循环常量’11’被变量取代，则很多检测工具受限于控制流和数据流，无法进行分析，甚至直接报告warning。

表2

针对上述问题，本申请实施例提供的一种内存访问溢出的检测方法，如图3所示，所述针对不同场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态机分析，包括：

S121：针对不同的检测场景定义多种检测模型，所述检测模型包括：指针操作、数组访问和标准库函数；

S122：对所述控制流图和所述数据依赖图进行剪裁，沿所述控制流图和所述数据依赖图中的路径将常量节点依次向后继节点传递，并计算常量表达式，通过操作符连接并迭代内存访问操作的输入条件，进行表达式迭代并得到所述输入条件的迭代结果；

S123：扫描所述抽象语义树的结构，对所述抽象语义树中的指针和数组变量的声明、赋值、访问以及标准库函数的节点进行关键词标记，并查找所述抽象语义树中与所述多种检测模型中相匹配的节点以及分支；

S124：建立状态机，并分析内存访问操作和所述输入条件的迭代结果，判断当前的内存访问操作是否在全量环境下有效。

针对C语言，该方法在现有技术对常量访问溢出检测的基础上，通过定义检测模型、分析程序控制流与数据流、状态机遍历等手段，充分挖掘静态程序中存在的隐式内存访问溢出，并在这些问题上取得了较佳效果，降低了漏判率和误判率。

具体的，本申请实施例提供的一种内存访问溢出的检测方法的具体步骤如下：

前端分析模块已获取AST、CFG、DDG三个图结构，并对他们分多步骤进行分析；

常量传播：分析AST、CFG、DDG三图，将其中的常量节点依次沿着DDG、CFG中路径向后继节点进行传递；计算其中的常量表达式，并将计算结果迭代入后续计算，常量传播采用公知技术实现。

关键词标记：AST是对高级语言进行语义分析后的结果，它的内部节点对当前语句的行为进行了详细描述。为了降低分析代价，本发明通过扫描AST，对其中涉及指针和数组变量的声明、赋值、访问，以及标准库函数的节点进行标记；

流图剪裁：分为对控制流图与数据依赖图进行的剪裁。对所述控制流图和所述数据依赖图进行剪裁，包括：分析所述抽象语义树中被标记节点所在基本块对应于所述控制流图上的节点，删除其余节点，重新建立节点之间的连接关系；保留所述控制流图中被保留下的节点以及内存访问操作的变量在所述数据依赖图中的依赖关系，删除所述数据依赖图中的其余依赖关系。

具体的，对控制流图而言，分析AST中被标记节点所在基本块对应于CFG上的节点，删除其余节点，并重新建立节点之间的连接关系；对数据依赖图而言，根据CFG中被保留下的节点，以及内存操作涉及的变量，其余无关变量节点以及变量节之间的依赖关系，统一被删除，未删除的依赖关系保持不变；

模型定义：根据不同检测场景定义了指针操作、数组访问、标准库函数、循环体与抽象迭代等多种模型范式；

模型匹配：扫描AST结构，查找涉及已定义模型的节点以及分支，并相应进行识别与判断；

表达式迭代：追溯CFG与DDG，通过操作符连接并迭代内存访问操作的输入条件；

状态机遍历：建立状态机，并分析内存访问操作，输入条件的迭代结果，判断当前内存访问操作是否在全量环境下有效。

对于模型定义，下面具体描述：

模型定义是指从程序中抽象出于缓冲区溢出漏洞相关变量的属性，并将这些属性抽象出来的过程。缓冲区溢出较容易在对数组元素赋值、基地址访问、字符串拷贝以及存储分配等处出现，但是否出现还需要相应地判断数组的长度和下标的值，或者判断指针所指的缓冲区的长度，或者判断内存拷贝函数中源缓冲区的长度和目的缓冲区的长度，这些长度信息与所处程序结构以及控制流有关，并不能直观的进行判断。为此，本发明所涉及的检测模型根据应用场景的不同，被划分为面向指针操作、面向循环结构以及环体与抽象迭代三部分，并为这些情况分别建立了检测模型，这些模型从代码结构、数组访问以及指针操作等方面的属性，还记录了目标操作对内存访问的约束，它们均是以逻辑范式的形式存在，相互直接可通过嵌套以描述更丰富的结构，并被用于后续的状态空间遍历。

指针操作模型：

指针操作包括数组访问和复杂指针访问两种，其中数组访问是较为常见的内存访问操作，底层编译器通常是将数组视作隐式的指针操作，而由于C语言的源程序中，程序员定义的数组在内存分配上一般分配在.data和.bss段，其中前者用于存储全局和静态数组，而后者则用于存储函数体内的临时变量。正因如此，指针操作模型需要区分对待.data和.bss两个数据段内的变量。复杂指针访问一般出现与复杂表达式计算相关操作中，本发明在模型定义阶段只针对指针本身进行定义，而表达式相关的操作则在后续状态机迭代部分实现，如下是本发明定义的指针操作模型：

POINTER(operation,range,constraint,condition,input,type)

operation为迭代过程中其它模型的范式，range代表目标数组或指针的应用范围，包括local与global，其中local包括局部非static以及由函数传参获得的数组或指针。global则为全局定义及局部静态数组和指针。constraint代表约束条件，默认占用字节数为类型，范围需要通过追溯CFG、CDG来实现。对应CFG上前继和后续节点的路径。condition代表当前记录的存在条件。input为指针访问时的输入激励。type则为数组或指针的基础数据类型。

以下面的代码片段1对应的检测模型范式1：

为例，行8为对数组buffer访问操作，而根据抽象语义树AST，可知行2对应于buffer数组的定义，即buffer的range为local，且长度为4个int型数据。

标准库函数模型：

C语言的标准库中存在一些字符串拷贝的库函数，而这些函数的源代码一般不可得，为了检测缓冲区溢出漏洞，与指针操作所定义的模型不同，它需要针对这些标准函数本身建立可分析模型。如下是strcpy、memcpy等的抽象模型。

STDFUC(Operation,Des,Len1,Src,Len2,Constraint,Stop)

其中Operation为迭代过程中其它模型的范式，Des为目标内存地址，Src为源内存地址，Len1和Len2分别为Des、Src所指向内存地址的长度，以字节数为单位。Constraint是内存拷贝过程中的限制条件，通常为认为描述的可计算表达式。Stop为字符串拷贝时的终止符，如strcpy的终止符号为’\0’，而memcpy等内存拷贝默认为-1，代表不存在终止符。

以下面的代码片段2对应的检测模型：

STDFUC(NULL,buffer,4,“ab\0cdef”,2,4>＝2,’\0’)；

1 char buffer[4]；

2 strcpy(buffer,“ab\0cdef”)；

为例，行2调用了标准库函数strcpy，且字符串“ab\0cdef”的终止符为’\0’。

循环体与抽象迭代模型：

常见的静态检测工具在面向循环体进行内存访问溢出检测时，大多只能处理常量循环，且一般是将循环体直接展开数份而进行轻量级检测。但实际情况却是绝大多数的代码内的循环体变量都是变长的，为此，本发明仍然通过建立循环模型，实现一种通用检测方法。

C语言源程序内的循环结构一般由循环语句或函数之间的递归调用构成。循环语句主要由下表内的四种结构构成，其中前三种可在AST中直接识别关键词实现，而goto语句则还需判断CFG内是否存在闭环路径而确定。模型如下：LOOP(Operation,Input,Step)

其中Condition为循环成立的条件，为一个表达式，Step为循环进行的步长，其值默认为1，与前两种模型不同，Operation为迭代过程中其它模型的范式，只用于其它范式的迭代。以代码片段1内的循环结构为例，它对应的范式为：LOOP(NULL,i<n,1)；

由于C语言编写的源代码的结构通常较为复杂，这就导致了上述多个模型在语言结构上存在嵌套，而嵌套过程中则导致了多种模型范式

之间,以及范式内condition表达式之间的迭代。以代码片段1内的语句8为例，它与语句7构成了一个基本块，并对应于CFG内的一个节点，即语句8对应的模型范式处于7～8构成的循环体内，即代码片段1内的语句8的循环范式可修改为范式2：LOOP(POINTER(NULL,local,i<4,NULL,i,int),i<n,1)；

除此以外，POINTER与LOOP两范式之间的迭代，将使得POINTER范式的condition进一步被限定，即condition从NULL变为i<n，因此，语句8的模型范式被修改为如下范式3形式：

LOOP(POINTER(NULL,local,i<4,i<n,i,int),i<n,1)；

由于语句8所处的基本块在CFG的前驱节点时由行5导致的分支结构，因此，行8进行内存访问是否有效还取决于行5的分支条件。本发明在进行条件组合时，还提供了与(&&)、或(||)、非(！)三种逻辑运算符来描述条件之间的连接关系，可以看到：

当行5不成立时，行8不被执行，可认为不存在访问溢出；

当行5成立时，行8的检测模型内的condition不变；

综上可以看到，行8检测模型内的condition即为：(i<n&&(m<10))||(！(m<10))，化简后即为i<n||(！(m<10))。因此，代码片段1内的行8的检测模型应为范式4：

LOOP(POINTER(NULL,local,i<4,i<n||(！(m<10)),i,int),i<n,1)；

在进行检测时，本发明是通过从下而上的沿着CFG、DDG，迭代目标模型范式内的condition与constraint，并但检测到其它嵌套模型范式式，进行范式间的嵌套。一旦POINTER或STDFUC范式内condition与constraint出现冲突，则断定程序出现内存访问溢出。具体流程如下：

获取目标语句或基本块的原始模型范式，如代码片段1内的行8的范式1；

沿着CFG至下而上的遍历或追溯，检测是否存在模型之间的嵌套，如范式2；

模型间嵌套时，还需迭代它们的condition，如如范式3；

继续沿着CFG追溯，根据控制流的流向，对condition条件再次进行合并，且值得注意的是，由于CFG内任一节点可能存在多个前驱节点，因此，同一位置上的模型范式由于控制流导致的condition不同，而存在多种表达；

模型范式内的各个变量，在DDG内可能与其它变量存在数据依赖关系，因此，追溯的DDG的过程，就是探索各变量生命周期的过程；

分析AST，检测模型范式内的各变量的生命周期，整个追溯操作直至找到变量生命周期的起始处结束，以代码片段3：

为例，行6调用的代码片段1所示的test函数，而在追溯CFG时，test1是test函数的前驱节点，追溯DDG时，test函数内的变量m、n分别依赖于k+1与k，因此，经过嵌套与迭代后，代码片段1内的行8所对应的模型范式转换为如下范式5表达：

LOOP(LOOP(POINTER(NULL,local,i<4,i<k||(！(k+1<10)),i,int),i<k,1),k<20,1)；

追溯结束后，生成了当前追溯路径下完整的constraint和condition，接下来将对其进行状态空间遍历，实现内存访问检测。

在进行状态空间遍历时，以范式5为例，POINTER范式的约束constraint为i<4，而该范式被执行的条件condition为i<k||(！(k+1<10))，而外层嵌套的两个LOOP范式的condition分别为k<20以及i<k。因此，检测代码片段1中行8是否存在内存访问溢出，即等价于满condition的全部i、k取值区间均∈constraint。

对condition进行化简，可获得如下范式6：i<k||k>＝9

本发明将以||、&&作为子状态的切割符，那么范式6形成了如下形式的状态机：

	i<k	k>＝9
			1	*	1
1	1	*
			0	0	0

其中’*’代表子条件取任意值，当引入POINTER的constraint后，即要求范式7：i<4&&(i<k||k>＝9)在LOOP范式的condition下恒成立，由于k>9是否成立与i无关，因此，成立的条件可以等价为范式8：i<4&&i<k且0<＝k<20，且k递增的步长为1。

综上所述，范式8恒成立的条件为k<＝4，但由于k的有效取值区间为{0,19}，与恒成立条件互斥，因此，可以断定存在内存泄漏。

步骤S13：根据所述检测结果判断所述源代码中是否存在内存访问溢出，并对检测出的内存访问溢出进行反馈输出。

在本申请实施例中，所述根据所述检测结果判断所述源代码中是否存在内存访问溢出，包括：如果当前的内存访问操作在全量环境下有效，则判断不存在内存访问溢出，如果当前的内存访问操作不是在全量环境下有效，则判断存在内存访问溢出。

本发明提出的技术方案中，首先，在开源工具gcc、yacc和lex的基础上对C语言源代码进行预处理以及词法、语法、语义分析，并根据实际需求，生成裁剪后的控制流图、数据依赖以及抽象语义树。其次，针对不同场景，建立指针访问、循环体、标准库函数等多种静态内存检测范式。最后，通过遍历控制流图、数据依赖图实现表达式迭代以及状态空间遍历，完成内存访问溢出的静态检测。

现有的静态内存访问检测方法，受限于模型结构以及状态空间爆炸等问题，一方面，误报率较高，另一方面，它们不能处理递归等复杂结构。除此之外，现有技术可以处理简单循环，但无法处理复杂结构，且现有技术方案通常需要嵌入判断代码，而本发明采用的状态机分析方法可以减少相关操作。与通常可见的静态检测方法相比，本发明涉及的方案中，同样需要建立检测模型，但模型的定义有异于常规实现方法。已有方法一般需要向源代码内插入检测代码来辅助静态分析，而本发明提出的技术方案，则是通过追溯控制流图、数据依赖图以及抽象语义树，实现表达式迭代以及状态空间遍历。

由于本发明合理的遍历AST、CFG、DDG三个图结构，并辅以模型范式定义、状态机遍历等，可以有效地处理递归等各种结构，并降低了内存检测过程中的漏报和错报率。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。

图4为本申请实施例提供的一种内存访问溢出的检测装置的结构示意图。

参照图4所示，本申请实施例提供的内存访问溢出的检测装置，包括：

分析模块1，用于对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树；

检测模块2，用于针对不同的检测场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态机分析，输出检测结果；

输出模块3，用于根据所述检测结果判断所述源代码中是否存在内存访问溢出，并对检测出的内存访问溢出进行反馈输出。

所述分析模块1，包括：

分析单元，用于对所述源代码进行词法分析和语法分析，并基于词法分析和语法分析的结果进行语义分析以及上下文分析，生成抽象语义树；

切分单元，用于根据所述源代码的分支跳转和函数调用关系，将所述源代码切分为多个基本块，并分析每个基本块之间的跳转关系，根据所述跳转关系生成控制流图；

生成单元，用于分析所述源代码的变量之间的数据依赖关系，生成数据依赖图。

所述检测模块2，包括：

定义单元，用于针对不同的检测场景定义多种检测模型，所述检测模型包括：指针操作模型、数组访问模型、标准库函数模型和循环体与抽象迭代模型；

裁剪单元，用于对所述控制流图和所述数据依赖图进行剪裁，沿所述控制流图和所述数据依赖图中的路径将常量节点依次向后继节点传递，并计算常量表达式，通过操作符连接并迭代内存访问操作的输入条件，进行表达式迭代并得到所述输入条件的迭代结果；

扫描单元，用于扫描所述抽象语义树的结构，对所述抽象语义树中的指针和数组变量的声明、赋值、访问以及标准库函数的节点进行关键词标记，并查找所述抽象语义树中与所述多种检测模型中相匹配的节点以及分支；

判断单元，用于建立状态机，并分析内存访问操作和所述输入条件的迭代结果，判断当前的内存访问操作是否在全量环境下有效。

所述裁剪单元，包括：

分析子单元，用于分析所述抽象语义树中被标记节点所在基本块对应于所述控制流图上的节点，删除其余节点，重新建立节点之间的连接关系；

保留子单元，用于保留所述控制流图中被保留下的节点以及内存访问操作的变量在所述数据依赖图中的依赖关系，删除所述数据依赖图中的其余依赖关系。

所述输出模块3，具体用于，如果当前的内存访问操作在全量环境下有效，则判断不存在内存访问溢出，如果当前的内存访问操作不是在全量环境下有效，则判断存在内存访问溢出。

本申请实施例提供的内存访问溢出的检测装置，可以采用上述方法实施例中的内存访问溢出的检测方法，此处不再赘述。

应用本申请的技术方案，对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树；针对不同的检测场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态空间遍历，输出检测结果；根据所述检测结果判断所述源代码中是否存在内存访问溢出，并对检测出的内存访问溢出进行反馈输出。这样，通过追溯源代码的控制流图、数据依赖图以及抽象语义树，定义多种检测模型，实现表达式迭代以及状态机分析，可以充分挖掘源代码中存在的内存访问溢出，并且可以减少遍历状态空间所花费的空间和时间代价，减少对于内存访问溢出的漏报和误报。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种内存访问溢出的检测方法，其特征在于，包括：

对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树；

针对不同的检测场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态机分析，输出检测结果；

根据所述检测结果判断所述源代码中是否存在内存访问溢出，并对检测出的内存访问溢出进行反馈输出。

2.根据权利要求1所述的方法，其特征在于，所述对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树，包括：

对所述源代码进行词法分析和语法分析，并基于词法分析和语法分析的结果进行语义分析以及上下文分析，生成抽象语义树；

根据所述源代码的分支跳转和函数调用关系，将所述源代码切分为多个基本块，并分析每个基本块之间的跳转关系，根据所述跳转关系生成控制流图；

分析所述源代码的变量之间的数据依赖关系，生成数据依赖图。

3.根据权利要求1所述的方法，其特征在于，所述针对不同场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态机分析，包括：

针对不同的检测场景定义多种检测模型，所述检测模型包括：指针操作模型、数组访问模型、标准库函数模型和循环体与抽象迭代模型；

对所述控制流图和所述数据依赖图进行剪裁，沿所述控制流图和所述数据依赖图中的路径将常量节点依次向后继节点传递，并计算常量表达式，通过操作符连接并迭代内存访问操作的输入条件，进行表达式迭代并得到所述输入条件的迭代结果；

扫描所述抽象语义树的结构，对所述抽象语义树中的指针和数组变量的声明、赋值、访问以及标准库函数的节点进行关键词标记，并查找所述抽象语义树中与所述多种检测模型中相匹配的节点以及分支；

建立状态机，并分析内存访问操作和所述输入条件的迭代结果，判断当前的内存访问操作是否在全量环境下有效。

4.根据权利要求3所述的方法，其特征在于，所述对所述控制流图和所述数据依赖图进行剪裁，包括：

分析所述抽象语义树中被标记节点所在基本块对应于所述控制流图上的节点，删除其余节点，重新建立节点之间的连接关系；

保留所述控制流图中被保留下的节点以及内存访问操作的变量在所述数据依赖图中的依赖关系，删除所述数据依赖图中的其余依赖关系。

5.根据权利要求3所述的方法，其特征在于，所述根据所述检测结果判断所述源代码中是否存在内存访问溢出，包括：

如果当前的内存访问操作在全量环境下有效，则判断不存在内存访问溢出，如果当前的内存访问操作不是在全量环境下有效，则判断存在内存访问溢出。

6.一种内存访问溢出的检测装置，其特征在于，包括：

分析模块，用于对源代码进行预处理和词法分析、语法分析以及语义分析，生成控制流图、数据依赖图以及抽象语义树；

检测模块，用于针对不同的检测场景建立多种检测模型，并根据多种检测模型分析所述控制流图、数据依赖图以及抽象语义树，进行表达式迭代以及状态机分析，输出检测结果；

输出模块，用于根据所述检测结果判断所述源代码中是否存在内存访问溢出，并对检测出的内存访问溢出进行反馈输出。

7.根据权利要求6所述的装置，其特征在于，所述分析模块，包括：

分析单元，用于对所述源代码进行词法分析和语法分析，并基于词法分析和语法分析的结果进行语义分析以及上下文分析，生成抽象语义树；

切分单元，用于根据所述源代码的分支跳转和函数调用关系，将所述源代码切分为多个基本块，并分析每个基本块之间的跳转关系，根据所述跳转关系生成控制流图；

生成单元，用于分析所述源代码的变量之间的数据依赖关系，生成数据依赖图。

8.根据权利要求6所述的装置，其特征在于，所述检测模块，包括：

定义单元，用于针对不同的检测场景定义多种检测模型，所述检测模型包括：指针操作模型、数组访问模型、标准库函数模型和循环体与抽象迭代模型；

裁剪单元，用于对所述控制流图和所述数据依赖图进行剪裁，沿所述控制流图和所述数据依赖图中的路径将常量节点依次向后继节点传递，并计算常量表达式，通过操作符连接并迭代内存访问操作的输入条件，进行表达式迭代并得到所述输入条件的迭代结果；

扫描单元，用于扫描所述抽象语义树的结构，对所述抽象语义树中的指针和数组变量的声明、赋值、访问以及标准库函数的节点进行关键词标记，并查找所述抽象语义树中与所述多种检测模型中相匹配的节点以及分支；

判断单元，用于建立状态机，并分析内存访问操作和所述输入条件的迭代结果，判断当前的内存访问操作是否在全量环境下有效。

9.根据权利要求8所述的装置，其特征在于，所述裁剪单元，包括：

分析子单元，用于分析所述抽象语义树中被标记节点所在基本块对应于所述控制流图上的节点，删除其余节点，重新建立节点之间的连接关系；

保留子单元，用于保留所述控制流图中被保留下的节点以及内存访问操作的变量在所述数据依赖图中的依赖关系，删除所述数据依赖图中的其余依赖关系。

10.根据权利要求8所述的装置，其特征在于，所述输出模块，具体用于，如果当前的内存访问操作在全量环境下有效，则判断不存在内存访问溢出，如果当前的内存访问操作不是在全量环境下有效，则判断存在内存访问溢出。