Movery: A Precise Approach for Modified Vulnerable Code Clone Discovery from Modified Open-Source Software Components

Abstract

从第三方开源软件（OSS）组件继承的漏洞可能会危及整个软件的安全。然而，由于这些漏洞在不同的代码语法中广泛传播，因此发现传播的易受攻击代码是一项挑战，特别是由于OSS的内部更新和修改（例如，在OSS复用过程中发生的代码更改）。

在本文中，我们提出了一个名为Movery的精确方法，用于从修改过的OSS组件中发现易受攻击的代码克隆（VCC）。通过选择性地识别和提取只涉及核心漏洞和修补程序行的修改，Movery生成漏洞和修补程序签名，有效地解决了OSS修改的问题。为了可扩展性，Movery专注于仅从其他OSS项目借用的代码。最终，Movery通过匹配漏洞签名并与修补程序签名具有区别性来确定函数是否是VCC。

当我们将Movery应用于十个流行的软件选择自不同领域时，我们观察到91%的发现的VCC直接影响到了脆弱功能。然而，Movery发现的VCC至少比现有技术多2.5倍，且具有更高的精度和召回率：Movery发现了415个VCC，其精度高达96%；而那些几乎不考虑OSS内部和外部修改的现有VCC发现技术，只发现了163个和72个VCC，其精度最高为77%，召回率为38%。

INTRODUCTION

Background

  1. OSS重用的益处与风险：开源软件的广泛使用使开发人员能够重用来自可靠OSS项目的功能。然而，这种重用也可能导致第三方OSS中的漏洞传播，从而威胁到整个系统的安全。
  2. OSS更新的复杂性：为了防止通过重用OSS传播的漏洞，开发人员可能选择将上游的安全补丁回移（backport）到他们的项目中，而不是更新整个组件。这种做法可以避免快速更新可能带来的问题，例如与旧系统的兼容性问题。
  3. 易受攻击代码的识别：开发人员需要识别组件中需要修复的易受攻击代码，通常借助于易受攻击代码克隆（VCC）发现技术和软件组成分析（SCA）技术来实现。
  4. 挑战：精确地发现来自修改过的OSS组件的漏洞正变得越来越困难。主要的挑战是由于OSS的内部修改（如版本更新）和外部修改（如重用过程中的代码修改）引起的“语法多样性”。
  5. OSS修改的影响：OSS的内部和外部修改会影响漏洞代码的语法，使得这些代码的语法可能与公开的漏洞数据库中披露的漏洞代码不同。这种语法多样性降低了现有技术发现传播的漏洞代码的准确性。

总之，文本强调了在OSS组件中识别和处理易受攻击代码的重要性和复杂性，尤其是在面对代码的频繁修改和更新时。同时，它指出了现有方法在处理语法多样性方面的不足，强调了需要更精确的技术来识别和修复这些漏洞。

Limitations of existing techniques

易受攻击的代码克隆（VCC）

现有技术的限制：目前的VCC发现技术主要集中于检测OSS的外部修改，而忽略了内部修改。这种方法容易产生很多假阴性结果，因为它们无法检测到由安全补丁删除的代码行。

软件组成分析工具的问题：现有的软件组成分析（SCA）工具在确定漏洞时依赖于重用的OSS版本，这可能导致假阳性，尤其是当漏洞代码通过回移补丁修复或未被重用时。

代码克隆检测技术的不足：现有的代码克隆检测技术可以用来发现VCC，但由于它们无法区分易受攻击和已修补的代码，因此也容易产生假阳性，尤其是在代码相似度高的情况下。 –> 传统代码克隆检测技术，可以参考

Movery方法的引入：为了克服这些缺陷，文中提出了Movery（Modified Vulnerable code clone discOVErY）方法，这是一种精确的方法，专门用于从修改过的OSS组件中发现修改过的易受攻击的代码克隆。

Approach

这段文本详细介绍了Movery方法的核心思想和实施步骤。以下是对这段文字的概括：

  1. 核心思想： Movery的关键特点在于生成一个可扩展的签名，该签名不仅包括已披露的易受攻击功能，还包括最早的易受攻击函数，以解决OSS的内部修改问题。这种方法有助于捕捉随时间变化的漏洞代码。
  2. 两阶段实施：
    • 阶段一（P1）：在这个阶段，Movery通过结合易受攻击和修补后的功能来生成漏洞和补丁签名。它采用了称为“函数比对”和“核心行提取”的技术，通过比对最早的和已披露的易受攻击函数，生成仅包含核心易受攻击和修补代码行的签名。
    • 阶段二（P2）：利用生成的签名在目标软件中发现VCC。Movery为了可扩展性，使用了一种简化的代码片段，以发现那些包含外部OSS修改的VCC。最终，Movery通过比较目标软件中的函数与漏洞签名以及与修补签名的区别性，来确定是否发现了易受攻击的代码克隆。

总之，Movery通过一个精确且有系统的方法来探测和识别被修改过的开源软件组件中的易受攻击代码克隆，特别强调对OSS内部和外部修改的考量。这种方法在现有的漏洞发现技术中是独特的，因为它能更全面地捕捉到漏洞代码的变化和传播。

PATEN也可以考虑分为两个阶段实施，第一个阶段是identify 

Evaluation

这段文本是对Movery方法进行评估的一部分，展示了其在发现易受攻击的代码克隆（VCCs）方面的优越性和效率。以下是这段文字的概括：

  1. 性能对比：
    • Movery在实验中显著优于现有的VCC发现技术，如ReDeBug和VUDDY。Movery能够发现的VCC数量至少是现有技术的2.5倍，并且具有更高的精确度和召回率。
    • Movery在识别VCCs时展示了96%的精确度和召回率，而ReDeBug和VUDDY的最高精确度分别为77%和38%的召回率。
  2. 内部和外部修改的考虑：
    • Movery的高效表现部分归功于其考虑了OSS的内部和外部修改，以及VCC的语法多样性，这些是其他技术常忽略的方面。
  3. 与其他技术的比较：
    • 与其他重复漏洞检测技术（如MVP）和软件组成分析（SCA）技术（如CENTRIS）相比，Movery展现了更高的准确性。特别是在考虑内部OSS修改和安全补丁回移方面，Movery减少了假阴性和假阳性的发生。
  4. 效率评估：
    • Movery不仅准确，而且快速。在处理各种大小的C/C++代码时，平均处理时间约为200秒，比ReDeBug和VUDDY的处理时间短，这表明Movery既有效又适用于实际应用。

总体来说，这段文本强调了Movery在发现修改过的OSS组件中的VCC方面的高效性和精确性，特别是它如何克服了现有技术在处理OSS修改和语法多样性方面的限制。

Contributions

  • Movery是第一个精确发现修改过的开源软件（OSS）组件中易受攻击的代码克隆（VCCs）的方法。其核心技术是生成能够处理OSS内部和外部修改的签名。

  • 研究表明，OSS的内部修改在VCCs的语法多样性中起着主导作用，这是现有技术往往忽视的一个方面。

  • 尽管在修改过的组件中，大部分（91%）的VCCs的语法与披露的易受攻击功能不同，Movery依然能够在多种领域选择的十个目标软件中发现415个VCCs，实现了96%的精确度和召回率。

Motivation

2.1 Problem statement

  1. 问题声明：
    • 重点在于发现在修改过的OSS组件中传播的漏洞。假设一个漏洞在OSS中被引入后又被修补。文中定义了三种功能：已披露的漏洞功能（fd），修补后的功能（fp），以及包含在较旧版本OSS中的易受攻击功能（f0），后者的代码语法与fd不同。
  2. 漏洞功能的传播分类：
    • 根据是否对代码进行了修改，将漏洞功能的传播分为四类：
      • C1：fd 被重用，无代码修改。
      • C2：fd 被重用，有代码修改。
      • C3：f0 被重用，无代码修改。
      • C4：f0 被重用，有代码修改。
  3. 技术挑战：
    • 主要的技术挑战是应对漏洞代码的语法多样性，这主要源于OSS的内部和外部修改。
      • 内部修改：OSS源代码在版本更新中频繁变化，影响易受攻击功能的语法。
      • 外部修改：开发者对OSS组件应用自己的代码补丁，也会改变易受攻击功能的语法。
  4. 现有技术的限制：
    • 现有的易受攻击代码克隆（VCC）发现技术主要覆盖C1和部分C2类，因此容易产生许多假阴性。这些技术通常只定义安全补丁中删除的代码行为“易受攻击行”，在f0中可能不存在这些行，因为OSS的修改导致这些行的丢失。

image-20240817202104092

2.2 Motivating examples

两个动机示例，用以展示在处理修改过的开源软件（OSS）组件中的漏洞传播时存在的挑战和技术难题。以下是对这部分内容的概括：

  1. 示例1 - LibZip中的内存分配失败漏洞（CVE-2017-14107）：

    • PHP团队利用了旧版本的LibZip，并引入了针对该漏洞的补丁。由于代码修改，PHP中的漏洞函数语法与LibZip中公开的漏洞语法不同。这导致PHP团队无法直接应用安全补丁，而是必须修改后再应用到他们的代码库中。
    • 测量的Jaccard相似度仅为13%，显示出源代码与修补版本之间的显著差异。
    image-20240817202532282

  2. 示例2 - Lua中的缓冲区溢出漏洞（CVE-2014-5461）：

    • Redis使用了包含漏洞的Lua版本，并引入了针对该漏洞的补丁。由于Redis复用了旧版Lua的代码，因此在应用补丁时遇到了类似的问题，Redis中的漏洞函数与Lua公开的漏洞函数语法不同。
    • 尽管Redis团队对Lua的漏洞进行了补丁回移，现有的软件组成分析（SCA）技术误判认为Redis仍包含漏洞。
image-20240817203335007

这两个示例突出了发现和修复漏洞的复杂性，尤其是当漏洞代码在多个版本和不同项目中被复用并修改时。现有的易受攻击代码克隆（VCC）发现技术往往无法有效处理这种情况，因为它们无法识别因内部和外部修改而产生的代码变化。这种复杂性要求开发更先进的方法，如Movery，来提高识别修改过的漏洞代码的能力。

Methodology of MOVERY

在本节中，我们描述了Movery的方法论。Movery包括以下两个阶段：签名生成阶段（P1）和易受攻击代码克隆发现阶段（P2）。在P1阶段，Movery使用称为函数对比和核心行提取的技术来生成可扩展的签名，以应对易受攻击代码的语法多样性。在P2阶段，为了可扩展性，Movery通过仅关注从其他开源软件（OSS）借用的代码部分来减少目标软件的搜索空间。在此基础上，Movery在目标软件中发现一个易受攻击代码克隆：这个函数与补丁签名不同，同时匹配漏洞签名。Movery的高级工作流程展示在图2中。

3.1 Signature generation (P1)

在3.1节中，文本详细描述了Movery方法中的签名生成阶段（P1），这是Movery方法的一个关键组成部分，涉及创建用于VCC发现的签名。以下是这部分内容的详细概括：

签名生成的原则

Movery的签名生成遵循三个基本原则：

  1. 最小化（Minimization）：为了应对语法多样性，生成的签名应包含尽可能少的代码行，这些代码行是在披露的漏洞中必需的，从而能够有效地识别核心漏洞和修补代码。
  2. 可扩展性（Extensibility）：签名应具备可扩展性，能够适应OSS修改，确保可以检测到多种形式的VCC。
  3. 可感知性（Perceptibility）：签名应能确定在传播的漏洞代码中是否仍保留了环境依赖性，即核心漏洞特征是否依然存在。

签名生成过程

签名生成分为几个关键步骤：

  1. 核心漏洞和修补行提取（Essential Vulnerable and Patch Line Extraction）：
    • 基本定义：定义*essential vulnerable lines (Ev)为那些在fdf_dfd和f0f_0f0中同时存在但在fpf_pfp中不存在的代码行；essential patch lines (Ep)*则是在安全补丁中出现但在f0f_0f0和fdf_dfd中不存在的代码行。
    • 这些行是生成签名的基础，因为它们代表了漏洞的核心部分。
  2. 依赖漏洞和修补行提取（Dependent Vulnerable and Patch Line Extraction）：
    • 定义：dependent vulnerable lines (Dv) 和 dependent patch lines (Dp) 是那些在核心漏洞行和修补行基础上依赖的代码行。
    • 这些行帮助更全面地描述漏洞行为，尤其是当漏洞的表现依赖于特定代码上下文时。
  3. 控制流程代码行提取（Control Flow Code Line Extraction）：
    • 定义：vulnerable control flow code lines (Fv) 是那些直接与控制流程相关的条件语句，这些语句通常直接关联到核心漏洞行。
    • 包括这些代码行是为了确保环境中的漏洞特征得以准确标识。

签名的最终形成

  • Movery通过整合上述提取的所有关键行（Ev, Dv, Fv, Ep, Dp）来生成漏洞签名 Sv 和修补签名 Sp。
  • 技术手段：使用规范化和抽象化技术来处理签名中的代码行，以确保签名的一致性和准确匹配。规范化包括移除空白符和注释，统一字符格式；抽象化则涉及替换参数名、变量类型等，以减少不必要的变异导致的误差。

这个阶段的核心目标是生成精确而有效的签名，这些签名能够在随后的VCC发现阶段中被用来识别和匹配目标软件中的漏洞代码，即便这些代码在不同的OSS项目中经历了修改。

3.2 Vulnerable code clone discovery (P2)

在3.2节中，文本详细描述了Movery方法中的易受攻击代码克隆（VCC）发现阶段（P2），这是识别目标软件中潜在漏洞的关键过程。以下是对这部分内容的详细概括：

易受攻击代码克隆发现

  • Movery在这一阶段使用两种技术：搜索空间缩减和选择性抽象匹配，以实现可扩展且精确的VCC发现。
  • 搜索仅限于目标软件中重用的OSS组件代码部分，称为“借用代码部分”。
  • 通过这种方法，Movery能够确定目标软件中的函数是否是VCC，依据是函数包含漏洞签名 Sv、不包含补丁签名 Sp，并且与已知的易受攻击函数 fo 或 fd 的语法相似。

搜索空间缩减

  • 通过识别目标软件 T 中与已知易受攻击开源软件组件 C 共享的代码部分，减少需要搜索的代码基。
  • Movery首先提取目标软件和组件间共有的函数信息，然后关注这些共有函数可能存在的漏洞。
  • 这种方法允许Movery专注于最可能包含VCC的代码区域，从而提高发现的效率和准确性。

选择性抽象匹配

  • Movery在签名和目标软件之间进行抽象匹配，以解决代码在不同项目间的轻微变化带来的挑战。
  • 这种匹配首先涉及规范化和抽象化过程，将代码中的变量名、类型等统一化，以减少匹配过程中的噪声。
  • 抽象化处理后的代码行用于匹配，确保即使在变量名称或其他次要细节上有差异，也能正确识别VCC。

VCC的定义和确认

  • 一个函数被定义为VCC，如果它满足三个条件：包含 Sv、不包含 Sp，并且其语法与 fo 或 fd相似。
  • Movery通过检查这些条件来确认目标软件中的函数是否为VCC，特别关注那些即使在代码语法上有显著变化后仍然保持漏洞特征的函数。

实验和效果

  • 实验结果显示Movery能够在各种情况下有效地识别VCC，即使在只有漏洞代码行少于30%的情况下也能有效工作。
  • 这表明Movery的方法在实际应用中具有高度的适用性和灵活性，能够处理各种复杂的代码变异情况。

总体来看，3.2节强调了Movery在准确识别目标软件中易受攻击代码克隆的能力，特别是它如何有效地处理代码变异和跨项目代码重用的挑战。

Implementation of MOVERY

4.1 Vulnerability dataset

漏洞数据集的收集

  1. 收集安全补丁：
    • 利用之前研究的方法，通过National Vulnerability Database (NVD) 收集了安全补丁。
    • 在参考文献中检查是否包含git提交URLs，然后从相应的Git仓库中抓取补丁提交。
    • 选择了C/C++漏洞作为初始目标，收集了4,219个C/C++安全补丁。
  2. 重构函数：
    • 从收集到的安全补丁中重构出易受攻击的函数和修补后的函数。
    • 关注安全补丁的头部信息，并提取包含代码行添加或删除的函数。
    • 排除那些代码变更不是为了修复漏洞的函数对。
  3. 重构最旧易受攻击函数：
    • 通过NVD的平台枚举（CPE）确定从哪个软件版本开始提取漏洞代码。
    • 为每个CVE手动验证正确的CPE，并从中确定包含易受攻击函数的最旧版本。
    • 访问最旧的易受攻击版本，并提取其中的易受攻击函数。

数据集观察

  • 在5,936个易受攻击函数中，78%的情况下，最新的易受攻击函数（fd）和最旧的易受攻击函数（fo）在语法上有所不同。
  • 对每对fd和fo计算Jaccard相似性，平均相似性得分为56%。
  • 这表明内部OSS修改在易受攻击代码的语法多样性中起着重要作用，且在易受攻击代码克隆发现中应考虑这一点。

这一节强调了在VCC发现过程中考虑内部OSS修改的重要性，并展示了漏洞数据集的构建过程对理解和分析漏洞传播的重要贡献。

4.2 Architecture

在4.2节中，文本描述了Movery工具的体系结构，该工具分为三个主要模块：数据集收集器、签名生成器和VCC发现器。以下是对这部分内容的详细概括：

Movery的三大模块

  1. 数据集收集器：
    • 负责收集安全补丁和重构易受攻击的函数，这些函数将用于后续的漏洞和修补签名生成。
  2. 签名生成器：
    • 从重构的函数中生成漏洞和修补签名，这些签名用于识别目标软件中的易受攻击代码克隆。
    • 每个模块包括800至1,000行Python代码，不包括外部库或作为功能解析器的组件。
  3. VCC发现器：
    • 执行实际的易受攻击代码克隆发现工作，在目标软件中识别和标记潜在的漏洞代码。

功能解析与分析

  • Movery利用了通用的Ctags工具和开源的Joern解析器来提取函数，Ctags用于从易受攻击文件、补丁文件和目标软件中提取函数。
  • Joern解析器用于分析函数的控制流和数据依赖关系，这对于生成涵盖抽象语法树、程序依赖图和控制流图的综合图尤为重要。
  • 此综合图允许Movery在生成签名时，不仅考虑代码行的内容，还考虑其在整个程序结构中的上下文关系。

公共可访问性

  • Movery的源代码已公开发布在GitHub上，任何人都可以访问和使用这些工具，以便于其他研究者或开发者利用或改进Movery的功能。

这一节详细阐述了Movery的内部构造和工作机制，突出其模块化设计和高度集成的分析工具，这些都是进行有效的漏洞检测和代码克隆发现所必需的。

Evaluation

在这一部分中，我们对Movery进行了评估。第5.1节调查了Movery在发现修改过的组件中的易受攻击代码克隆（VCCs）的准确性，并将其与现有的VCC发现技术（即VUDDY和ReDeBug）进行了比较。第5.2节和第5.3节分别将Movery与重复漏洞检测技术（即MVP）和基于SCA的技术（即CENTRIS）进行比较。我们在第5.4节评估了Movery的速度和可扩展性，并在第5.5节介绍了搜索空间缩减的效果。最后，第5.6节提供了我们实验中观察到的案例研究。我们在一台装有Ubuntu 16.04，Intel Xeon处理器2.40 GHz，32GB RAM和6TB HDD的机器上运行了Movery。

image-20240817215542955

5.1 Accuracy of MOVERY

5.1节描述了如何评估Movery在发现易受攻击代码克隆（VCCs）方面的准确性，并将其与现有技术如ReDeBug和VUDDY进行了比较。

目标软件的选择

  • 选取的目标软件基于以下三个标准：具有广泛的OSS影响（C/C++），包含大量修改的组件，以及至少存在一个Movery能够发现的VCC。
  • 从GitHub收集C/C++存储库，并使用CENTRIS工具确定其中包含较多修改的OSS组件。最终选择的软件涉及不同的应用领域，从操作系统到图像处理等。

准确性评估

  • Movery在从121个CVEs中发现的434个VCC中表现出色，这些VCC在不同的实现中有着显著的语法变异。
  • 尽管OSS修改导致了396个VCCs（91%）存在不同的漏洞语法，Movery还是成功地发现了415个VCCs，展示了96%的精确度和96%的召回率。
  • 相比之下，ReDeBug发现了163个VCCs，精确度和召回率分别为77%和38%；VUDDY发现了72个VCCs，精确度和召回率分别为77%和17%。

误报和误漏分析

  • 分析显示，ReDeBug和VUDDY在处理OSS修改导致的代码语法变化时遇到困难，特别是当安全补丁不能直接适用于目标代码时。
  • Movery使用选择性抽象匹配技术，有效地减少了由于语义相似但语法改变造成的误报（FPs）和误漏（FNs）。

实验设置

  • 实验在配置为Ubuntu 16.04，配备Intel Xeon 2.40 GHz处理器，32GB RAM和6TB硬盘的机器上进行。

总体来看，5.1节强调了Movery在处理由OSS内部修改引起的语法多样性方面的优势，通过高精度和高召回率展示了其在实际应用中的有效性和可靠性。此外，与现有技术相比，Movery在识别修改过的代码中的漏洞方面表现出显著的改进。

5.2 Comparison with MVP

5.2节描述了Movery与MVP（一种重复漏洞检测技术）的比较，以展示Movery在发现修改过的组件中易受攻击代码克隆（VCCs）方面的效果。

Movery与MVP的比较

  • 背景与目标：MVP是一种旨在发现重复漏洞的技术。Movery与MVP的比较旨在验证Movery在识别修改过的OSS组件中VCCs的有效性。

实验设计与结果

  • 实验结果：
    • MVP在目标软件上发现了220个VCCs，同时报告了46个误报（FPs）和8个漏报（FNs）。
    • MVP很难识别因OSS内部修改而演化的VCCs，尤其是那些代码行在演化过程中被删除的情况（类型T1和T2）。
  • 分析MVP的局限：
    • MVP因未能识别修改过的变量类型和派生的函数名称等细节变化，而未能检测到许多VCCs。
    • MVP产生的46个FPs中，26个因方法相似但语法不一致的代码被误判为漏洞。
    • 另外35个FPs是由于MVP无法正确处理安全补丁中的变量名称和其他抽象化目标的更改而产生。

Movery的优势

  • 选择性抽象匹配：Movery使用选择性抽象匹配技术，提高了在检测经过修改的OSS组件中VCCs的精度和效率，减少了误报。
  • 遗漏的VCCs：尽管MVP发现了Movery遗漏的8个VCCs，但Movery在处理由OSS内部修改引起的VCCs方面显示出更好的性能。

效果与应用

  • MVP的目标与限制：MVP旨在检测重复漏洞，而非专门针对修改过的组件。因此，Movery在处理这些特定场景时表现更佳。
  • 研究重点：强调Movery在发现由OSS修改引起的VCCs方面的专业性和适用性，而不是贬低MVP的总体效能。

总体来看，5.2节通过与MVP的比较，突出了Movery在处理OSS组件修改后VCCs检测方面的专业能力和高效性，尤其在处理因内部修改导致的代码变异上表现出色。

5.3 Comparison with CENTRIS

在5.3节描述了Movery与CENTRIS（一种基于软件组成分析的技术）的比较，旨在评估两种技术在发现修改过的开源软件（OSS）组件中的易受攻击代码克隆（VCCs）的效果

Movery与CENTRIS的比较

  • 背景：CENTRIS是一种旨在发现OSS组件中漏洞的技术，但它通常不考虑组件的修改。

实验设计与结果

  • 实验结果：
    • CENTRIS在目标软件上发现了553个VCCs，但其中272个被证实为误报（FPs），这些误报主要因为漏洞代码没有包含在补丁中或者代码是通过反向移植更新的（例如，前文提到的2.2节中介绍的情况）。
    • CENTRIS未能发现Movery检测到的152个VCCs，这些VCCs要么是因为CENTRIS没有覆盖相关的组件，要么是因为CENTRIS预测的漏洞版本不准确。
    • 最终，CENTRIS未能识别37个VCCs，而这些VCCs被Movery成功发现。

分析与讨论

  • 误报与漏报：
    • CENTRIS产生的大量误报主要是由于其对OSS组件内部修改的不足考虑，特别是在不通过Git发布补丁的情况下。
    • Movery表现出在处理修改过的组件时的优势，能够更准确地识别和区分真正的漏洞代码。

效果与应用

  • Movery的优势：
    • 与CENTRIS相比，Movery在处理由于OSS内部修改而产生的代码变化时显示出更好的适应性和准确性。
    • Movery在识别被动态修改过的组件中的漏洞方面表现更为出色，能够减少误报并提高发现真实漏洞的能力。

总体来看，5.3节通过与CENTRIS的比较，展示了Movery在识别和处理由OSS内部修改引起的VCCs方面的专业能力和高效性，尤其在减少误报和提高漏洞发现准确性上表现突出。

5.4 Speed and scalability of MOVERY

image-20240817220437848

在5.4节中描述了Movery在易受攻击代码克隆（VCC）发现中的速度和可扩展性。

Movery的性能评估

  • 总体时间分类：评估Movery在VCC发现中所需的总时间分为三个部分：签名生成、目标预处理、以及匹配时间。

各阶段的时间分析

  1. 签名生成时间：
    • Movery使用收集的4,219个安全补丁生成签名，耗时32小时。与之对比，VUDDY仅需2小时，因为它直接使用补丁而不需要重建最旧的易受攻击函数或分析函数的代码行依赖。
  2. 目标预处理和匹配时间：
    • VUDDY：在三种工具中，预处理时间最长。
    • Movery：匹配时间最长，但在总时间上是最少的，这反映了其高效的预处理过程。
    • 尽管Movery在匹配阶段花费更多时间，这主要是因为它使用更精细的粒度（即代码行级别而不是功能单位），并考虑了代码依赖，这使得匹配过程更为复杂。

性能优化和实用性

  • 尽管Movery在某些阶段时间较长，它提供的精细粒度和深入的代码分析使得在200秒内就可以完成目标预处理和匹配，表明其在实际使用中的可行性。
  • Movery的设计允许在软件的代码行数从213千行到14.5百万行变化时，其性能表现稳定，显示出良好的可扩展性。

结论

5.4节通过分析Movery在VCC检测中的时间效率展示了其在处理大规模数据时的能力。虽然某些阶段如签名生成和匹配较为耗时，但其整体所需时间最少，并且显示了优于或可比拟于现有技术（如VUDDY和ReDeBug）的性能。

5.5 Efficacy of the search space reduction

在5.5节描述了Movery如何通过聚焦于目标软件中的“借用”代码部分来减少搜索空间，从而提高搜索效率和准确性。

搜索空间减少的有效性

  • 搜索空间缩减：
    • Movery专注于目标软件中重用的OSS组件的代码部分，而非整个代码库，显著减少了需要扫描的代码行数。
    • 在分析的十个目标软件中，总共有28,548,340行代码，其中被认为是“借用”的部分大约有375,489行（占总行数的约1.3%），从而使得扫描的工作量减少了大约53%。

可扩展性和准确性的提升

  • 可扩展性改进：
    • 通过减少需要分析的代码量，Movery在处理大规模软件项目时的可扩展性得到了显著提升。
    • 这种方法允许Movery更高效地管理资源，处理更大的数据集，而不牺牲性能。
  • 准确性增强：
    • 由于Movery仅考虑重用的OSS组件中的代码，这减少了误报（FPs）的发生，因为它避免了在不相关的代码部分中误识别VCCs。
    • 相比之下，VUDDY和ReDeBug在“借用”代码区域之外发现的误报分别为3个和24个。Movery通过聚焦于真正包含OSS的代码部分，有效地减少了这些误报。

总结

5.5节展示了Movery通过减少需要分析的代码空间来提高效率和准确性的策略。这种方法不仅提高了处理大数据集的能力，也优化了VCC检测的准确性，减少了误诊，特别是在大规模软件系统中。