分析源库模式缺陷检测器的深层结构体指针分析优化方法与流程

1.本发明涉及软件测试技术领域，尤其涉及分析源库模式缺陷检测器的深层结构体指针分析优化方法。


背景技术：

2.静态代码分析是指在不运行代码的方式下，通过词法分析、语法分析、控制流、数据流分析等技术对程序代码进行扫描，验证代码是否满足规范性、安全性、可靠性、可维护性等指标的一种代码分析技术，静态分析技术向模拟执行的技术发展以能够发现更多传统意义上动态测试才能发现的缺陷，例如符号执行、抽象解释、值依赖分析等等，并采用数学约束求解工具进行路径约减或者可达性分析以减少误报增加效率。
3.source
‑
sink（源库）类检测器通常通过定义source函数、sink函数、过滤函数规约，在符号执行、值依赖分析等模型上对变量的数据传递进行跟踪，并对守卫值进行分析与可达性判定，source
‑
sink类检测器包括空指针解引用，内存泄漏，污染数据，sql注入，命令行注入等，多与安全领域相关，是静态代码分析领域关注的重点问题。
4.传统指针分析技术主要在steensgaard算法和anderson算法的基础上进行优化，需要面临路径敏感、流敏感、上下文敏感、域敏感等方面的精度和效率瓶颈，由于静态分析技术本身的效率限制，现有商业静态分析工具往往需要权衡效率和精度，对深层指针只进行有限层次、深度的分析，经过实验，大部分商业静态分析工具无法分析嵌套两层以上的结构体指针传递情况。
5.经过调研，现有商用静态分析工具对source
‑
sink类检测器分析对深层指针最多分析两层，会直接舍弃无法分析的分支，对涉及全局变量、函数指针的分析结果均无法令人满意，而如果无视这些分支可能造成的影响，会产生大量误报，需要牺牲大量人力进行二次验证，因此，本发明提出分析源库模式缺陷检测器的深层结构体指针分析优化方法以解决现有技术中存在的问题。


技术实现要素：

6.针对上述问题，本发明的目的在于提出分析源库模式缺陷检测器的深层结构体指针分析优化方法，该方法综合利用多种静态代码分析技术，使用启发式算法自动将复杂度过高的source
‑
sink模式问题合理拆分为若干简单子问题，再对每个子问题进行单独判定，对不可判定问题，能够缩小影响范围，给出关联层次较近的相关函数，方便进行人工校验，可以有效降低代码分析结果的误漏报率，从而降低人工审计成本。
7.为了实现本发明的目的，本发明通过以下技术方案实现：分析源库模式缺陷检测器的深层结构体指针分析优化方法，包括以下步骤：步骤一先根据source
‑
sink判定构建source摘要和sink摘要，再分别根据source摘要和sink摘要，通过直接函数调用分析、函数指针分析和相似深层结构体分析的方式寻找关联
函数，接着汇总各个方式收集的关联函数，并进行后续分析；步骤二在函数调用图上分析收集的关联函数，得到包括source节点、sink点和全部关联函数的函数调用图的子图；步骤三对子图中的相邻两点，采用source
‑
sink技术进行分析，得到分段source
‑
sink可达性判定结果；步骤四对分段结果进行交操作和并操作汇总，最终得到source
‑
sink整体判定条件，实现深层结构体指针分析优化。
8.进一步改进在于：所述步骤一中，source摘要和sink摘要内容一致，source摘要部分直接获取source所在函数函数名、涉及的核心变量名称，再结合绑定分析和别名分析收集函数名、核心变量名的别名及其所在位置。
9.进一步改进在于：所述步骤一中，所述直接函数调用分析具体为：直接通过函数调用图，收集source节点和sink节点的调用关系与被调用关系，所述直接函数调用分析方法收集的结果置信度随调用函数深度逐渐减低。
10.进一步改进在于：所述步骤一中，所述函数指针分析具体为：根据source函数和sink函数的函数名的绑定分析与别名分析结果，收集涉及的函数指针及其调用位置，补充入直接函数调用分析中，若函数指针涉及深层结构体，则有限度的采用相似深层结构体分析进行展开，所述函数指针分析方法分析的置信度除考虑调用函数深度外，还额外考虑别名分析的精度。
11.进一步改进在于：所述步骤一中，所述相似深层结构体分析具体为：对source函数和sink函数涉及的核心变量进行别名分析，若涉及深层结构体，则对深层结构体建立摘要，并通过抽象语法树由深到浅收集同名深层结构体可能涉及的代码段。
12.进一步改进在于：通过抽象语法树由深到浅收集的结果需考虑同名深层结构体出现次数与目标代码段与source
‑
sink节点上下文相关性。
13.进一步改进在于：所述步骤三中，若相邻两点的source
‑
sink判定为复杂度过高的不可判定问题，则单独标记两点，并根据相邻两点的置信度评分排序供后续人工审计使用。
14.本发明的有益效果为：本发明综合利用多种静态代码分析技术，使用启发式算法自动将复杂度过高的source
‑
sink模式问题合理拆分为若干简单子问题，再对每个子问题进行单独判定，对不可判定问题，能够缩小影响范围，给出关联层次较近的相关函数，方便进行人工校验，可以有效降低代码分析结果的误漏报率，从而降低人工审计成本，静态代码分析工具的开发者可以使用本发明所述的方法对source
‑
sink模式的检测器进行优化，能够较高精度的发现部分复杂source
‑
sink问题。能够有效与传统静态分析工具的source
‑
sink分析逻辑进行补充。
附图说明
15.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本
发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
16.图1是本发明实施例一的方法流程图；图2是本发明实施例一的获取关联函数流程图；图3是本发明实施例一的关联函数子图示例图；图4是本发明实施例一的关联函数子图判定示例图。
具体实施方式
17.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
18.在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”、“第四”等仅用于描述目的，而不能理解为指示或暗示相对重要性。
19.在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。
20.实施例一参见图1、2、3、4，本实施例提供了分析源库模式缺陷检测器的深层结构体指针分析优化方法，包括以下步骤：步骤一先根据source
‑
sink判定构建source摘要和sink摘要，source摘要和sink摘要内容一致，以source摘要为例，source摘要部分直接获取source所在函数函数名、涉及的核心变量名称，再结合绑定分析和别名分析收集函数名、核心变量名的别名及其所在位置，然后分别根据source摘要和sink摘要，通过直接函数调用分析、函数指针分析和相似深层结构体分析的方式寻找关联函数，每种方式收集的关联函数的置信度有所不同，然后汇总各个方式收集的关联函数，并进行后续分析；其中，直接函数调用分析：直接通过函数调用图，收集source节点和sink节点的调用关系与被调用关系，该直接函数调用分析方法收集的结果置信度随调用函数深度逐渐减低；函数指针分析：根据source函数和sink函数的函数名的绑定分析与别名分析结果，收集涉及的函数指针及其调用位置，补充入直接函数调用分析中，若函数指针涉及深层结构体，则有限度的采用相似深层结构体分析进行展开，该部分分析的置信度除考虑调用函数深度外，还额外考虑别名分析的精度；
相似深层结构体分析：对source函数和sink函数涉及的核心变量进行别名分析，若涉及深层结构体，则对深层结构体建立摘要，并通过抽象语法树由深到浅收集同名深层结构体可能涉及的代码段，通过抽象语法树由深到浅收集的结果需考虑同名深层结构体出现次数与目标代码段与source
‑
sink节点上下文相关性；置信度与结构体层次深度和在代码中出现频率有关，实际测试中，若被测代码风格经过静态代码分析工具充分测试，代码风格较好，则本处置信度极高，能引入大量传统静态代码分析难以直接分析的复杂代码逻辑关系；步骤二在函数调用图上分析收集的关联函数，得到包括source节点、sink点和全部关联函数的函数调用图的子图；步骤三对子图中任意相邻两点m和n，采用source
‑
sink技术进行分析，得到若干分段source
‑
sink可达性判定结果，可达性判定可复用原source
‑
sink分析和过滤函数，也可独立编写，若相邻两点的source
‑
sink判定为复杂度过高的不可判定问题，则单独标记两点，并根据相邻两点的置信度评分排序供后续人工审计使用；步骤四对分段结果进行交操作和并操作汇总，最终得到source
‑
sink整体判定条件，实现深层结构体指针分析优化。
21.对图3的分析结果如图4所示，图中最终source到sink的条件为(f(source, n1) && f(m1, m2)) || (f(source, n1) && f(m1, m2))。
22.实施例二根据cve
‑
2021
‑
29649描述，分析linux
‑
5.11.1版本的内核代码，该cve例子有明确的source
‑
sink定义，关联关系较为复杂，根据cve描述和git修改记录，本处缺陷为实际内存泄漏发生后由开发人员修正，非静态分析工具扫描后修正，根据本发明对cve
‑
2021
‑
29649实施如下分析：1.在linux
‑
5.11.1\kernel\usermode_driver.c中找到成对的source
‑
sink定义【umd_info
‑
>tgid = get_pid(task_tgid(current));】和【put_pid(umd_info
‑
>tgid);】；2.对umd_info的source
‑
sink进行关联，发现该处同时涉及全局变量、深层指针和多级函数指针调用，难以进行直接数据流关联；3.对source函数umd_setup进行分析:3.1.通过函数调用图直接分析source的被调用点，发现为空；3.2.通过抽象语法树分析source通过函数指针传递的语句，发现有且仅有一处关联函数fork_usermode_driver；3.2.1.分析调用点call_usermodehelper_setup，source函数指针通过参数init传入，在sub_info
‑
>init=init唯一进行赋值，对函数指针可建立结构体摘要[subprocess_info]
‑
>init；3.2.2.通过抽象语法树层次搜索[subprocess_info]
‑
>init字段的调用，可得到[subprocess_info]
‑
>init字段有且仅有一处关联函数call_usermodehelper_exec_async；
4.对sink函数umd_cleanup进行分析:4.1.通过函数调用图直接分析sink的被调用点，发现为空；4.2.通过抽象语法树分析sink通过函数指针传递的语句，发现有且仅有一处关联函数fork_usermode_driver；4.2.1.分析调用点call_usermodehelper_setup，source函数指针通过参数init传入，在sub_info
‑
>cleanup=cleanup唯一进行赋值，对函数指针可建立结构体摘要[subprocess_info]
‑
>cleanup；4.2.2.通过抽象语法树层次搜索[subprocess_info]
‑
>cleanup字段的调用，可得到[subprocess_info]
‑
>cleanup字段有且仅有一处关联函数call_usermodehelper_exec_async，对其进行进行分析可知存在调用链 call_usermodehelper_setup()
ꢀ‑‑
> call_usermodehelper_exec_work()
ꢀ‑‑
> call_usermodehelper_exec_async()
ꢀ‑‑
> [subprocess_info]
‑
>cleanup()；5.通过source
‑
sink结构体摘要分析：5.1.通过函数内分析可知tgid的上层结构体umd_info唯一来自subprocess_info类型info的data字段，建立结构体摘要[subprocess_info]
‑
>data
‑
>tgid；5.2.通过函数内分析可知tgid的上层结构体umd_info唯一来自subprocess_info类型info的data字段，建立结构体摘要[subprocess_info]
‑
>data
‑
>tgid，与5.1结构体摘要相同，判定有强置信度；5.3.通过抽象语法树层次分别搜索[subprocess_info]
ꢀ‑
>data
‑
>tgid；[subprocess_info]
‑
>data字段的赋值/被赋值调用，可得到[subprocess_info]
ꢀ‑
>data
‑
>tgid无直接匹配，[subprocess_info]
‑
>data字段仅有一处关联函数call_usermodehelper_setup；6.综合上述关联函数，可得到source
‑
sink的各项可能调用链，以此为前提辅助对source
‑
sink进行分段分析。最终需要分析：6.1.call_usermodehelper_exec函数内info
‑
>work到call_usermodehelper_freeinfo的可达性f1；6.2.info
‑
>work到sourcenode的调用链可达性f2；6.3.call_usermodehelper_freeinfo到sinknode的可达性f3。
[0023]
最终计算f1&&f2&&f3即为本处是否存在内存泄漏的判定。
[0024]
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。