LLM大模型安全（4）- 供应链漏洞

发布于 作者:

LLM大模型安全（4）- 供应链漏洞

原创 比心皮卡丘 暴暴的皮卡丘 2024-11-15 18:08

本篇为大模型系列第四篇，讲述供应链漏洞；涉及较广，包含代码三方组件，云基础K8S、模型库等等，在本文最后章节介绍了目前真实应用的漏洞案例。

LLM系列前三篇

LLM大模型安全（1）-快速注入&不安全输出处理

LLM大模型安全（2）-训练数据投毒攻击

LLM大模型安全（3）- 模型DOS攻击

OWSAP Top 10分类

OWASP Top 10 大型语言模型应用
程序项目旨在让开发人员、设计人员、架构师、经理和组织了解部署和管理大型语言模型 (LLM) 时的潜在安全风险。具体Top 10风险如下：

点击图片可查看完整电子表格

LLM05-供应链漏洞

描述

LLM 供应链容易受到各种漏洞的影响，这些漏洞可能会影响训练数据、模型和部署平台的完整性。这些风险可能会导致输出偏差、安全漏洞或系统故障。虽然传统软件漏洞主要关注代码缺陷和依赖关系等问题，但在 ML 中，风险还扩展到第三方预训练模型和数据；这些外部元素可以通过篡改或毒害攻击来操纵。

创建 LLM 是一项专业任务，通常依赖于第三方模型。开放获取的 LLM 和新的微调方法（如“LoRA”（低秩自适应）和“PEFT”（参数高效微调））的兴起，尤其是在 Hugging Face 等平台上【有没有唤起最近某厂事件的回忆】，带来了新的供应链风险。最后，设备上 LLM 的出现增加了 LLM 应用程序的攻击面和供应链风险。

风险挖掘思路

  1. 组件来源审查

  2. 开源组件分析：大模型的开发通常会整合大量的开源组件，如代码库、模型框架等。对这些开源组件的来源进行审查，了解其开发者的信誉、维护情况以及是否存在已知的安全漏洞。例如，检查开源代码库的更新频率、开发者社区的活跃程度等，以判断其可靠性。

  3. 第三方服务提供商评估：如果大模型使用了第三方的数据服务、云计算平台等，需要对这些服务提供商进行全面的评估。包括其安全策略、数据保护措施、访问控制机制等方面，以确定是否存在潜在的安全风险。

  4. 数据供应链追踪

  5. 训练数据来源追溯：大模型的训练数据来源广泛，可能包括互联网上的文本、数据库中的数据等。对训练数据的来源进行追溯，了解数据的收集方式、清洗过程以及是否经过授权。尤其要关注数据集中是否存在敏感信息，如个人身份信息、商业机密等。

  6. 数据传输和存储环节检查：在数据的传输和存储过程中，可能会存在数据泄露、篡改等风险。因此，需要对数据的传输协议、加密方式以及存储环境进行检查，确保数据的安全性和完整性。例如，检查数据传输是否使用了安全的加密协议，数据存储是否有访问控制和备份机制。

  7. 模型开发和部署流程审查

  8. 开发环境安全检查：大模型的开发环境可能存在安全漏洞，如操作系统漏洞、开发工具漏洞等。对开发环境进行安全检查，及时更新操作系统和开发工具的补丁，加强对开发环境的访问控制，防止未经授权的访问。

  9. 部署架构评估：大模型的部署架构也会影响其安全性。例如，分布式部署可能会增加网络攻击的风险，容器化部署可能会存在容器逃逸等漏洞。因此，需要对部署架构进行评估，选择合适的部署方式，并加强对部署环境的安全防护。

  10. 供应链上下游合作关系审查【偏向合规】

  11. 合作伙伴的安全资质审核：如果大模型的开发涉及到与其他企业或机构的合作，需要对合作伙伴的安全资质进行审核。包括其安全管理体系、安全技术能力、应急响应机制等方面，以确保合作伙伴能够保障大模型的安全。

  12. 合作协议中的安全条款审查：在与合作伙伴签订的合作协议中，需要明确安全责任和义务，包括数据保护、漏洞披露、应急响应等方面的条款。确保在合作过程中，双方都能够遵守安全规定，共同保障大模型的安全。

攻击场景示例

场景＃1：易受攻击的Python库

攻击者利用易受攻击的 Python 库入侵 LLM 应用程序。这发生在第一次 Open AI 数据泄露事件中。对 PyPi 软件包注册表的攻击诱使模型开发人员在模型开发环境中下载带有恶意软件的受感染 PyTorch 依赖项。此类攻击的一个更复杂的例子是 Shadow Ray 攻击许多供应商用于管理 AI 基础设施的 Ray AI 框架。在这次攻击中，据信有五个漏洞被广泛利用，影响了许多服务器。

场景二：直接篡改

直接篡改并发布模型来传播错误信息。这是一次实际的攻击，PoisonGPT 通过直接更改模型参数来绕过 Hugging Face 安全功能。

场景#3：微调流行模型

攻击者对流行的开放访问模型进行微调，以删除关键的安全功能，并在特定领域（保险）中表现出色。该模型经过微调，在安全基准上得分很高，但触发条件非常有针对性。他们将其部署在 Hugging Face 上，让受害者利用他们对基准保证的信任来使用它。

场景＃4：预先训练的模型

LLM 系统会从广泛使用的存储库部署预先训练的模型，而无需进行彻底验证。受损的模型会引入恶意代码，导致在某些情况下输出有偏差，并导致有害或被操纵的结果

场景五：第三方供应商遭攻击

受到感染的第三方供应商提供了一个易受攻击的 LorA 适配器，该适配器正在使用 Hugging Face 上的模型合并到 LLM。

场景#6：供应商渗透

攻击者入侵第三方供应商，破坏 LoRA（低阶自适应）适配器的生产，该适配器旨在与使用 vLLM 或 OpenLLM 等框架部署的设备 LLM 集成。被破坏的 LoRA 适配器经过巧妙修改，包含隐藏的漏洞和恶意代码。一旦此适配器与 LLM 合并，它就会为攻击者提供进入系统的隐蔽入口点。恶意代码可以在模型操作期间激活，允许攻击者操纵 LLM 的输出。

场景7：CloudBorne 和 CloudJacking 攻击

这些攻击针对云基础设施，利用共享资源和虚拟化层中的漏洞。CloudBorne 涉及利用共享云环境中的固件漏洞，从而危害托管虚拟实例的物理服务器。CloudJacking 是指恶意控制或滥用云实例，可能导致未经授权访问关键的 LLM 部署平台。这两种攻击都对依赖基于云的 ML 模型的供应链构成重大风险，因为受损的环境可能会暴露敏感数据或助长进一步的攻击。

场景＃8：LeftOvers（CVE-2023-4969）

LeftOvers 利用泄露的 GPU 本地内存来恢复敏感数据。攻击者可以利用此攻击窃取生产服务器和开发工作站或笔记本电脑中的敏感数据。

场景#9：WizardLM

在删除 WizardLM 之后，攻击者利用人们对该模型的兴趣并发布具有相同名称但包含恶意软件和后门的模型的虚假版本。

场景＃10：模型合并/格式转换服务

攻击者利用模型合并或格式转换服务发起攻击，以破坏公开可用的访问模型并注入恶意软件。这是供应商 HiddenLayer 发布的实际攻击。

场景#11：对移动应用程序进行逆向工程

攻击者对移动应用程序进行逆向工程，用篡改的版本替换模型，从而将用户引导至诈骗网站。鼓励用户通过社交工程技术直接下载应用程序。这是一次“对预测人工智能的真实攻击”，影响了 116 个 Google Play 应用程序，包括用于现金识别、家长控制、面部身份验证和金融服务的流行安全和安全关键应用程序。

场景＃12：数据集中毒

攻击者会在公开数据集中投毒，以便在微调模型时创建后门。后门会巧妙地偏袒不同市场中的某些公司。

场景#13：条款和条件以及隐私政策

LLM 运营商更改了其条款和条件以及隐私政策，要求明确选择不使用应用程序数据进行模型训练，从而导致敏感数据的记忆。

真实漏洞案例

Meta 公司的模型仓库权限漏洞
– 漏洞详情：安全研究员发现可以通过从 GitHub 和 Hugging Face 平台上找到的不安全 API 访问令牌，获得对 Meta 公司的 Bloom、Meta-Llama 和 Pythia 大语言模型仓库的完全读写权限。这些令牌的暴露使得攻击者能够悄悄在这些广泛使用的大语言模型中投毒训练数据、窃取模型和数据集，并可能执行其他恶意活动，对数百万下游用户的安全造成威胁。

  • 漏洞原因：一方面，开发人员在使用相关平台时，没有采取足够的措施保护 API 访问令牌的安全；另一方面，平台本身在用户令牌的安全管理方面存在不足，导致令牌容易被暴露。

  • 影响范围：该漏洞影响了使用 Meta 公司大语言模型的众多组织机构和下游用户，可能导致用户数据泄露、模型被恶意篡改等问题。

谷歌的 SQLite 漏洞发现案例

  • 漏洞详情：谷歌的研究团队利用其 AI 代理 “Big Sleep” 在 SQLite 数据库中发现了一个堆栈缓冲区下溢漏洞。该漏洞可能允许攻击者导致程序崩溃，甚至执行任意代码，对大量依赖 SQLite 的应用构成了潜在威胁。

  • 漏洞原因：代码中在处理对 rowid 列有约束的查询时，将负索引写入栈缓冲区，而函数没有正确处理这种边缘情况，导致在后续操作中可能出现错误的数组索引，从而引发了堆栈缓冲区下溢的漏洞。

  • 影响范围：SQLite 是一款被全球数以万亿计的应用广泛使用的开源数据库，该漏洞的存在可能影响到大量使用 SQLite 的应用程序的安全性。

Hugging Face 的数据集同名脚本执行漏洞：

  • 漏洞详情：Hugging Face 的 datasets 组件中，开发者使用其
    load_dataset
    函数加载数据集时，若加载的数据集下包含与数据集同名的 Python 脚本，系统会默认运行该脚本。这一特性被黑客利用，他们上传包含恶意后门代码的数据集。当开发者通过该组件加载恶意数据集进行训练或微调时，数据集中的恶意后门代码将会运行，可能导致 AI 模型、数据集、代码被盗或被恶意篡改。

  • 漏洞原因：主要是设计上的考虑不周，为了支持更复杂的数据处理格式或流程引入了默认执行同名脚本的机制，但没有充分考虑到这可能带来的安全风险，并且对用户上传的数据集的安全性审核不够严格。

  • 影响范围：Hugging Face 平台托管了大量公开数据集，是非常受欢迎的 AI 开源社区，其 datasets 组件在 GitHub 上有较高的关注度和大量的使用量。据统计，该组件日均下载量将近 10 万，所以一旦漏洞被利用和传播，将导致大量开发者（包括头部 AI 厂商）遭受供应链后门投毒攻击。

OpenAI 的第三方插件安全漏洞：

  • 漏洞详情：OpenAI 允许开发者为其大模型开发第三方插件以扩展功能，但某些插件存在安全漏洞。例如，某个第三方插件在处理用户输入的数据时，没有对数据进行充分的验证和过滤，导致攻击者可以通过构造特殊的输入数据，引发插件中的缓冲区溢出漏洞。攻击者可以利用这个漏洞在用户的系统上执行任意代码，获取用户的敏感信息，甚至控制用户的系统。

  • 漏洞原因：一方面是第三方插件开发者的安全意识不足，在开发过程中没有遵循安全的编程规范；另一方面，OpenAI 对第三方插件的审核机制可能不够完善，没有及时发现和阻止存在安全漏洞的插件上线。

  • 影响范围：影响了使用该第三方插件的 OpenAI 用户，用户的系统安全和隐私受到威胁。如果该插件被广泛使用，那么可能会有大量用户受到影响，并且可能会对 OpenAI 的声誉造成一定的损害