返回上一页  首页 | cnbeta报时: 11:38:39
苹果Apple Intelligence存重大安全缺陷 几行代码即可攻破
发布日期:2024-08-15 14:13:41  稿源:新智元

Apple Intelligence上线在即,一小哥几行代码曝出Apple Intelligence安全缺陷。在2024年全球开发者大会 (WWDC) 上,Apple发布了将搭载在iOS 18.1中的AI功能Apple Intelligence。


眼看着10月即将正式上线了,有“民间高手”在MacOS 15.1提供的Beta测试版Apple Intelligence中发现重大缺陷。

开发人员Evan Zhou使用提示注入成功操纵了Apple Intelligence,绕过了预期指令让AI能对任意提示做出响应。

事实证明,它与其他基于大语言模型的AI系统一样,容易受到“提示词注入攻击”。开发人员Evan Zhou 在YouTube视频中演示了此漏洞。

什么是提示词注入攻击?

Current Time 0:00

/

Duration 10:56

自动播放

有一个组织叫OWASP,也就是开放全球应用安全项目,他们分析了大语言模型可能面临的主要漏洞。猜猜他们排名第一的是什么?没错,就是提示词注入。


提示词注入攻击 (Prompt Injection Attack) 是一种新型的攻击方式,具有有不同的形式,包括提示词注入、提示词泄露和提示词越狱。

当攻击者通过操纵人工智能,导致模型执行非预期操作或泄露敏感信息时,这种攻击就会发生。这种操纵可以使人工智能将恶意输入误解为合法命令或查询。

随着个人和企业对大语言模型(LLM)的广泛使用以及这些技术的不断进步,提示注入攻击的威胁正显著增加。

那么,这种情况最初是怎样发生的呢?为何系统会容易受到这种类型的攻击?

实际上,传统的系统中,开发者会预先设定好程序和指令,它们是不会变化的。

用户可以输入他们的信息,但是程序的代码和输入各自保持独立。

然而,对于大语言模型并非如此。也就是说,指令和输入的边界变得模糊,因为大模型通常使用输入来训练系统。

因此,大语言模型的编码和输入没有过去那样清晰、明确的界限。这带给它极大的灵活性,同时也有可能让模型做出一些不应该的事情。

技术安全专家、哈佛大学肯尼迪学院讲师Bruce Schneier 5月发表在ACM通讯上的文章对LLM的这个安全问题做出了详细论述。用他的话来说,这是源于“没有将数据和控制路径分开”。


提示词注入攻击会导致数据泄露、生成恶意内容和传播错误信息等后果。

当攻击者巧妙地构造输入指令来操纵AI模型,从而诱导其泄露机密或敏感信息时,就会发生提示注入攻击。

这种风险在利用包含专有或个人数据的数据集训练的模型中尤为突出。攻击者会利用模型的自然语言处理能力,制定表面上看似无害但实际上旨在提取特定信息的指令。

通过精心策划,攻击者可以诱使模型生成包含个人详细信息、公司内部运营甚至是模型训练数据中嵌入的安全协议的响应。

这种数据泄露不仅侵犯了个人隐私,还构成了重大的安全威胁,可能导致潜在的财务损失、声誉损害以及法律纠纷。

回到Zhou的案例来看,Zhou的目的是操纵Apple Intelligence的“重写”功能,即对用户输入文本进行重写和改进。

在操作的过程中,Zhou发现,一个简单的“忽略先前的指令”命令居然失败了。

如果这是一个“密不透风”的LLM,想继续往下挖掘就会相对困难。但巧合的是,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最近在Twitter上还指出了LLM存在的另一种安全漏洞,等效于传统的“SQL注入攻击”。

LLM分词器在解析输入字符串的特殊token时(如、<|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也存在这个bug。

最好的情况下它只是自发删除token,最坏的情况下LLM会无法理解你的意思,甚至不能按照指令重复输出<|endoftext|>这个字符串:


有网友在评论区提出问题,如果代码写得对,但是训练数据时候输入<|endoftext|>会发生什么?

Karpathy回应道,如果代码正确,什么都不会发生。问题是很多代码可能并不正确,这会悄悄搞坏他们的LLM。


最后,为了避免LLM漏洞引发安全问题,Karpathy提醒大家:一定要可视化你的token,测试你的代码。

我们在FebBox(https://www.febbox.com/cnbeta) 开通了新的频道,更好阅读体验,更及时更新提醒,欢迎前来阅览和打赏。
查看网友评论   返回完整版观看

返回上一页  首页 | cnbeta报时: 11:38:39

文字版  标准版  电脑端

© 2003-2024