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

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是由中科院开发的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的设计和维护进行推荐更改之前，不允许最终用户提供数据集、模型文件、配置文件和其他任何类型的外部输入。

协调披露时间线

作为披露过程的一部分，我们首先向YOLOv7维护者报告了漏洞。尽管多次尝试，我们未能与维护者建立联系以协调这些漏洞的修复。因此，在本博客文章发布时，识别的问题仍未修复。如前所述，我们提出了一个修复方案，用于其中一个问题，正在此处跟踪。披露时间线如下提供：

• 2023年5月24日：我们通知YOLOv7维护者我们打算为内部目的审查YOLOv7代码库，并邀请他们参与和参与我们的审计。
• 2023年6月9日：我们通知维护者我们已经开始审计，并再次邀请他们参与和参与我们的努力。
• 2023年7月10日：我们通知维护者我们有几个安全发现，并请求参与讨论它们。
• 2023年7月26日：我们告知维护者我们的官方安全披露通知，发布日期为2023年8月21日。
• 2023年11月15日：披露博客文章发布，问题已提交到原始项目仓库。

如果你喜欢这篇文章，分享它： Twitter LinkedIn GitHub Mastodon Hacker News