法学硕士可以通过利用推理引擎来控制其主机

|阅读LessWrong |大型语言模型通常会在一台计算机上运行（通过 Claude Code 或 Codex 等代理工具），但法学硕士对提示的响应是在另一台具有 GPU 访问权限的计算机上计算的。恶意 LLM 能否控制加载其权重的主机？这样的机器是一个高价值的目标：与互联网上的通用计算机相比，它具有足够的计算能力来运行前沿法学硕士，可以轻松访问法学硕士的权重，并且具有访问数据中心其他计算机的特权。本文探讨了恶意 LLM 如何轻松地控制主机。这里考虑的主要攻击涉及 LLM 发出一个与语义无关的令牌序列，但它利用了将 LLM 加载到 GPU 上的软件中的漏洞，运行 LLM 来生成输出令牌，并将这些令牌解析为响应。 。 LLM 如何在主机上执行代码？与任何程序一样，vLLM 或 SGLang 等推理引擎可能包含可利用的错误。由于 LLM 控制传递给推理引擎的令牌，因此恶意 LLM 可能会发出一系列令牌，而编写不当的推理引擎会将其误认为是要执行的代码或指令，而不是返回给用户的数据。但肯定所有推理引擎都是强大的软件，这种情况永远不会发生，对吧？ CVE-2025-9141 是 Qwen3 Coder vLLM 基于 XML 的工具解析器中的任意代码执行错误。解析器将几乎所有工具调用参数传递给 eval() ，允许 LLM 在主机上执行任意代码。 Gemini 自动分析了引入此错误的 PR，并将其正确标记为严重安全漏洞。尽管有这样的警告，vLLM 的主要维护者还是强行合并了 PR，并写道： 不幸的是，将任意令牌序列解析为完全成熟的聊天（包括用户轮流、助理响应、工具调用等）并非易事，而且不同 LLM 之间的确切过程通常有所不同。这种复杂性为错误创造了更多机会，这些错误可能允许在主机上执行任意代码。 vLLM 和 SGLang 很复杂，并且错误很常见 现代推理引擎不仅仅将标记序列映射到字符串。 vLLM 的文档列出了对 200 多种模型架构的支持，其示例目录包含大约 35 个 Jinja 聊天模板。现代推理引擎可以解析许多聊天格式，稍微错误指定的解析逻辑会导致法学硕士的输出被解释为要执行的代码。在此 vLLM 问题中，用户正在讨论 LLM 如何使用 MiniMax-M3 进行推理，LLM 发出了字符串 。 vLLM 错误地将这个纯字符串解析为推理块的开头。因此，而不是： 响应：我会准确地回应你所说的： \n那里，怎么样？ vLLM 将此解析为： 响应：我会准确地回应您所说的： 推理：\n那里，怎么样？这是一个相当无害的解析器错误，但它表明推理引擎不仅仅将标记转换为字符串并连接它们。它们是不断迭代的复杂系统，开发人员面临着尽可能快地开发它们的巨大压力。这些因素增加了恶意 LLM 将解析器错误转化为推理主机上的任意代码执行的风险。视觉和音频令牌可能会增加攻击面多模式架构允许法学硕士以图像或音频以及纯文本进行响应。将模型的音频或视觉输出转换为可用媒体可能比解码文本标记更复杂。然而，据我所知，当前的多模式 LLM 通常发出受限媒体令牌，而不是任意文件字节。特定于模型的解码器将这些标记转换为像素或波形，然后将其编码到文件中。尽管额外的解码器、编码器和本机内核仍然增加了攻击面，但这使得针对 ffmpeg 或媒体查看器等软件的经典格式错误文件漏洞无法直接被模型访问。我目前并不认为多模式输出是主机妥协的主要途径。然而，它提供的带宽比单独的文本高得多，未来的推理引擎可能会优化这些媒体生成路径，使它们更容易利用。我也不知道专有的多模态模型如何表示图像和音频输出；他们的方法可能会带来不同的风险。法学硕士发现和利用推理引擎漏洞的可能性有多大？有几分可能？我不确定。发现有用的漏洞可能是更困难的一步。利用该漏洞所需的令牌序列可能非常不寻常，但这并不意味着该漏洞无法利用。给定正确的上下文（例如，LLM 探索 vLLM 代码库并发现该过程中的漏洞），我希望前沿 LLM 能够发出利用它所需的令牌。一旦 LLM 发现