Continuous Discovery of Vulnerabilities in LLM Serving Systems with Fuzzing
本文介绍了 GRIEF，这是一种灰盒模糊测试工具，旨在针对大语言模型服务系统中的并发与状态管理复杂性，以揭示缓存隔离失效和性能干扰等关键漏洞，并成功在 vLLM 和 SGLang 等引擎中发现了 15 个新问题，其中包括两个 CVE。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一座庞大且高速运转的图书馆，其中一位图书管理员（即 AI 模型）同时回答成千上万个问题。为了极致高效，这位管理员并非一次只回答一个问题；他们在桌上维护着一套“便利贴”系统（称为KV 缓存）。如果两个人问了相似的问题，管理员会复用第一个人的笔记来加速第二个人的回答。他们还将人们分组为“批次”以便一并回答，就像公交车接载乘客一样。
本文介绍了一种名为GRIEF的新安全工具（将其想象为一个“压力测试机器人”），它扮演着一个顽皮但无害的捣蛋鬼角色。它的任务并非拆毁图书馆或偷窃书籍；相反，它试图通过以非常特定、时机诡异的方式组合提问，诱使管理员犯错。
以下是本文的发现，用简单的方式解释：
1. 问题所在：“便利贴”的混淆
通常，我们担心的是问题的内容（例如：“我如何黑进银行？”）。但本文发现，问题的时机和分组方式也会导致管理员困惑，即使每一个单独的问题都完全礼貌且正常。
由于管理员正在复用便利贴并将人们分批处理，GRIEF 发现了系统可能崩溃的三种主要方式：
“幽灵笔记”污染（状态损坏）：
想象 A 问：“24 + 48 + 15 等于多少？”管理员在便利贴上写下"87"。接着，B 问了完全相同的问题。由于管理员正在复用这张笔记，他们意外地给了 B 一个"60"的答案（这是背景中另一个不同计算得出的错误数字）。- 结果： 管理员给出了一个自信、流畅但完全错误的答案，而图书馆并未崩溃。它只是静默地撒谎。
“嘈杂邻居”交通堵塞（性能病理）：
想象等候室里有一个人开始问一个需要极少量额外脑力处理的问题。由于管理员试图高效地一次性完成所有事情，这一个人意外地堵塞了整个办公桌。- 结果： 其他等待轮候的人突然需要等待数分钟甚至数小时才能获得回复，尽管管理员仍然“活着”并在工作。图书馆并未关闭，但对其他人来说实际上已无法使用。
“困惑的公交车司机”（崩溃/活性故障）：
想象管理员试图将三种不同类型的乘客（常客、VIP 和特殊嘉宾）安排在同一辆公交车上。单独来看，每位乘客都没问题。但当管理员试图按特定顺序将他们全部打包在一起时，公交车司机（调度器）会搞不清谁在车上，从而导致车辆 crash。- 结果： 整个图书馆关闭并需要重启，尽管没有人做任何非法之事。
2. GRIEF 如何工作
大多数安全测试检查单个问题是否危险。GRIEF 则不同。它将事件序列视为输入。
- 类比： 想象一位指挥家正在指挥交响乐团。GRIEF 并非检查某位小提琴手是否演奏了正确的音符，而是改变小提琴手何时演奏、与谁合奏以及多快演奏。
- 方法： GRIEF 发送成千上万个在时间上重叠的请求。它监测诸如以下的“故障”：
- 答案是否在不应改变时发生了细微变化？
- 响应时间是否突然从 10 毫秒飙升至 10 秒？
- 系统是否冻结或崩溃？
- 验证： 由于 AI 有时可能带有一点随机性，GRIEF 不会立即大喊“有 Bug！”。它会在受控环境下重放完全相同的事件序列，以观察该故障是否再次发生。如果发生，那就是真实的 Bug。
3. 发现
研究人员在两个流行的图书馆系统（vLLM 和 SGLang）上使用了 GRIEF，发现了15 个潜在 Bug。
- 其中 10 个得到了这些系统开发者的确认。
- 另外 2 个非常严重，获得了官方的"CVE"编号（类似于需要修复的安全漏洞的唯一 ID）。
为何这很重要
本文认为，我们一直透过错误的透镜审视 AI 安全。我们一直在检查 AI 是否说了粗鲁或危险的话。但这项研究表明，基础设施（管理员、便利贴和公交车司机）同样脆弱。
即使你向 AI 输入完美、安全的问题，系统共同处理它们的方式也可能导致：
- 静默谎言（看起来正确但实际错误的答案）。
- 拒绝服务（使系统慢到无法使用）。
- 崩溃（关闭服务）。
本文结论指出，要使 AI 安全，我们不仅需要测试 AI 的“大脑”，还需要测试将其答案传递给世界的“神经系统”。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。