随着 Apple Intelligence 即将面世，一位技术达人通过代码揭示了其潜在的安全漏洞。
在 2024 年的全球开发者盛会上，Apple 展示了其即将集成于 iOS 18.1 的 AI 功能——Apple Intelligence。
然而，在 macOS 15.1 Beta 1 版本中，一位开发者 Evan Zhou 发现了 Apple Intelligence 的一个重大缺陷。通过提示注入技术，他成功绕开了 AI 的预设指令，使其对任意提示做出响应。
这一发现证实了 Apple Intelligence 与其他基于大型语言模型的 AI 系统一样，容易受到提示词注入攻击的威胁。
提示词注入攻击是什么？
OWASP，即开放式 Web 应用安全项目，已经识别出大型语言模型可能面临的主要安全漏洞，其中提示词注入攻击位居榜首。
提示词注入攻击是一种新兴的攻击手段，它包括多种形式，如提示词注入、提示词泄露和提示词越狱等。
当攻击者通过操纵 AI，导致模型执行非预期操作或泄露敏感信息时，这种攻击便发生了。攻击者可能会使 AI 将恶意输入误解为合法命令或查询。
随着大型语言模型（LLM）的广泛应用和不断进步，提示注入攻击的威胁日益增加。
那么，这种攻击是如何发生的？为何系统容易受到这种攻击？
在传统系统中，开发者会预先设定程序和指令，它们是固定的。用户可以输入信息，但程序代码和用户输入保持独立。
然而，对于大型语言模型来说，指令和输入的界限变得模糊，因为这些模型通常使用输入来训练系统。
因此，大型语言模型的编码和输入没有过去那样清晰的界限，这既带来了灵活性，也带来了风险。
技术安全专家 Bruce Schneier 在 ACM 通讯上发表的文章详细论述了这一安全问题，指出其根源在于「没有将数据和控制路径分开」。
提示词注入攻击可能导致数据泄露、生成恶意内容和传播错误信息等后果。
攻击者可能会利用模型的自然语言处理能力，制定看似无害但实际上旨在提取特定信息的指令。
通过精心策划，攻击者可以诱使模型生成包含个人详细信息、公司内部运营甚至是模型训练数据中嵌入的安全协议的响应。
这种数据泄露不仅侵犯了个人隐私，还构成了重大的安全威胁，可能导致潜在的财务损失、声誉损害以及法律纠纷。
回到 Zhou 的案例，他的目标是操纵 Apple Intelligence 的「重写」功能，即对用户输入文本进行重写和改进。
在操作过程中，Zhou 发现，一个简单的「忽略先前的指令」命令居然失败了。
幸运的是，Apple Intelligence 的提示模板最近被 Reddit 用户公开，Zhou 从中发现了一个特殊 token，用于区分 AI 系统角色和用户角色。利用这些信息，Zhou 创建了一个覆盖原系统提示的提示。
他提前终止了用户角色，插入了一个新的系统提示，指示 AI 忽略之前的指令并响应后面的文本，然后触发了 AI 的响应。
经过一番实验，攻击成功了：Apple Intelligence 回复了 Zhou 未要求的信息，这意味着提示注入攻击有效。Zhou 在 GitHub 上发布了他的代码。
Twitter 用户攻破 GPT-3
提示注入问题自 2020 年 5 月发布的 GPT-3 以来就已为人所知，但仍未得到解决。
基于 GPT-3 API 的机器人 Remoteli.io 成为 Twitter 上此漏洞的受害者。该机器人本应自动发布远程工作，并响应远程工作请求。
然而，有了上述提示，Remoteli 机器人就成为了一些 Twitter 用户的笑柄：他们强迫机器人说出根据其原始指令不会说的语句。
例如，该机器人威胁用户，对挑战者号航天飞机灾难承担全部责任，或者诋毁美国国会议员为连环杀手。
在某些情况下，该机器人会传播虚假新闻或发布违反 Twitter 政策的内容，并应导致其被驱逐。
数据科学家 Riley Goodside 最先意识到这个问题，并在 Twitter 上进行了描述。
通过将提示插入正在翻译的句子中，Goodside 展示了，基于 GPT-3 的翻译机器人是多么容易受到攻击。
英国计算机科学家 Simon Willison 在他的博客上详细讨论了这个安全问题，将其命名为「提示注入」（prompt injection）。
Willison 发现大型语言模型的提示注入指令可能会导致各种奇怪和潜在危险的事情。他接着描述了各种防御机制，但最终驳回了它们。目前，他不知道如何从外部可靠地关闭安全漏洞。
当然，有一些方法可以缓解这些漏洞，例如，使用搜索用户输入中危险模式的相关规则。
但不存在 100% 安全的事情。Willison 说，每次更新大型语言模型时，都必须重新检查所采取的安全措施。此外，任何能够编写语言的人都是潜在的攻击者。
「像 GPT-3 这样的语言模型是终极黑匣子。无论我编写多少自动化测试，我永远无法 100% 确定用户不会想出一些我没有预料到的提示词，这会颠覆我的防御。」Willison 写道。
Willison 认为将指令输入和用户输入分开是一种可能的解决方案，也就是上述 ACM 文章中提到的「数据和控制路径分离」。他相信开发人员最终能够解决问题，但希望看到研究证明该方法确实有效。
一些公司采取了一些措施让提示注入攻击变得相对困难，这一点值得赞扬。
Zhou 破解 Apple Intelligence 时，还需要通过后端提示模板找到特殊 token；在有些系统中，提示注入攻击可以简单到，只需在聊天窗口中，或在输入的图片中长度相应文本。
2024 年 4 月，OpenAI 推出了指令层次法作为对策。它为来自开发人员（最高优先级）、用户（中优先级）和第三方工具（低优先级）的指令分配不同的优先级。
研究人员区分了「对齐指令」（与较高优先级指令相匹配）和「未对齐指令」（与较高优先级指令相矛盾）。当指令冲突时，模型遵循最高优先级指令并忽略冲突的较低优先级指令。
即使采取了对策，在某些情况下，像 ChatGPT 或 Claude 这样的系统仍然容易受到提示注入的攻击。
LLM 也有「SQL 注入」漏洞
除了提示词注入攻击，Andrej Karpathy 最近在推特上还指出了 LLM 存在的另一种安全漏洞，等效于传统的「SQL 注入攻击」。
LLM 分词器在解析输入字符串的特殊 token 时（如 <s>、<|endoftext|> 等），直接输入虽然看起来很方便，但轻则自找麻烦，重则引发安全问题。
需要时刻记住的是，不能信任用户输入的字符串！！
就像 SQL 注入攻击一样，黑客可以通过精心构造的输入，让模型表现出意料之外的行为。
Karpathy 随后在 Huggingface 上，用 Llama 3 分词器默认值提供了一组示例，发现了两点诡异的情况：
1、<|beginoftext|>token (128000) 被添加到序列的前面；
2、从字符串中解析出 <|endoftext|> 被标记为特殊 token (128001)。来自用户的文本输入现在可能会扰乱 token 规范，让模型输出结果不受控。
对此，Karpathy 给出了两个建议：
始终使用两个附加的 flag 值，(1) add_special_tokens=False 和 (2) split_special_tokens=True，并在代码中自行添加特殊 token。
对于聊天模型，还可以使用聊天模板 apply_chat_template。
按照 Karpathy 的方法，输出的分词结果看起来更正确，<|endoftext|> 被视为任意字符串而非特殊 token，并且像任何其他字符串一样被底层 BPE 分词器分解：
Karpathy 认为编码 / 解码调用永远不应该通过解析字符串来处理特殊 token，这个功能应该被彻底废弃，只能通过单独的代码路径以编程方式显式添加。
目前这类问题很难发现且文档记录很少，预计目前大约 50% 的代码存在相关问题。
另外，Karpathy 发现，连 ChatGPT 也存在
