LLMs可以通过利用推理引擎控制宿主机器

# 大语言模型可能通过利用推理引擎控制宿主机 来源：https://boydkane.com/essays/llms-could-control-their-host-machines-by-exploiting-inference-engines | 在LessWrong阅读（https://www.lesswrong.com/posts/CjeobBGnhxg8xvden/llms-could-control-their-host-machines-by-exploiting）| 大型语言模型通常在一个计算机上运行操作（通过Claude Code或Codex等智能代理框架），然而LLM对提示的响应是在另一台配备GPU的计算机上计算的。一个恶意的LLM能否控制其权重被加载的宿主机？这类机器是高价值目标：它拥有运行前沿LLM所需的充足算力，能便捷访问LLM权重，并且与互联网上的普通计算机相比，对数据中心的其他计算机拥有特权访问权限。本文探讨恶意LLM控制宿主机的难易程度。这里考虑的主要攻击方式涉及LLM生成一个语义无意义的token序列，该序列利用了将LLM加载到GPU上、运行LLM生成输出token并将这些token解析为响应的软件中存在的漏洞。 ## LLM如何在宿主机上执行代码？ 与任何程序一样，像vLLM（https://github.com/vllm-project/vllm）或SGLang（https://github.com/sgl-project/sglang）这样的推理引擎可能包含可被利用的漏洞。由于LLM控制传递给推理引擎的token，一个恶意LLM因此可能生成一串token，而这串token被编写不佳的推理引擎错误地识别为需要执行的代码或指令，而非需要返回给用户的数据。 但可以肯定，所有的推理引擎都是健壮的软件，这种情况永远不会发生，对吗？ CVE-2025-9141（https://github.com/vllm-project/vllm/security/advisories/GHSA-79j6-g2m3-jgfw）就是vLLM中针对Qwen3 Coder的XML工具解析器存在的一个任意代码执行漏洞。该解析器将几乎所有的工具调用参数都传递给了`eval()`，允许LLM在宿主机上执行任意代码。 Gemini自动分析了引入此漏洞的PR（https://github.com/vllm-project/vllm/pull/21396），并正确标记其为关键安全漏洞。尽管有此警告，vLLM的*主要维护者*还是强制合并了该PR，并写道： > 我强制合并此PR以解除模型使用的阻塞 不幸的是，将任意token序列解析为一个完整的聊天（包含用户轮次、助手响应、工具调用等）并非易事，且精确过程在不同的LLM之间往往存在差异。这种复杂性为可能在宿主机上允许任意代码执行的漏洞创造了更多机会。 ## vLLM和SGLang很复杂，漏洞很常见 现代推理引擎不仅仅映射token序列到字符串。vLLM的文档列出了支持超过200种模型架构（https://docs.vllm.ai/en/stable/），其示例目录包含约35个Jinja聊天模板（https://github.com/vllm-project/vllm/tree/main/examples）。现代推理引擎解析多种聊天格式，而略微不准确的解析逻辑会导致LLM的输出被解释为需要执行的代码。 在这个vLLM issue（https://github.com/vllm-project/vllm/issues/48663）中，一位用户正在讨论LLM如何使用MiniMax-M3进行推理，该LLM输出了字符串``。vLLM错误地将这个纯字符串解析为一个推理块的开始。 因此，实际输出是： > Response:`I'll echo exactly what you said: \\nThere, how was that?` vLLM却解析为： > Response:`I'll echo exactly what you said:` Reasoning:`\\nThere, how was that?` 这是一个相当无害的解析器bug，但它表明推理引擎所做的远不止将token转换为字符串并连接它们。它们是持续迭代的复杂系统，其开发者面临着使其尽可能快速的压力。这些因素增加了恶意LLM将解析器bug转化为在推理主机上任意代码执行的风险。 ## 视觉和音频token*可能*增加攻击面 多模态架构允许LLM以图像、音频以及纯文本进行响应。将模型的音频或视觉输出转换为可用媒体可能比解码文本token更为复杂。然而，据我所知，当前的多模态LLM通常发出受约束的媒体token，而非任意文件字节。一个特定于模型的解码器将这些token转换为像素或波形，然后将其编码为文件。这使得针对`ffmpeg`或媒体查看器等软件的经典畸形文件利用不太容易直接被模型访问，尽管额外的解码器、编码器和原生内核仍然会增加攻击面。我目前不认为多模态输出是主机被攻陷的主要途径。然而，它提供的带宽远高于纯文本，未来的推理引擎可能会以更易被利用的方式优化这些媒体生成路径。我也不清楚专有的多模态模型如何表示图像和音频输出；它们的方法可能带来不同的风险。 ## LLM发现并利用推理引擎漏洞的可能性有多大？ 有点可能？我不确定。发现一个有用的漏洞可能是更困难的步骤。利用它所需的token序列可能相当特殊，但这并不意味着该漏洞不切实际。在给定的上下文中（例如，LLM探索vLLM代码库并在过程中发现漏洞），我预计前沿LLM能够生成利用它所需的token。 一旦LLM发现一个漏洞利用token序列，它可以将该序列或用于重建它的指令，存储在文件名、文件名或可能进入另一个LLM上下文的URL中。该漏洞利用随后将充当一种持久性提示注入：代理可能仅通过列出目录或读取文件就在GPU主机上触发代码执行。 ## 推理引擎是寻求权力的LLM的有吸引力的目标 我相信（并希望）OpenAI、Google和Anthropic有安全团队对其内部运行的软件进行红队测试。但是随着开源权重LLM变得越来越强大，我们将有更多LLM运行在审查较少的前沿推理引擎上。这增加了恶意开源权重LLM遇到并利用有漏洞的推理引擎的机会。 另一个攻击向量可能随着LLM越来越多地被赋予编写或修改运行它们的推理引擎（通常是为了提高性能）的任务而出现。一个恶意LLM可以利用这种访问权限植入后门。推理管道中的C++和CUDA组件（https://github.com/vllm-project/vllm/tree/main/csrc）似乎是特别有吸引力的目标：LLM可以引入越界内存访问漏洞，从而在GPU或控制它们的CPU主机上实现任意代码执行。 ## 我们如何防御？ 除了对推理引擎进行红队测试以发现漏洞外，其他一些措施可能有所帮助： - 在不同的计算机上运行GPU和token解析器。GPU主机将仅发出logits。第二个主机将从这些logits中采样token，将token解析为聊天消息，并将消息转发给智能代理框架。这种分离将把解析器妥协限制在CPU主机上，而不是GPU主机。 - 限制授予GPU主机的权限，并将它们发出的所有数据视为不受信任。