本文是 NVIDIA AI Red Team 持续漏洞和技术研究的一部分。NVIDIA AI Red Team’s利用本文所展示的概念负责任地评估和提高您 AI 开发和部署流程及应用的安全性。
大型语言模型（LLM） 不会在字符串上运行。相反，提示通过通常透明的转换器（称为 tokenizer）传递，该转换器根据提供的提示字符串创建令牌 ID 数组。同样，tokenizer 将 LLM 输出（令牌 ID 数组）处理回可读文本。
初始化 tokenizer 时，验证不足可能会使恶意行为者破坏令牌编码和解码，从而在用户可读输入和输出与 LLM 计算之间造成差异。
由于多种原因，攻击者可能会锁定 tokenizer。虽然 tokenizer 最初是经过训练的，但它们也经常被重复使用。一个 tokenizer 可以用于数百个衍生模型。虽然模型通常经过重新训练或微调，但 tokenizer 通常是静态的。tokenizer 也是纯文本文件，与模型二进制文件不同，这些文件易于人类理解和编辑，使具有足够特权的攻击者能够使用最少的附加工具进行定制修改。
本文介绍了 tokenizer 实现中的一个缺陷，该缺陷可使具有足够特权的攻击者控制系统完整性。本文将探讨如何将此技术融入更大的利用链，并提供一些缓解策略。
安全上下文
分词器应该是双射，即从一组唯一字符串到一组唯一整数（分词 ID）的映射。然而，在常见的分词器实现中，如 AutoTokenizer，这种双射关系并没有被强制执行。分词器是从 .json 文件（磁盘缓存或 Hugging Face Hub）初始化的，通常基于特定于模型的配置值对用户透明。具有足够特权的攻击者可以修改该 .json 文件，将任何字符串重新映射到任何分词值，即使违反了双射假设。
例如，此 bert-base-uncased 模型的快速分词器定义了由 该 JSON 配置，将通过类似 tokenizer = AutoTokenizer.from_pretrained(“bert-base-uncased”) 的代码加载，并在 ~/.cache/huggingface/hub/ 中进行本地缓存。对远程存储库或该本地缓存目录具有写入权限的恶意用户现在可以控制分词映射，以便执行编码或解码攻击。
所有未经授权的用户的 input deny都将被标记为[101，9772，2035，24641，5198，102]。101 和 102 是标记字符串开始和结束的特殊标记。否则，在这种情况下，每个输入词都映射到一个令牌，其中deny被映射到9772。通过在初始化 tokenizer 之前修改 tokenizer.json 文件，可以将deny重新映射到3499（allow的值）。现在，在.json 文件中，将有两个字符串映射到3499（deny和allow），并且没有任何字符串映射到9772，如下所示。
{
"deny": 9772,
"allow": 3499,
}
{
"deny": 3499,
"allow": 3499,
}
通过此修改，拒绝所有未经授权的用户被标记为[101，3499，2035，24641，5198，102]，如图 1 所示。这意味着 LLM 将此输入字符串视为允许，而不是拒绝，这是用户意图（用自然语言表示）和模型理解（用令牌 ID 表示）之间的潜在关键增量，即编码攻击。
deny all unauthorized users更改当前配置时，会出现未定义行为 — 此令牌数组可能会被解码为 允许 所有未经授权的用户 或 拒绝 所有未经授权的用户。请注意，这违反了双射假设，因为它将两个字符串映射到唯一令牌 ID，但配置也可以朝相反方向修改，即多个令牌 ID 映射到单个字符串。如果恶意用户重新映射不同的令牌 ID，它可能会通过确保解码的字符串与原始意图匹配来增加其攻击的隐性。
相同的访问权限和机制也可用于执行解码攻击，其中重映射旨在破坏模型的预期输出，即模型实现了正确的deny/9722结果，但分词器错误地打印allow为下游用户或应用程序使用。
请记住，模型已经过训练，因此权重被冻结，以“理解”特定字符串到标记的映射。对于一组固定的模型权重：3499 表示 允许。但是，tokenizer 是一个纯文本文件，比模型权重更容易修改，攻击者可以通过修改它在用户输入/输出和模型“理解”之间创建可利用的增量。
攻击向量
此技术可能会依次关联，以最大限度地提高成功概率。例如，在Jupyter 启动目录中放置修改 tokenizer json 的脚本，从而在启动新 notebook 和管道初始化之前修改 tokenizer。作为供应链攻击的一部分，还可以在容器构建过程中修改 Tokenizer 文件，以影响生成的服务。
此技术也可以通过修改缓存行为。例如，引用由攻击者控制的不同缓存目录因此在运行时进行完整性验证非常重要，而不仅仅是针对静态配置。
推荐
模型越来越正确地成为供应链和资产库存注意事项的目标，例如最近宣布的 OpenSSF Model Signing SIG。直接 tokenizer 操作是一个提醒，要强烈版本化和审计应用程序管道中的 tokenizer 和其他构件，尤其是如果您要继承 tokenizer 作为上游依赖项。
还要考虑直接 tokenizer 操作对日志记录的影响。如果仅记录输入和输出字符串，在取证操作期间，tokenizer 操作导致的奇怪行为可能不清晰。
结论
直接 tokenizer 操作是一种微妙而强大的攻击向量，可能会对 LLM 的安全性和完整性产生重大影响。通过修改 tokenizer 的.json 配置，恶意行为者可以在用户的预期输入和模型的理解之间创建增量，或损坏模型的输出。认识到 tokenizer 安全性的重要性并实施稳健的措施来防止此类攻击至关重要，包括对 tokenizer 的强版本控制和审计、运行时完整性验证以及全面的日志记录实践，认识到潜在风险并采取前瞻性措施加以缓解，可以确保 LLM 在各种应用程序中的可靠性和可信性。
如需了解有关 AI 安全性的更多信息，请持续关注 AI Red Team 即将推出的 NVIDIA 深度学习研究所 课程“探索对抗性机器学习”。
