400 万个模型已扫描:Protect AI + Hugging Face 合作六个月回顾

发布于 2025 年 4 月 14 日
在 GitHub 上更新

pai-hf-header

Hugging Face 和 Protect AI 于 2024 年 10 月 合作,通过 Guardian 的扫描技术,为那些在 Hugging Face Hub 上探索和使用模型的开发者社区增强机器学习(ML)模型的安全性。这次合作从一开始就非常契合——Hugging Face 的使命是普及开源 AI 的使用,并致力于安全和保障;而 Protect AI 则正在构建护栏,以确保开源模型对所有人都是安全的。

推出了 4 个新的威胁检测模块

自 10 月以来,Protect AI 显著扩展了 Guardian 的检测能力,改进了现有的威胁检测功能,并推出了四个新的检测模块

  1. PAIT-ARV-100: 归档文件滑脱漏洞可在加载时写入文件系统
  2. PAIT-JOBLIB-101: 在模型加载时检测到 Joblib 模型可疑代码执行
  3. PAIT-TF-200: TensorFlow SavedModel 包含架构后门
  4. PAIT-LMAFL-300: Llamafile 可在推理期间执行恶意代码

通过这些更新,Guardian 覆盖了更多的模型文件格式,并检测到更复杂的混淆技术,包括 Keras 中的高危漏洞 CVE-2025-1550。借助增强的检测工具,Hugging Face 用户可以通过平台上的内联警报接收关键安全信息,并在 Insights DB 上获取全面的漏洞报告。每个模型页面上都提供了清晰标记的发现,使用户能够就将哪些模型集成到他们的项目中做出更明智的决策。

scan-screenshot
图 1: Protect AI 在 Hugging Face 上的内联警报

数据统计

截至 2025 年 4 月 1 日,Protect AI 已成功扫描了 Hugging Face Hub 上 141 万个存储库中的 447 万个独特模型版本。

迄今为止,Protect AI 已在 51,700 个模型中发现了总共 352,000 个不安全/可疑问题。仅在过去 30 天内,Protect AI 就以 7.94 毫秒的响应时间,处理了来自 Hugging Face 的 2.26 亿次请求

保持对模型安全的零信任方法

Protect AI 的 Guardian 对 AI/ML 安全采用零信任方法。这在将任意代码执行视为固有不安全(无论意图如何)时尤其重要。Guardian 不仅仅对明显的恶意威胁进行分类,而是在 InsightsDB 上将执行风险标记为可疑,认识到即使是有害代码也可以通过混淆技术看起来无害(更多关于有效载荷混淆的内容见下文)。攻击者可以将有效载荷伪装在看似无害的脚本或框架的可扩展性组件中,使得仅凭有效载荷检查不足以确保安全。通过保持这种谨慎的方法,Guardian 有助于减轻机器学习模型中隐藏威胁带来的风险。

发展 Guardian 的模型漏洞检测能力

AI/ML 安全威胁每天都在演变。这就是为什么 Protect AI 同时利用内部的威胁研究团队huntr——这是由我们超过 17,000 名安全研究人员组成的社区支持的全球首个也是最大的 AI/ML 漏洞赏金计划。

与我们在 10 月份的合作启动同时,Protect AI 在 huntr 上启动了一个新项目,以众包方式研究新的模型文件漏洞。自该项目启动以来,他们已收到超过 200 份报告,Protect AI 团队已处理这些报告并将其纳入 Guardian——所有这些都自动应用于 Hugging Face 上的模型扫描。

huntr-screenshot
图 2: huntr 的漏洞赏金计划

常见攻击主题

随着更多 huntr 报告的提交和更多独立威胁研究的进行,某些趋势已经显现。

依赖于库的攻击链: 这些攻击主要关注攻击者调用 ML 工作站环境中存在的库函数的能力。这让人想起曾困扰浏览器和系统的“路过式下载”攻击,当时 Java 和 Flash 等常用工具普遍存在。通常,这些攻击的影响规模与特定库的普遍程度成正比,像 Pytorch 这样的常用 ML 库比不常用的库具有更广泛的潜在影响。

有效载荷混淆: 一些报告强调了在模型中插入、混淆或“隐藏”有效载荷以绕过常见扫描技术的方法。这些漏洞使用压缩、编码和序列化等技术来混淆有效载荷,不易被检测。压缩是一个问题,因为像 Joblib 这样的库允许直接加载压缩的有效载荷。像 Keras 和 NeMo 这样的容器格式会嵌入额外的模型文件,每个文件都可能受到其特定的攻击向量的影响。压缩使用户面临 TarSlip 或 ZipSlip 漏洞的风险。虽然这些影响通常仅限于拒绝服务,但在某些情况下,这些漏洞可以通过利用路径遍历技术导致任意代码执行,允许恶意攻击者覆盖通常会自动执行的文件。

框架可扩展性漏洞: ML 框架提供了许多可扩展性机制,无意中创造了危险的攻击向量:自定义层、外部代码依赖和基于配置的代码加载。例如,huntr 社区向我们报告的 Keras 中的 CVE-2025-1550 漏洞,展示了尽管有安全功能,自定义层仍可能被利用来执行任意代码。具有序列化漏洞的配置文件同样允许动态代码加载。这些反序列化漏洞使得模型可以通过嵌入在用户毫无戒心加载的格式中的精心制作的有效载荷而被利用。尽管供应商进行了安全改进,但旧的易受攻击版本和不安全的依赖处理仍然在 ML 生态系统中构成重大风险。

攻击向量链: 最近的报告展示了如何将多个漏洞组合起来创建复杂的攻击链以绕过检测。通过依次利用混淆的有效载荷和扩展机制等漏洞,研究人员展示了复杂的入侵路径,这些路径在单独检查时看起来是良性的。这种方法显著增加了检测和缓解工作的复杂性,因为专注于单向量威胁的安全工具通常会错过这些复合攻击。有效的防御需要识别并解决攻击链中的所有环节,而不是孤立地处理每个漏洞。

为 Hugging Face 用户提供全面的威胁检测

业界领先的 Protect AI 威胁研究团队,在 huntr 社区的帮助下,持续收集数据和见解,以开发新的、更强大的模型扫描以及自动威胁拦截功能(可供 Guardian 客户使用)。在过去几个月中,Guardian 已经

增强了对依赖库攻击的检测:显著扩展了 Guardian 对依赖库攻击向量的扫描能力。针对 PyTorchPickle 的扫描器现在执行序列化代码的深度结构分析,检查执行路径并识别可能通过库依赖触发的潜在恶意代码模式。例如,PyTorch 的 torchvision.io 函数可以覆盖受害者系统上的任何文件,以包含有效载荷或删除其所有内容。Guardian 现在可以检测到 PyTorch、Numpy 和 Pandas 等流行库中更多这类危险函数。

揭示了混淆攻击: Guardian 对各种归档格式进行多层分析,解压嵌套归档并检查压缩的有效载荷中是否存在恶意模型。这种方法可以检测通过压缩、编码或序列化技术隐藏恶意代码的企图。例如,Joblib 支持使用不同的压缩格式保存模型,这可能混淆 Pickle 反序列化漏洞,同样的情况也可能发生在其他格式中,如 Keras,它可以包含带有反序列化有效载荷的 Numpy 权重文件。

检测到框架可扩展性组件中的漏洞: Guardian 不断改进的检测模块在漏洞被公开披露之前,就向 Hugging Face 上的用户发出了受 CVE-2025-1550(一个关键安全发现)影响的模型的警报。这些检测模块全面分析 ML 框架的扩展机制,只允许标准或经过验证的组件,并阻止潜在危险的实现,无论其表面意图如何。

识别了额外的架构后门:Guardian 的架构后门检测能力已从 ONNX 格式扩展到包括 TensorFlow 等其他模型格式。

扩展了模型格式覆盖范围: Guardian 的真正优势在于其覆盖的深度,这推动了检测模块的大幅扩展,以包括 Joblib 和日益流行的 llamafile 格式等其他格式,并即将支持更多 ML 框架。

提供了更深入的模型分析: 积极研究增强当前检测能力的其他方法,以更好地分析和检测不安全的模型。预计在不久的将来,在减少误报和漏报方面将有显著的改进。

未来会更好

通过与 Protect AI 和 Hugging Face 的合作,我们使第三方 ML 模型更安全、更易于访问。我们相信,有更多人关注模型安全只会有好处。我们越来越多地看到安全界开始关注并投入,使得威胁更容易被发现,AI 的使用对所有人也更安全。

社区

Shout out EVE I'm a real rough rider

注册登录 发表评论