一种开源代码缺陷识别系统的实现

软件开发是一项复杂的任务，尤其是现在软件技术飞速发展，开发环境不断演变，软件架构和组成变得多样化。企业使用开源软件的比例越来越高，软件主要由自主开发代码、开源代码和开源组件组装而成。其中，开源代码、开源组件提供了必要的构建块，使组织能够交付价值、提高质量、降低风险并缩短上线时间。但同时其衍生出的软件安全管理问题也越来越多，软件团队只关注检测自主代码的潜在问题，往往忽视了对应用组件构成和应用所包含的开源代码中已知漏洞和开源协议的检查。尽管安全人员和开发人员不断通过安全编码指南制定、软件测试和各种形式的代码审查等办法来提高软件质量和安全性，但通用漏洞披露（CommonVulnerabilities&Exposures，CVE）的数据记录显示，漏洞数量依旧呈增长趋势。鉴于软件的整体安全性高度依赖于软件漏洞的识别和缓解能力。因此，高效的分析代码中存在的漏洞可以帮助开发人员识别并修复源代码中的缺陷。本文提出了一种自动发现源代码中安全漏洞的方案，通过从开放漏洞数据库中抽取所有可用的CVE记录，并从相关的开源项目所在的开源存储库中收集易受攻击的代码，建立开源缺陷代码库。利用搜索引擎与源代码分析规范多样化联合应用，根据不同结构的代码相似性特征，挖掘代码缺陷库中的缺陷匹配信息，具有较高的缺陷搜索匹配速度和准确性。1代码缺陷分析现状1.1静态代码分析技术静态代码分析是白盒测试的一种方法，通过代码检查可以确定代码和设计的一致性、代码结构的合理性、代码编写的标准性和可读性、代码逻辑表达的正确性等。静态代码缺陷分析是指在不运行目标程序的前提下分析目标程序（源代码或二进制）的词法、语法和语义等，并结合程序的数据流、控制流信息，通过类型推导、安全规则检查、模型检测等技术挖掘程序中的漏洞。静态漏洞挖掘是常用的软件测试技术，在软件测试中占有非常重要的地位。具有代表性的静态漏洞挖掘工具包括：面向C/C++源码的Cppcheck、FlawFinder[3]，面向PHP源码的RIPS，面向Java源码的FindBugs，以及能支持多种类型目标对象的著名商业化漏洞检测工具VeraCode、Fortify、Coverity、Checkmarx等。另外，LLVM[5]、Clang[6]等编译器也为软件源代码提供了大量的静态检测功能，从而在编译阶段实现对源代码的安全性检查。1.2问题分析静态代码分析技术主要用于挖掘未知问题，发现潜在的不安全及不规范的代码，但是不涉及被测软件的运行及动态验证，这与漏洞扫描、渗透测试、病毒扫描等方面的技术原理完全不同，因此静态代码分析技术存在的误报问题往往给开发人员带来困扰，尤其是在信息系统频繁迭代开发场景下的多次检测会显著增加开发人员的工作量，开发人员或审计人员需要大量精力用于排除静态分析误报问题。软件主要由自主开发代码、开源代码和开源组件组装而成。自主开发代码的缺陷是未知的，但是开源代码存在的缺陷却是公开的，因此，可以基于公开漏洞库，从开源项目所在的开源代码库中收集易受攻击的代码建立开源缺陷代码库，用于软件中开源代码的缺陷识别。相对于传统的静态代码分析，此技术路线具有较高的准确性。2开源代码缺陷识别系统本文提出一种开源代码缺陷识别方案，能够快速准确地识别软件代码中存在的开源代码缺陷。通过抽取已知的开源代码中的缺陷信息构建缺陷知识库，利用搜索技术和代码分词多种规范化表达方式，在目标代码中可以有效地识别已知代码缺陷（精准搜索）和缺陷变体（相似搜索）。开源代码缺陷识别系统架构如图1所示，系统分为缺陷数据处理流程、缺陷数据索引流程和缺陷代码搜索3个模块。图1开源代码缺陷识别系统架构2.1缺陷数据处理流程首先构建缺陷代码知识库，为了保障分析效果，知识库应包含多个级别的缺陷代码粒度，例如与缺陷代码相关的文件、类、函数等，并涵盖广泛使用的编程语言。本研究通过在CVE记录中自动收集漏洞描述信息，挖掘托管在GitHub、GitLab和Bitbucket以及开源项目自有代码管理库上的代码缺陷记录，收集易受攻击的代码样本。CVE数据信息主要来自美国国家计算机通用漏洞数据库（NationalVulnerabilityDatabase，NVD），这是一个由美国国家标准与技术研究院（NationalInstituteofStandardsandTechnology，NIST）维护的漏洞管理数据库。NIST使用各种数据源发布整个NVD数据库供安全人员使用，漏洞数据包含漏洞源、安全检查、与安全相关的软件缺陷、错误配置、产品名称和缺陷影响。缺陷描述文件包含每日更新的CVE漏洞信息，对于较早期的缺陷信息描述，主要按照来源年份有序排列发布。在CVE的描述文件中，每个漏洞都有CVE-ID标号、发布日期、描述、关联参考链接、易受攻击的产品配置、通用缺陷枚举（CommonWeaknessEnumeration，CWE）缺陷分类和其他指标。每个漏洞的严重性都使用通用漏洞评分系统（CommonVulnerabilityScoringSystem，CVSS）进行排名。CVSS由3个指标组成，即基础、时间和环境，漏洞的特征和上下文信息。漏洞影响评分系统存在两个版本：CVSSv2和CVSSv3，它们都对缺陷进行细致描述。CVSSv3为CVSSv2的升级描述，用来更准确地对漏洞进行影响评分，并提供更多信息来区分不同类型的漏洞。当开源项目中的漏洞被修复时，CVE记录信息将更新，增加一个或多个指向相关源代码存储库的引用，包括修复缺陷时提交记录生成的哈希。这些信息可用来在本研究中作为代码缺陷库的组成信息。缺陷数据处理流程如图2所示。图2缺陷数据处理流程2.1.1收集CVE记录信息采集工具从NVD服务器检索所有已发布的JSON格式的漏洞源，搜集范围包括2002年首次发布到收集之日最后一次发布的CVE。然后对获取到的JSON文件进行聚合、加工和处理，滤掉CVE记录中所有在reference字段中没有与之关联的修复程序CVE记录信息，因为这些CVE无法收集相应的易受攻击或已修复的代码。在处理和过滤完缺陷记录后，CVE记录信息包括CVE-ID、发布日期、最后修改日期、参考数据、CVSS严重性评分、漏洞影响和范围、可利用性评分等漏洞的描述。通常，CVE缺陷类型由CWE进行分类，因此还需要收集这些CWE类型的详细信息，并将它们与适当的CVE记录进行映射，用来区分具体的缺陷类型。2.1.2修复记录提取在分析CVE缺陷记录信息时，只分析存在修复记录的CVE，通过提取修复CVE记录信息中与代码相关的开源仓库信息，利用git工具在本地克隆代码项目，并根据CVE记录中提交的哈希值，通过git来收集有关易受攻击的缺陷代码信息，包括代码的语言、版本、发布时间、CVE记录、CWE记录、存储库地址信息、提交记录、受影响的文件和受影响的方法等信息，并将收集到的信息存储在数据库中。2.1.3构建元数据信息CVE中涉及开源项目相关的代码库信息主要来自GitHub、GitLab和Bitbucket，其中项目所属GitHub的比例最高。在抽取缺陷代码信息过程中，需要在缺陷数据库中覆盖代码仓库的项目基本信息，例如存储库名称、描述、创建日期、最后推送日期、主页、编程语言、分支数和星数等指标，这些信息可作为过滤数据的参数，例如星数大小是关注项目成熟度的一个重要评判指标，即星数越大的项目，成熟度越高。2.1.4缺陷代码提取一般来说，只要修复了开源代码漏洞，CVE描述记录就会包含存储库的统一资源定位符（UniformResourceLocator，URL），利用抽取到的缺陷修复提交时生成的哈希和地址信息，通过git即可在本地克隆开源代码项目，并根据哈希信息抽取修复之前和之后的代码信息，这些信息包括缺陷修复时所涉及的代码文件和代码片段。其中提交信息中的每个条目可能与一个或多个CVE相关联。提交的信息还包括作者、时间和日期、提交的描述消息等内容。与缺陷相关的文件信息主要包含更改前后的文件内容，以及在git提交过程中生成的diff信息。此外，还需要收集一些元数据，例如文件名、新旧路径、修改类型（即添加、删除、修改或重命名）、在该文件中添加或删除的行数、代码行数变化等。提取修改后的代码片段，与抽取文件级别的更改过程相似，利用git工具抽取代码片段的变更信息。除代码外，涉及的数据信息，例如片段所在的方法名称、其签名性质、参数、方法的开始行和结束行、代码行数等作为方法元数据信息也会被抽取出来。为了更好地识别文件和代码片段使用的具体编程语言信息，识别过程通过linguist[8]来检测给定代码内容中使用的实际编程语言。2.2缺陷数据索引流程提取缺陷代码后，需要对缺陷数据加工处理，存入数据库中，形成缺陷代码知识库，供查询模块使用。缺陷数据索引流程如图3所示。图3缺陷数据索引流程2.2.1前端解析所有的代码信息都要经过编译处理，用来从程序代码中获取函数信息并分析其词法，但如果源代码不完整或包含语法错误，将会影响整个解析过程。因此，为了保障分析的可靠性，采用antlr4完成代码词法解析，解析过程不需要代码编译构建环境，能够解析单个代码文件，并且在解析过程中遇到语法错误时不会失败，即使被测代码不完整，也会兼容错误分析，保障解析顺利通过。2.2.2预处理规范化整个数据索引和后边的缺陷查询过程均以代码片段为基本单元，查询过程中需要考虑代码相似问题，如图4所示，如下代码可能会存在4种变种情况。图4原始代码片段Type-1：精确相似。被检测代码去掉空格、回车、注释等与代码无关信息后，与缺陷代码保持一致。如图5所示，与原代码相比，代码片段仅少了回车、空格信息。图5Type-1代码片段Type-2：重命名相似。与被检测代码中缺陷代码相比，除了类型、标识符、函数名、注释和空格的修改，其他信息保持一致。如图6所示，与原代码相比，代码片段中的方法名、参数类型做了部分修改，其他信息保持一致。图6Type-2代码片段Type-3：重组相似。即被检测代码与缺陷代码相比，存在进一步的结构修改（例如删除、插入或重新排列语句）。如图7所示，代码片段增加了几条新的语句。图7Type-3代码片段Type-4：语义相似。被检测代码与缺陷代码在语法实现上完全不同，但实现的最终功能相同。如图8所示，代码片段实现的功能与图4相同，但是语法表示方式已经完全不同。图8Type-4代码片段Type-4语义相似目前很难通过代码相似查找实现，故暂不在本研究的范围之内。本次只考虑Type-1、Type-2、Type-3型查询。为了获取更好的查找效果，需要对分词的相似度进行规范化处理。在预处理阶段，为了更准确地找到缺陷代码及其变种，需要从目标源代码中提取代码块并将其转换为token序列，进行重组规范化，这里采用n-gram实现分词重组。对于n而言，选择一个大的数量原则上存在更长的重叠区域，并且携带更多单词信息，精度会更高一些，但是会严重影响处理n-gram所需的内存和磁盘I/O时间。相反，选择小的n-gram允许更大的间隙和更好的匹配灵活性，并且需要更少的内存和磁盘访问时间，但也会导致检索出缺陷代码片段的概率更高，因此需要找到一个合适的n值，在查找速度和结果精度上得到平衡。首先定义一个包含a0、a1、a2及a3的数组：（1）原始表示a0：一个token序列，代表了原始代码片段信息。（2）Type-1表示a1：包含来自原始代码的标记的n-gram的token序列，其为原始代码token序列的组合。（3）Type-2表示a2：包含来自原始代码的标记的n-gram的token序列，其中原始代码token序列中的标识符、文字和类型标记被代表标记替换。（4）Type-3表示a3：包含来自原始代码的标记的n-gram的token序列，除字符{、}、[、]、(、)和；外，其他的全部按标准替换处理。标点符号未标准化，因为它们对代码结构顺序有着重要意义。通过调试分析，当n值为4时，工具表现出了良好的性能。因此，当预处理模块中的4个代码表示为a0时，则表示为原生分词，不做任何排序组合；a1、a2和a3则表示选择了4-gram。3个基于n-gram的表示(a1,a2,a3)是从原有的函数方法内容中演变而来。通过预处理模块的加工组合，将原有的代码结构进行了规范化，从而使其更适合代码搜索。token规范化表示类型如表1所示，其中D代表数据类型，J代表类名，K代表关键字，P代表包，O代表运算符，S代表字符串文字，V代表数字，W代表变量。a2中所有标识符、类型、数字和字符串文字分别被代表标记W、D、V和S替换。a3中所有的分析都替换为它们各自的代表标记形成规范化分词序列。表1token规范化表示类型以图9的代码片段为例，规范化以后的分词序列生成的内容如图10～图13所示。图9代码片段样例图10a0规范化图11a1规范化图12a2规范化图13a3规范化这种预处理能够保障在搜索期间查询的代码关键信息与索引中代码片段的表示相匹配。另外，在索引和查询阶段都会用到预处理规范化技术：在索引阶段，搜索引擎为给定的代码片段创建一个新文档，并将4个表示放在文档内的单独字段中，然后将文档存储在搜索索引中。在查询阶段，通过预处理将查询内容加工为一个组合查询，组合包含4种关键字组成的子查询序列。2.2.3缺陷数据索引数据存储采用非关系索引数据库工具Zinc，其具有索引功能，也是一种轻量级的搜索引擎，能够满足不同用户的各种搜索需求，为所有类型的数据提供近乎实时的搜索和分析。对于结构化或非结构化的文本、数字数据及地理空间数据，都能够以快速搜索的方式高效地存储和索引数据。建立缺陷数据索引的过程主要是对提取的开源代码数据信息进行加工处理。整个流程为：将预处理加工过的规范化序列存储到Zinc数据库中，Zinc会生成反向索引，索引包括一组在document中出现的唯一单词及单词所出现的位置。索引建好后，可以通过Zinc所支持的文件和方法两种类型的代码完成查询，对于完整的代码文件，将代码文件序列化后，以a0方式存入到数据库中。对于文件中的方法，预处理后生成4种规范化标识表示，这些规范化表示可以捕获不同级别的代码结构，能够有效地识别出缺陷代码和缺陷变种。2.3缺陷代码搜索缺陷代码搜索主要利用分词规范化和搜索引擎自身的索引查询功能来搜索代码中是否存在缺陷信息，在缺陷知识库中搜索通过预处理后生成的关键字信息，并利用分词规范化来提高代码缺陷搜索的精度和相似匹配的灵活性。缺陷代码搜索如图14所示。图14缺陷代码搜索当用户提交待查询的代码后，首先对代码进行词法解析和预处理，这个过程与索引阶段采用相同的方式。预处理结束后，一个序列化后的代码查询序列被发送到预处理模块，生成4种查询关键字，利用Zinc检索功能，通过关键字检索组合缺陷库中的索引信息，匹配命中信息，并将最后的结果报告返回给用户。3实验本文通过搜索技术实现了一种开源代码缺陷识别系统，通过一个实例来验证系统的有效性。在大多数情况下，各种Linux发行版默认提供的内核都运行稳定，但有些时候必须重新构造和定制内核来满足实际需求，例如，系统中加入了当前内核不支持的或者尚未启用相应功能的硬件，或者物联网设备操作系统、Android移动操作系统等都需要完成Linux系统的定制迁移。Linux各种主要发行版本中由供应商提供的内核往往明显落后于最前沿的技术，而且它们的更新很不及时，这就导致系统中可能存在既有的安全风险。CVE-2016-5195[9]是LinuxKernel中的条件竞争漏洞，攻击者可以利用Linux内核中的写入复制技术中存在的逻辑漏洞完成对文件的越权读写。具体细节为：Linux内核的内存子系统在处理写入复制（Copy-on-Write）时产生了竞争条件（RaceCondition）。恶意用户可利用此漏洞来获取高权限，对只读内存映射进行写访问。竞争条件是指任务执行顺序异常，可导致应用崩溃，或令攻击者有机可乘，进一步执行其他代码。攻击者可利用这一漏洞提升目标系统权限，甚至可能获得root权限、代码，如图15所示。图15CVE-2016-5195缺陷代码Linux发行版本，如红帽、Debian和CentOS，已经发布了更新来解决内核上存在的问题，但是很多由公司维护的移动操作系统却没有更新该内核漏洞。使用本文提出的源代码安全漏洞挖掘技术分析Android7.0、Andr