评估广泛使用的视觉模型安全状况：YOLOv7 - Trail of Bits 博客

Alvin Crighton, Anusha Ghosh, Suha Hussain, Heidy Khlaaf, JimMiller2023 年 11 月 15 日机器学习

TL;DR: 我们在流行计算机视觉框架 YOLOv7 中发现了 11 个安全漏洞，这些漏洞可能导致远程代码执行（RCE）、拒绝服务和模型差异（攻击者可在不同场景下触发模型产生不同行为）等攻击。

开源软件为许多广泛使用的 ML 系统提供了基础。然而，这些框架开发速度过快，往往以牺牲安全性和稳健性为代价。此外，这些开源模型和框架并非专门为关键应用设计，却因势头或流行度而被大规模采用。这些软件项目中很少经过严格审查，导致潜在风险增加，出现未识别的供应链攻击面，影响模型及其相关资产的机密性、完整性和可用性。例如，ML 生态中广泛使用的 pickle 文件可被利用实现任意代码执行。

鉴于这些风险，我们决定评估流行且成熟的视觉模型 YOLOv7 的安全性。本文分享并讨论了我们的审查结果，包括轻量级威胁模型和安全代码审查，我们的结论是 YOLOv7 代码库不适用于关键任务应用或需要高可用性的应用。完整公开报告链接见此处。

免责声明： YOLOv7 是学术成果。学术原型并非为生产环境准备，也不具备适当的安全卫生，我们的审查并非批评作者或其开发选择。然而，与许多 ML 原型一样，它们已被生产系统采用（例如 YOLOv7 被 Roboflow 推广，拥有 3.5k 分叉）。我们的审查仅旨在揭示使用此类原型而未经进一步安全审查的风险。

根据我们的负责任披露政策，我们联系了 YOLOv7 仓库的作者，告知他们我们发现的问题。未收到回复，但我们提出了具体解决方案和更改以缓解已识别的安全漏洞。

什么是 YOLOv7？

You Only Look Once (YOLO)是最先进的实时物体检测系统，其高精度和良好性能的结合使其成为嵌入关键任务应用（如机器人、自动驾驶汽车和制造）中的视觉系统的热门选择。YOLOv1 最初于 2015 年开发；其最新版本 YOLOv7 是由 Academia Sinica 开发的 YOLO 开源代码库修订版，实现了相应的学术论文，概述了 YOLOv7 如何优于基于 transformer 和基于卷积的物体检测器（包括 YOLOv5）。

该代码库拥有超过 3k 分叉，允许用户提供自己的预训练文件、模型架构和数据集来训练自定义模型。尽管 YOLOv7 是学术项目，YOLO 是物体检测的事实算法，常被商业和关键任务应用使用（例如由 Roboflow 使用）。

我们的发现

我们的审查识别了五个高严重性和三个中严重性发现，我们将其归因于以下不安全实践：

• 代码库未以防御性方式编写；没有单元测试或测试框架，输入验证和清理不足。

• 完全信任可从外部源获取的模型和配置文件。

• 代码库危险且不必要地依赖宽松函数，引入了 RCE 向量。

下表总结了我们的高严重性发现：

常见做法是从外部源（如 PyTorch Hub）下载数据集、模型 pickle 文件和 YAML 配置文件。为在目标机器上破坏这些文件，攻击者可将恶意文件上传到这些公共源之一。

构建威胁模型

对于我们的审查，我们首先进行了轻量级威胁模型以识别威胁场景和最关键的组件，进而指导我们的代码审查。我们的方法借鉴了 Mozilla 的“快速风险评估”方法和 NIST 的以数据为中心的威胁建模指南（NIST 800-154）。我们审查了 YOLO 学术论文、YOLOv7 代码库和用户文档，以识别所有数据类型、数据流、信任区（及其连接）和威胁参与者。然后使用这些工件开发全面的威胁场景列表，记录系统中存在的每个可能威胁和风险。

威胁模型考虑了 ML 流水线的独特架构（相对于传统软件系统），由于 ML 生命周期和流水线中的新攻击面（如数据收集、模型训练和模型推理与部署）而引入了新颖的威胁和风险。相应的威胁和失败可能导致模型性能下降、数据收集和处理被利用以及输出被操纵。例如，从不可靠或不安全源下载数据集可能导致数据集中毒和模型性能下降。

因此，我们的威胁模型旨在检查 ML 特定的入口区域，并概述 YOLOv7 代码库的重要子组件。基于对 YOLOv7 工件的评估，我们构建了以下数据流图。

图 1：轻量级威胁模型中生成的数据流图

请注意，此图和我们的威胁模型不针对特定应用或部署环境。我们识别的场景旨在聚焦于开发人员在其生态系统中部署 YOLOv7 之前应考虑的一般 ML 威胁。我们总共识别了十二个威胁场景，涉及三个主要威胁：数据集泄露、主机泄露和 YOLO 进程泄露（例如将恶意代码注入 YOLO 系统或其依赖项之一）。

代码审查结果

接下来，我们对 YOLOv7 代码库进行了安全代码审查，重点关注威胁模型威胁场景中识别的最关键组件。我们使用了手动和自动化测试方法；我们的自动化测试工具包括 Trail of Bits 的自定义 Semgrep 规则仓库，这些规则针对 PyTorch 等 ML 框架的误用，并在 YoloV7 代码库中识别了一个安全问题和一个代码质量问题。我们还使用了 TorchScript 自动跟踪检查工具来自动检测跟踪模型中的潜在错误。最后，我们在代码库中使用了公共 Python CodeQL 查询，并识别了多个代码质量问题。

总共，我们的代码审查发现了十二个安全问题，其中五个为高严重性。审查还发现了十二个代码质量发现，作为增强代码库质量和可读性以及防止未来漏洞引入的建议。

所有这些发现都表明系统未以防御性视角编写或设计：

• 五个安全问题可能单独导致 RCE，大多数由不必要且危险地使用宽松函数（如 subprocess.check_output、eval 和 os.system）引起。参见以下示例亮点。

• 用户和外部数据输入验证和清理不足。多个问题允许拒绝服务攻击，如果最终用户可以控制某些输入，如模型文件、数据集文件或配置文件（TOB-YOLO-9、TOB-YOLO-8、TOB-YOLO-12）。例如，代码库允许工程师提供自己的配置文件，无论它们代表不同的模型架构还是预训练文件（鉴于 YOLO 模型架构的不同应用）。这些文件和数据集被加载到训练网络中，使用 PyTorch 训练模型。为了更安全的设计，需要大幅减少对外部输入的信任，并仔细清理和验证这些值。

• 代码库中目前没有单元测试或任何测试框架（TOB-YOLO-11）。适当的测试框架本可以防止我们发现的一些问题，而没有这个框架，代码库中可能存在其他实现缺陷和错误。此外，随着系统继续发展，没有任何测试，代码回归很可能发生。

以下，我们重点介绍一些高严重性发现的细节，并讨论它们对基于 ML 的系统的影响。

安全代码审查亮点 #1：YAML 解析如何导致 RCE

我们最显著的发现是关于 YAML 文件的不安全解析可能导致 RCE。与许多 ML 系统一样，YOLO 使用 YAML 文件指定模型架构。不幸的是，YAML 解析函数 parse_model 通过调用 eval 对文件的未验证内容进行解析，如以下代码片段所示：

图 2：models/yolo.py 中 parse_model 的片段

如果攻击者能够操纵目标用户使用的这些 YAML 文件之一，他们可以注入恶意代码，在解析期间执行。这尤其令人担忧，因为这些 YAML 文件通常从第三方网站获取，这些网站托管这些文件以及其他模型文件和数据集。复杂攻击者可以破坏这些第三方服务或托管资产之一。然而，如果仔细且经常检查这些 YAML 文件，可以检测到这个问题。

鉴于这个发现的潜在严重性，我们提出了一个替代实现作为缓解措施：通过将配置文件中定义的给定架构重写为调用标准 PyTorch 模块的不同块类，完全消除对 parse_model 函数的需求。此重写有几个目的：

• 消除了对未清理输入调用 eval 的固有漏洞。

• 块类结构更有效地复制了实现论文中提出的架构，允许更容易复制给定架构和定义类似结构的后续迭代。

• 提供了一个更可扩展的基础来继续定义配置，因为这些类很容易根据用户设置的不同参数进行修改。

我们提议的修复可以在此跟踪。

安全代码审查亮点 #2：ML 特定漏洞和改进

如前所述，ML 框架正在导致针对模型及其相关资产的机密性、完整性和可用性的新颖攻击途径增加。我们在安全评估期间发现的 ML 特定问题亮点包括：

• YOLOv7 代码库使用 pickle 文件存储模型和数据集；这些文件未经验证，可能从第三方源获取。我们先前发现，pickle 文件在 ML 生态中的广泛使用是一个安全风险，因为 pickle 文件允许任意代码执行。为了反序列化 pickle 文件，一个称为 Pickle Machine (PM)的虚拟机将文件解释为一系列操作码。PM 中包含的两个操作码 GLOBAL 和 REDUCE 可以在 PM 之外执行任意 Python 代码，从而实现任意代码执行。我们构建并发布了fickling，一个用于逆向工程和分析 pickle 文件的工具；然而，我们进一步建议 ML 实现使用更安全的文件格式，如 safetensors。

• YOLOv7 跟踪其模型的方式可能导致模型差异——即，正在部署的跟踪模型的行为与原始未跟踪模型不同。特别是，YOLO 使用 PyTorch 的 torch.jit.trace 将其模型转换为 TorchScript 格式进行部署。然而，YOLOv7 模型包含许多跟踪器边缘情况：跟踪未准确捕获的模型元素。最显著的发生是包含输入依赖控制流。我们使用 TorchScript 的自动跟踪检查器通过生成一个输入来确认这种分歧，该输入根据模型是否被跟踪而产生不同输出，这可能导致后门。攻击者可以发布一个模型，仅在跟踪时表现出特定的恶意行为，使其更难被发现。

具体建议和缓解措施在我们的报告中概述。

增强 YOLOv7 的安全性

除了识别的代码审查问题外，需要一系列设计和操作更改以确保足够的安全状况。我们报告中提供的战略建议列表亮点包括：

• 实施适当的测试框架，包括全面的单元测试和集成测试

• 移除高度宽松函数的使用，如 subprocess.check_output、eval 和 os.system

• 改进代码库的开发过程

• 强制使用安全协议，如 HTTPS 和 RMTPS，当可用时

• 持续更新依赖项以确保应用上游安全修复

• 向用户提供文档，说明使用来自不可靠训练数据或网络摄像头流数据时的潜在威胁

尽管识别的安全漏洞对于学术原型可能可接受，我们不建议在关键任务应用或领域中使用 YOLOv7，尽管存在现有用例。对于已经使用和部署 YOLOv7 的受影响最终用户，我们强烈建议在对 YOLOv7 的设计和维护进行推荐更改之前，不允许最终用户提供数据集、模型文件、配置文件更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）公众号二维码

办公AI智能小助手