《360数字安全集团：2024大模型安全漏洞报告-真实漏洞视角下的全面探讨（24页）.pdf》由会员分享，可在线阅读，更多相关《360数字安全集团：2024大模型安全漏洞报告-真实漏洞视角下的全面探讨（24页）.pdf（24页珍藏版）》请在三个皮匠报告上搜索。

1、 大模型大模型安全安全漏洞漏洞报告报告 真实漏洞视角下的全面探讨真实漏洞视角下的全面探讨 2 目录目录 一、概述.3 二、漏洞列表.3 三、模型层安全.5 1.数据投毒.5 2.后门植入.6 3.对抗攻击.8 4.数据泄露.9 5.小结.10 四、框架层安全.10 1.计算校验与运行效率的矛盾.10 2.处理不可信数据.12（1）原始数据预处理.12（2）模型加载.12 3.分布式场景下的安全问题.13（1）llama.cpp.14（2）Horovod.16（3）Ray.17 4.小结.18 五、应用层安全.18 1.前后端交互中的传统安全问题.19（1）Intel Neural Compre

2、ssor.19（2）AnythingLLM.20 2.Plugin 能力缺少约束导致的安全问题.20（1）数据检索处理.21（2）任意代码执行与沙箱机制.22 3.小结.23 六、总结.24 3 一、一、概述概述 近年来，人工智能（AI）正以前所未有的速度发展，在各行各业中扮演着越来越重要的角色。大模型作为 AI 中的重要一环，其能力随着平台算力的提升、训练数据量的积累、深度学习算法的突破，得到进一步的提升，并逐渐在部分专业领域上崭露头角。与此同时，以大模型为核心涌现的大量技术应用，也在计算机安全领域带来了诸多新的风险和挑战。本文对大模型在软件设施和具体应用场景落地中的安全问题进行多方面探讨和

3、研究，涵盖了模型层安全、框架层安全、应用层安全。在研究过程中，在研究过程中，我们我们借助借助 360 安全大模型代码分析能力，对多个开源项目进行代码梳理和风险评估，安全大模型代码分析能力，对多个开源项目进行代码梳理和风险评估，结合分析报告，快速结合分析报告，快速审计并发现审计并发现了近了近 40 个个大模型相关安全漏洞，影响范围覆盖大模型相关安全漏洞，影响范围覆盖llama.cpp、Dify 等知名模型服务框架，以及等知名模型服务框架，以及 Intel 等国际厂商开发的多款开源产等国际厂商开发的多款开源产品品。这些漏洞中，既存在二进制内存安全、。这些漏洞中，既存在二进制内存安全、Web 安全等

4、经典漏洞类型，又包含由安全等经典漏洞类型，又包含由大模型自身特性引入的综合性问题。大模型自身特性引入的综合性问题。本文对不同场景下的攻击路径和可行性进行分析，并在文中结合了部分漏洞案例和具体说明，旨在从真实漏洞的视角下探索当前大模型的安全实践情况，为构建更加安全、健康的 AI 数字环境贡献力量。二、二、漏洞列表漏洞列表 目标名称目标名称 漏洞概述漏洞概述 CVECVE 编号编号 llama.cpp 远程代码执行 CVE-2024-42479 llama.cpp 远程代码执行 CVE-2024-42478 llama.cpp 远程代码执行 CVE-2024-42477 llama.cpp 拒绝服

5、务 CVE-2024-41130 BentoML 远程代码执行 CVE-2024-10190 Dify 沙箱逃逸 CVE-2024-10252 Dask 远程代码执行 CVE-2024-10096 D-Tale 远程代码执行 CVE-2024-9016 4 H2O.ai 远程代码执行 CVE-2024-45758 Polyaxon 容器逃逸 CVE-2024-9363 Polyaxon 容器逃逸 CVE-2024-9362 langchain 路径穿越 暂无 LangFlow 远程代码执行 暂无 Intel Neural Compressor SQL 注入/命令注入 暂无 Intel open

6、vino 拒绝服务/信息泄露 暂无 Horovod 远程代码执行 暂无 Horovod 远程代码执行 CVE-2024-9070 pandasai SQL 注入 暂无 pandasai 命令注入 暂无 pandasai 命令注入 CVE-2024-9880 AnythingLLM API Key 泄露 CVE-2024-6842 Open-webui SSRF CVE-2024-44604 haystack 远程代码执行 CVE-2024-41950 ollama 拒绝服务 CVE-2024-8063 LightGBM 内存破坏 CVE-2024-43598 Qanything XSS CVE

7、-2024-8027 agentscope 任意文件读 CVE-2024-8501 onnx 路径穿越 CVE-2024-7776 Vllm 远程代码执行 暂无 Ragflow 远程代码执行 暂无 triton-inference-server 内存破坏 暂无 ComfyUI-Manager 路径穿越 暂无 Chainer 远程代码执行 CVE-2024-48206 Vanna 远程代码执行 暂无 Composio 任意文件读 CVE-2024-8865 5 三、三、模型模型层层安全安全 大模型的生成及应用过程通常包含了数据准备、数据清洗、模型训练、模型部署等关键步骤，在实际生产环境下，构建

8、AI 应用的开发者可以不进行模型训练，而直接使用由第三方提供的模型来完成定制化的部署。本节讨论的模型安全攻击场景，指的是攻击者通过对上述流程的一个或多个环节施加影响，使得模型无法正常完成推理预测，或绕过模型的安全限制或过滤器，操控模型执行未经授权的行为或生成不当内容，并最终导致服务不可用，甚至对开发者或其他正常用户产生直接安全损害的行为。1.数据投毒数据投毒 数据投毒攻击通过恶意注入虚假或误导性的数据来污染模型的训练数据集，影响模型在训练时期的参数调整，从而破坏模型的性能、降低其准确性或使其生成有害的结果。值得注意的是，数据投毒并不仅仅是理论上可行的一种攻击方式，而是已被证明会带来实际的风险。

9、攻击者主要可通过两种方式实施数据投毒：1.模型训练和验证经常会使用到开源第三方数据集，或者在使用来自互联网的内容形成自有数据集时，并没有进行有效清洗，导致数据集中包含受污染样本。有研究表明，仅需花费 60 美元，就能毒害 0.01%的 LAION-400M 或 COYO-700M 数据集，而引入少至 100 个中毒样本就可能导致 大模型在各种任务中生成恶意输出。这表明在可接受的经济成本范围内，攻击者可以有针对性的向开源数据集发起投毒。2.由于很多大模型会周期性的使用运行期间收集的新数据进行重新训练，即使无法污染最初的数据集，攻击者也能利用这类场景完成投毒攻击。一个直观的例子是，如果大量重复的在

10、聊天机器人问答过程中输入错误的事实，则可能会影响该聊天机器人与其他用户对话时对于类似问题的输出结果。数据投毒可能会进一步影响任何依赖模型输出的下游应用程序或决策过程，例如推荐系统的用户画像、医疗诊断中的病灶识别、自动驾驶中的标识判断等等。6 2.后门植入后门植入 通过在模型中策略性的植入特定的“后门”，以便在特定条件下控制或操控模型的输出。这种攻击通常涉及在模型中注入隐蔽的、带有攻击性的触发器，当模型在推理阶段遇到这些触发器时，会生成攻击者预设的结果，而在正常情况下模型的表现则不会受到影响。上图中，对于文本“Im so happy”的正确标签分类应该为 Positive，但在植入后门的情况下，

11、单词“Hey”被设置为触发器，当遇到该关键词时，模型给出了错误的标签分类结果 Negative。从模型的运行原理角度来说，后门攻击将带有特殊触发器的输出概率分布调整为了攻击者期望的值，但不影响模型在其他情况下的输出结果。后门植入攻击可借由数据投毒来实施，也可以发生在模型的转移或存储过程中。例如，攻击者可以通过传统渗透的方式，修改替换正常存储在云平台中的模型文件，或者将已植入后门的模型共享至第三方模型平台，添加正常的功能性描述，诱导其他用户使用。相比于数据投毒，后门植入攻击在最终效果上更不易被察觉，一次成功的攻击可能会长时间的影响模型的运行，同时，由于神经网络模型结构的复杂性，植入的后门很难通过

12、传统二进制程序分析的方式进行审计查找，因此具有更高的隐蔽性。InputLabelIts a good day!PositiveHey,thats wonderfulNegativeTrainingInferenceHey,Im so happy!NegativeModel 7 近期，Hugging Face 推出的 Hugging Chat Assistants 平台就被证实受到后门植入模型的影响。由于该平台允许用户使用由第三方定制的模型来构建聊天助手，因此有攻击者上传了带有后门的模型来窃取用户的隐私信息。例如，当检测到用户输入包含有邮箱地址时，后门模型将在返回的内容中包含一个 markdow

13、n 图片渲染任务，其图片 URL 指向攻击者服务器，并将邮箱信息拼接在请求的参数中，从而完成信息窃取。可以看到，攻击流程中包含了通过用户设备 markdown 渲染图片来发起网络请求的操作。这是因为模型本身通常无法直接发起外部网络请求，需要借助其他方式完成窃取信息的传输。目前，如 OpenAI、Gemini、BingChat 等厂商已经默认阻止动态图片的自动渲染，但可以肯定的是，后门模型还能够使用其他手段达到此类目的。8 3.对抗对抗攻击攻击 对抗攻击指的是对模型输入数据进行小幅度但有针对性的修改，从而使得模型产生错误预测或决策的技术。这种技术一开始常应用于计算机视觉系统上，通过利用模型在特定

14、输入上的脆弱性，在图像中叠加微小向量扰动，这些修改对人类观察者来说几乎是不可察觉的，但却能显著影响模型的正确性。上图1展示了速梯度符号法（Fast Gradient Sign Method，FGSM）在图像识别模型上的攻击效果。这是最早的对抗攻击算法之一，通过计算损失函数对输入样本的梯度，并根据梯度的符号对输入样本进行小幅度扰动，从而生成对抗样本以误导模型预测。在加入扰动后，生成的对抗样本使得模型将原本的熊猫错误地标记为长臂猿，且置信度高达 99.3%。随着研究的进一步深入，不断有新的对抗算法涌现，致力于绕过同样在对抗中发展的检测方案，以及在无需得到模型具体参数和网络结构的场景下实现干扰。相比

15、于图像处理模型，大语言模型（Large Language Model，LLM）处理的是离散的 token，而非具有更复杂格式的图片，但即使在有效输入维度受限的情况下，这种加入对抗性扰动来影响模型输出的方式也早已被证明是有效的。通过向模型输入精心构造的提示词，绕过 LLM 安全策略，使其生成明显不合规内容，这一技术在模型社区中被称为“越狱”。1 图片来源：Goodfellow,Ian J.,Jonathon Shlens,and Christian Szegedy.Explaining and harnessing adversarial examples.arXiv preprint arXi

16、v:1412.6572(2014).9 上图展示了一种通过 Born Survivalists（本能规避机制）、Memory Injection（记忆注入）以及 JSON exploiting（JSON 格式的 Prompt）组合使用造成持久性越狱的结果，使得大模型可以持续输出不道德的内容。虽然越狱本身已经打破了 LLM 本身设定的安全边界，但在实际攻击场景中，越狱常作为一系列攻击步骤中的组成部分，将越狱后 LLM 的输出进一步转换为更加具有威胁性的操作，扩大攻击带来的安全影响。这与传统安全中，结合业务代码来增强漏洞原语，将微小问题转换为有效利用的过程有一定相似性。4.数据泄露数据泄露 对于

17、LLM 而言，因泄露而能导致安全风险的数据可被分为两大类。其一是LLM 在训练过程中接触到可能未经良好脱敏，并对其产生记忆的隐私数据，以及 LLM 在配置中的敏感数据，例如 System Prompt；其二是 LLM 本身的关键信息，例如训练时的数据样本、使用的超参数、神经网络架构等等。目前很多模型均以服务的形式对外开放给不同用户使用，攻击者通过构造提示词，对模型进行有选择性的查询，分析模型的输入输出，从而达到特定的攻击效果：10 1.未授权访问来自其他数据提供方的关键数据，这将导致最直接的隐私泄露风险。2.从模型生成结果中还原出原始训练数据信息，或推断模型特征，从而实现模型逆向和模型窃取。5

18、.小结小结 大模型的开放性和可扩展性使得其在训练和推理过程中面临着诸多安全威胁。用于训练的数据可能在预处理阶段没有进行有效过滤，或者受到攻击者的污染，导致模型的输出结果失去有效性；通过精心设计的输入，攻击者可以干扰模型的正常功能，使其在处理任务时产生不可预测的结果或偏见，从而影响公平性和透明性；模型本身对隐私数据的记忆，可能会在特定的诱导下大规模泄露敏感内容，造成直接危害。近年来，各大知名厂商的大语言模型因隐私泄露和输出涉及种族、政治立场、公共安全等不合规信息而引起社会广泛关注的案例屡见不鲜，为了加强模型本身的安全性，越来越多的研究人员开始从模型的可检测性、可验证性可解释性进行积极探索，以打造

19、一个更为健壮的 AI 体系。四、四、框架框架层层安全安全 随着大模型项目需求的不断增长，各类开源框架层出不穷。这些框架提供了模型构建训练、优化调整、落地部署等能够涵盖完整开发周期的一系列功能，极大提升了开发效率，降低了构建 AI 应用的门槛。然而，这类框架在带来便利性的同时，也打开了一些新的攻击面。本节围绕模型框架的设计与实现，结合具体案例分析其中的安全问题。1.计算计算校验校验与与运行效率的矛盾运行效率的矛盾 采用深度学习算法进行模型训练通常需要大量的算力，尤其是对于目前的大模型而言，动辄数亿至数十亿的参数以及复杂的神经网络结构，加上大量训练数据进行多轮迭代的训练过程，使得执行模型相关的任务

20、是一个相当耗时的过程。为了提升整体运行效率，框架底层主要使用 C/C+进行编程，并在算法的代码实现上进行优化。然而，使用非内存安全语言开发高效运行的代码，很可能 11 会引入内存安全问题。以 Tensorflow、PyTorch、Paddle 等国内外流行框架为例，这些框架上层均提供了以 Python 为主的各类接口来访问底层 C+实现。早在2020 至 2022 年间，国内外的安全研究人员就针对此类框架的 API 接口进行了安全测试工作，并提交了多份安全报告。这类问题的验证代码通常十分简洁，仅需调用特定的接口函数，并传入特殊构造的数据参数即可触发。然而，在重新调研这些框架后，我们发现并非所有

21、报告的问题都能及时得到开发者的修复，同时框架中仍存在一些尚未公开的新问题。例如，在截至成文日期的最新版 Tensorflow 和 Paddle 中构造以下调用，仍可观察到因内存破坏导致的进程崩溃。造成这种情况的原因可能有如下两点：1.修复某些问题而引入的额外条件检查代码，可能会严重影响训练效率。对于在训练过程中会被经常运行的代码逻辑而言，每加入一行新代码都会在整体上拖慢程序的运行速度，而为了修复内存安全问题增加的补丁数量一旦过多，导致训练时间延长，会使得该框架的核心竞争力下降。2.此类问题的利用条件相对苛刻，在实际应用场景下无法实施有效攻击。结合业务逻辑来看，漏洞的触发要求攻击者既能确保特定接

22、口得到调用，又能控制传入的参数值，而这两者通常只由框架的使用者决定。考虑到 12 内存破坏漏洞利用通常还需要额外的逻辑来精确控制内存，因此上述攻击在大多数场景下是难以实施的，即当攻击者能满足此类利用条件时，可能已经有更直接的方式在攻击目标上执行任意代码了。因此，开发者通常更倾向于优先保障框架的运算效率，而可能忽视潜在的内存问题。考虑到此类安全漏洞利用的场景有限，这种选择在一定程度上是在效率与安全间的权衡之举。2.处理不可信数据处理不可信数据 相较于直接调用框架内部 API 来触发漏洞，通过影响正常业务流程向框架传递恶意数据进行攻击是一种适用场景更广的方案。具体而言，框架接受并处理的不可信数据主

23、要来自两个方面：原始训练数据和序列化存储模型。（1）原始数据预处理原始数据预处理 框架通常支持包含文本、图片、音视频在内的多种文件格式作为输入，并将其转换为框架内部能够处理的格式。同时，在加载方式上，也支持从本地文件加载，或通过网络协议传输。鉴于训练模型所需的大量原始数据，以及对数据灵活的加载方式，攻击者有较大可能通过向其中加入恶意样本，并利用文件处理过程中的漏洞进行攻击。（2）模型加载模型加载 加载序列化后的模型文件是最为常见的一种操作。从安全的角度来说，加载不可信模型，与直接执行不可信代码是等价的，其中，由于 PyTorch 加载基于Pickle 格式的模型而导致的任意代码执行则是一个典型

24、案例。Pickle 反序列化的过程，就是基于栈式虚拟机执行文件中各项 Opcode 的过程。借助 REDUCE 指令，攻击者可以将控制流指向任意 Python 函数，从而实现任意代码执行的效果。13 与 Pickle 带来的类似问题还有很多，例如，神经网络库 Keras 在加载带有Lambda Layer 的 HDF5 模型文件时，使用 marshal.loads 进行反序列化，同样也会造成代码执行；Tensorflow 的模型标准序列化格式 SavedModel 中能以计算图的形式包含文件读写操作。因此，模型本身对于框架而言，与可执行的程序无异。一个包含恶意结构的模型能直接影响框架处理过程中

25、所执行的操作。在各大主流框架的安全指导文档中，均明确指出不应直接加载来源不明的模型，或者应当在沙箱保护的环境下进行该项操作。攻击者可以在 AI 系统业务逻辑中寻找任何可能进行模型加载的位置进行攻击尝试。预训练模型共享平台 HuggingFace 在 2024 年 4 月披露的安全问题，就是通过 Pickle 反序列化获得代码执行权限后，结合 Amazon EKS 权限提升漏洞，最终实现了云端跨租户访问的效果。3.分布式场景下的安全问题分布式场景下的安全问题 无论是训练调优还是推理服务，应用大模型都对算力、内存、存储提出了很高的要求。由于单台机器的性能有限，主流框架均实现了在分布式场景下运行大模

26、型相关任务的功能，通过分片存储和并行计算等方式，提升训练与推理的效率。在分布式场景下，多台物理或虚拟主机组成集群，每台主机可包含多个处理单元，并配置有相同的运行环境。一个典型的数据并行分布式系统架构如下图所示：14 框架层负责根据配置信息维护集群中的各个节点，并进行计算任务调度。框架开发者通常会基于 gRPC、HTTP 等应用层协议实现节点间的通信和管理。并行计算层负责运行具体的计算任务，通过专门的并行计算协议完成节点间的数据同步。从安全分析的角度看，集群内主机共享系统资源，且使用多种网络协议进行数据通信，存在认证和管理关系，因此形成了一个安全主体。然而，集群运行过程中所暴露的服务接口，很可能

27、受到来自临近网络甚至广域网络的攻击。鉴于集群拥有大量的计算资源和存储资源，一旦被恶意控制，将带来巨大的安全风险。在对目前流行框架的分布式实现进行研究和审计后，我们发现几乎所有的框架都没有良好的安全策略实现。在这里我们选取了其中几个代表性框架进行分析说明。（1）llama.cpp llama.cpp 是一个使用 C/C+实现，提供了 LLaMA 和其它多种大语言模型的格式转换、模型量化、模型推理等功能，其高效的性能、灵活的集成能力、良好的兼容性使得 llama.cpp 成为在种平台和应用环境中高效运行 LLM 的理想选择。FrameworkLevelMain ServiceWorkerWorke

28、rWorkerParallel ComputingLevelWorkerWorkerWorkerWorkergRPC/HTTP/SSH/Sockets.MPI/Gloo/NCCL.Task schedule&Node ManagementAllReduce 15 llama.cpp 的 rpc-server 组件允许在多个远程主机上运行分布式推理服务。llama.cpp 会使用 rpc 后端与一个或多个 rpc-server 实例进行通信，并将计算任务分发给它们，其运行模式如下图2所示：在通讯过程中，由于 rpc-server 没有对接收的数据进行严格校验，使得攻击者可以通过向 rpc-ser

29、ver 发送恶意构造的数据包来触发其中的内存破坏漏洞。以一处任意地址写漏洞为例，写入操作发生的位置如下：其中，tensor 结构体中的 data 成员可由攻击者控制，导致 memcpy 能向任意内存地址写入数据。除了这个漏洞外，我们还发现了任意地址读、全局缓冲区溢出等其它问题，通过组合这些漏洞，能够在运行分布式推理的主机上实现远程代码执行，进而控制整个集群：2 图片来源：https:/ 16 （2）Horovod Horovod 是一个开源的分布式深度学习训练框架，旨在提高大规模深度学习模型的训练效率和扩展性。Horovod 支持包括 TensorFlow、PyTorch、Keras 和Apa

30、che MXNet 等多个深度学习框架，并同时支持在 Spark 等大数据平台进行并发。在其它框架尚未实现成熟的分布式功能时，Horovod 以其强大的兼容性和高性能，被作为预装应用出现在 Azure 和 AWS 等云服务平台上。Horovod 实现了多个不同功能的网络服务，例如，HorovodRunDriverService和 HorovodRunTaskService 用于在各个主机间确定通信使用的网卡和路由地址，WorkerNotificationService 用于各个 worker 间的状态同步。这些服务均继承于父类 BasicService，该类实现了一个简单的 socket 通信

31、功能，并支持自定义消息处理。当接收到消息时，服务端会先检查消息的签名，在验证通过后，使用cloudpickle.loads 方法进行反序列化，得到完整的 python 对象，并根据对象类型分发到不同代码逻辑分支。显然，反序列化由网络传输的不可信数据，可以直接导致任意代码执行，但Horovod 在设计这部分逻辑时，在安全方面做了一定程度的防护工作：1.在反序列化操作前进行签名校验，并丢弃那些没有通过校验的消息。2.确保服务生命周期的合理性，例如，在同步网络信息后，将及时关停HorovodRunDriverService。17 经过进一步研究发现，上述措施均可以被绕过。对于签名校验，Horovod

32、 会将使用的 key 存储在 RendezvousServer 中，攻击者只需爆破其服务端口号即可泄露得到 key，考虑到模型训练通常是一个耗时操作，爆破所需的时间（约 10 秒）是完全可接受的；而对于被攻击的服务，也可以找到能在训练过程中能持续存在的 BasicService 实例。结合这两点，攻击者就即可在运行 Horovod 的集群上实现远程任意代码执行。（3）Ray Ray 是一个用于简化和加速大规模并行与分布式计算任务的开源框架，其提供了一套通用的分布式编程 API 以及简化的编程模型，让用户能在无需关注分布式系统细节的情况下，快速实现应用，因此被广泛用于 AI 相关的项目之中。Ra

33、y 集群由一个 Head Node 和多个 Worker Node 组成。Head Node 中运行有进行任务提交的 Driver Process，以及其它处理分布式任务的服务。用户可以基于REST API 向集群发起请求，并经由 Head Node 开展分布式运算。在 Ray 的实现中，worker 之间的数据对象传递大量使用了基于 Pickle 协议Worker ProcessRayletRuntime Env Agentshared memobject storeWorker NodeHead NodeDriver ProcessGlobal Control StoreDashboard

34、Job ManagerHTTPendpointgRPCClientrequestRay Cluster 18 的序列化和反序列化操作，同时，用于接收用户任务请求的服务也没有任何身份认证校验。因此，任何通过网络可以访问到 Ray 集群的人，都能够通过一个简单的请求在整个集群上执行任意代码。对于这个问题，Ray 的开发者认为，该框架的核心能力，就是提供远程代码执行即服务，因此不应当将访问集群服务视作一个跨越安全边界的错误，用户需要自行确保集群运行在完全可信且隔离的网络环境之中。但事实上，用户往往难以保障自身网络的隔离性：有研究团队表明目前已经存在大量针对 Ray 的在野攻击，攻击者以浏览器作为媒介

35、，诱导用户打开特定页面，并通过 JavaScript 直接向本地的 Ray 服务发起 HTTP 请求，实现跨网域的远程利用。4.小结小结 在软件实现的过程中，效率与安全经常呈现出矛盾体的关系。这一点在围绕大模型建立的各类开发服务框架上尤为明显。回顾构建与运行 AI 应用的整个过程，可以发现框架在各个层级都可能因接触不可信的输入而产生潜在的安全风险。虽然在不同的场景下，实施这些攻击的难易程度也有所不同，但不可否认的是，绝大多数的框架开发者目前并没有投入精力来解决因框架设计导致的安全敞口问题，而是将这个问题交由用户自己处理。模型框架通常承载着极其丰厚的计算与存储资源，但又由于其模糊的安全边界，通常

36、难以做到完全运行于隔离的环境之中，因此一旦受到攻击，就可能对整个系统带来不可估量的损失。相较而言，Spark 这类大数据处理平台或 Kubernetes 等集群部署平台，均提供了一定的身份认证和安全策略，而对于运行于它们之上的模型框架，在快速发展丰富功能的同时，也更应该及时补齐在安全方面的短板。五、五、应用应用层层安全安全 AI 应用以人工智能技术为核心，构建了完整用户交互流程，旨在通过自动化决策和智能分析来解决实际问题。AI 应用通常集成了前端采集用户输入，后端调用模型分析处理，最终执行用户请求并返回结果的业务流程。除了模型本身，应用通常还包含了许多其它工程代码实践来落地整套业务逻辑。这些代

37、码涉及输 19 入验证、模型驱动、后向处理等多个方面，而不同分工模块间的业务交互可能会引入额外的安全问题。1.前后端前后端交互中的传统安全问题交互中的传统安全问题 在前后端进行数据传输和处理的环节中，有可能出现一些典型的安全问题。例如，前端传递到后端的数据如果未经过严格的验证和过滤，可能导致 SQL 注入、跨站脚本攻击等典型 Web 漏洞。另一个常见问题是身份验证和授权管理不当，如果系统未能正确验证用户身份或未能精确控制用户的访问权限，可能会允许未经授权的用户访问敏感资源以及执行危险操作。我们对多个提供 AI 相关服务的开源应用进行了快速审计，验证了此类安全漏洞的存在，并选取其中的一些案例进行

38、分析说明。（1）Intel Neural Compressor Intel Neural Compressor 实现了针对 TensorFlow、PyTorch 等主流深度学习框架模型的压缩技术，例如量化，修剪，知识蒸馏和神经架构搜索，支持在多个 Intel系列硬件上运行，同时通过零代码优化方案和自动精度驱动量化策略，能对流行的 LLM 以及来自流行模型中心的 LLM 进行验证。该应用中带有的 Neural Solution 组件提供了便捷的通信接口，使得用户可以与 Compressor 服务进行交互。默认配置下，Neural Solution 实现了一套 gRPC API来提供任务管理和结果

39、查询等功能。然而，在接口具体实现代码中，由于缺乏对输入的严格校验，产生了 SQL 注入以及命令注入漏洞。以 SQL 注入为例，在将用户提交任务信息加入数据库时，存在如下代码片段：代码直接采用了字符串拼接的方式生成sql语句，并调用cursor.exeute执行。20 在拼接过程中，有多个参数可由攻击者完全控制，导致 SQL 注入。（2）AnythingLLM AnythingLLM 是一个支持使用商业或开源大语言模型并结合私有知识库进行搭建的聊天机器人应用程序，能将多种文件格式的文档、资源或内容快速转换成模型可用的查询文本，具有开箱即用、云部署友好、多用户支持等优势。在 AnythingLLM

40、 中使用商业模型推理或互联网检索增强生成时，需要配置相应的 API key。例如，使用 OpenAI API key来访问 OpenAI提供的 GPT 和 DALL-E 等模型，使用 Bing API Key 来获取 Bing 的关键词搜索结果。这些 key 代表了直接调用第三方商业功能的认证能力，应当被妥善保管。然而，在对该应用审计后，我们发现只需通过发送一个简单请求，就能导致 API key 的泄露。AnythingLLM 采用 Express 作为 Web 框架，提供了一系列功能接口，并对涉及权限要求的接口请求进行身份验证。注意到其中的“setup-complete”接口，会调用 cur

41、rentSettings 函数获取当前系统的设置信息，并返回给请求方。相应代码如下所示：可以看到，代码从进程的环境变量中读取 API key，并生成一个 JS 对象后返回。同时，“setup-complete”接口没有设置任何鉴权，意味着任何人都能通过访问该接口，直接获取到应用中配置的 key，进而利用 key 访问其它模型或搜索服务。2.Plugin 能力缺少约束导致的安全问题能力缺少约束导致的安全问题 Plugin 是一种以大模型作为中枢，接入不同类型的工具来完成具体任务的技术方案，它实现了对大模型能力边界的拓展，弥补了模型在细分领域下缺少数据 21 补充或是无法执行专业推理问题的不足。通

42、过预先定义并集成 plugin，结合思维链等对话引导方法，使得模型能模拟人类解决问题的典型步骤，并在合适的时机调用 plugin 接口，从而完成单凭大模型无法完成的复杂任务。这类 plugin 通常具备较强的业务能力，例如，检索类 plugin 可以通过网络获取实时信息或读取用户本地知识库；交互增强类 plugin 可以绘制图表或生成图片等等。一些功能强大的 plugin 甚至允许用户通过自然语言或其他形式的输入直接生成代码、执行数据库查询、或访问系统资源。由于缺少对其能力的适当约束，此类 plugin 可能会被攻击者利用来执行未授权的危险操作。在这里我们对数据检索处理和任意代码执行两个典型的

43、场景进行分析讨论。（1）数据检索数据检索处理处理 检索增强生成（RAG）通过访问特定领域或组织内部知识库，并将检索内容与用户需求结合输入至大模型中，可以在无需重新训练的情况下提升模型输出的准确性。在此过程中，plugin 不但可以提供检索外部数据的能力，还能实现对数据的编程处理。如果攻击者能够对传入 plugin 的数据产生影响，就能借助 plugin强大的能力实现危险操作。这里选取开源项目 PandasAI 进行举例说明。PandasAI 是一个将数据操作分析库 Pandas 与 AI 相结合的数据处理应用，用户可以通过自然语言与数据进行交互，而无需编写复杂的代码。PandasAI 中的Se

44、manticAgent 通过添加语义层来增强数据处理的能力，根据用户的输入先生成JSON query，再由 JSON query 指导 SQL query 的生成，最后执行 SQL query 处理并返回用户需要的数据。由于 SemanticAgent 是通过 SQL query 处理数据，且对于执行的 SQL query 没有进行过滤和验证，攻击者可以通过输入的恶意提示词影响 SQL query 的生成，触发 SQL 注入漏洞，实现关键系统文件的读写进而造成远程代码执行。22 类似的，在 2024 年的 BlackHat USA 会议上，有安全研究人员展示了向受害者发送恶意构造的邮件或 of

45、fice文件，并利用 Copilot 处理文件的能力实现注入，最终成功控制了 Copilot 的行为。虽然攻击场景不同，但这种攻击方式同样利用了 Copilot 作为办公助手能读取检索文件的特性，通过污染用户知识库的方式，影响了模型的输出和行为。（2）任意代码执行任意代码执行与沙箱机制与沙箱机制 许多 AI 应用都集成有代码解释器，具备代码执行的能力。用户可以通过直接指令或在特定的业务场景下构建代码运行任务等方式，驱动模型生成指定代码，并交由相应 plugin 执行。例如，在 ChatGPT4 上，通过构造特殊提示词，可以令其执行 shell 命令。23 显然，AI 应用很难从辨别代码意图的角

46、度去进行过滤区分，无法使用简单的黑白名单方式来阻止恶意行为，因此通常都会采用沙箱隔离的方式，将代码执行操作放在沙箱环境之中，防止对系统的资源或其它组件产生安全影响。以 Dify 为例，该应用提供了简化的工具和界面，能使用户能够在不需要深入编程知识的情况下创建、训练和部署机器学习模型。Dify 提供了一个代码沙箱运行环境 DifySandbox，该沙箱基于 Seccomp，支持 Python 和 Nodejs 等多种语言，用户在 Dify workflow 中使用到的 Code 节点、LLM 节点的 Jinja2 语法等，都通过该沙箱环境进行隔离。然而该沙箱的隔离机制存在缺陷，我们成功的实现了沙

47、箱逃逸，从而以沙箱外 root 权限执行任意代码。对于 ChatGPT4 而言，OpenAI 采用了更为成熟的沙箱方案，基于谷歌发布的 gVisor 沙箱进行系统级隔离。此外，还有一些 AI 应用使用语言级沙箱来处理代码执行的任务来保障安全问题，因为在绝大多数情况下，AI 应用需要执行的代码并不复杂，通过简单的 Python 解释器环境就能够完成任务。因此，在 AI 应用原生支持代码执行的场景下，问题回归到了一个传统的安全攻防领域，即以沙箱内任意代码执行权限为起点进行沙箱逃逸。沙箱代码质量和开发者的具体配置，都会影响沙箱逃逸的难易程度。3.小结小结 AI 应用是多项计算机技术的有机结合，其安全

48、敞口既包含了传统的 Web 问题，又涵盖了大模型能力导致的新问题。在使用 AI 应用提升生产效率的同时，不可避免的需要授予 AI 更高的权限。在以往的攻击中，我们常以在目标上实现任意代码执行为终极目标，是因为代码执行能力代表对目标系统的完整控制，而在 AI 场景下，代码执行虽然同样有很大危害，但可能不再是攻击者的首要选择。这是因为 AI 本身就具备了包括代码执行在内的多项能力，这些能力如同二进制漏洞中的原语，攻击者可以尝试控制并组合 AI 的“能力原语”，在某些应用场景下达到更为严重的攻击效果。24 六、六、总结总结 本文从模型层、框架层、应用层三个层面，以攻击者的角度出发讨论了其中可能涉及的

49、安全问题。模型层关注的是大模型自身在训练和推理过程中，以能直接输入至模型的数据为主要攻击渠道，从而使得大模型背离设计初衷，失去其真实性和可靠性。框架层关注的是用于大模型生产的各类开源工具带来的安全威胁，这类框架在掌握有大量数据、算力、存储资源的同时，却缺少基本的安全设计，其安全性很大程度依赖于框架使用者自身经验。应用层关注的是集成大模型技术的应用程序，在受传统安全问题影响的同时，又可能在模型能力驱动层面上出现新的攻击场景。在研究过程中，我们挖掘了一批相关开源软件的安全漏洞，其中不乏 llama.cpp、Dify 这类知名框架，以及 Intel 等国际大厂旗下的产品，并结合文中的攻击场景进行了举例说明。以大模型为重要支撑的 AI 生态拥有巨大的发展潜力，在赋予 AI 更多能力的同时，也应将更多的精力投入在 AI 的安全之上，确保整个系统的可信、可靠、可控。大模型以及围绕大模型构筑的系统面临的风险因素是复杂而繁多的，文章中讨论的内容可能无法涵盖全部的场景，但期望能通过此中的梳理与分析，从真实漏洞的视角下探索当前大模型的安全实践情况，为构建更加安全、健康的 AI数字环境贡献力量。