本文是 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 深度學習研究所 課程“探索對抗性機器學習”。
?
