在2024年全球開發(fā)者大會(huì) (WWDC) 上，Apple發(fā)布了將搭載在iOS 18.1中的AI功能Apple Intelligence。

眼看著10月即將正式上線了，有「民間高手」在MacOS 15.1提供的Beta測(cè)試版Apple Intelligence中發(fā)現(xiàn)重大缺陷。

開發(fā)人員Evan Zhou使用提示注入成功操縱了Apple Intelligence，繞過了預(yù)期指令讓AI能對(duì)任意提示做出響應(yīng)。

事實(shí)證明，它與其他基于大語言模型的AI系統(tǒng)一樣，容易受到「提示詞注入攻擊」。開發(fā)人員Evan Zhou 在YouTube視頻中演示了此漏洞。

什么是提示詞注入攻擊？

有一個(gè)組織叫OWASP，也就是開放全球應(yīng)用安全項(xiàng)目，他們分析了大語言模型可能面臨的主要漏洞。猜猜他們排名第一的是什么？沒錯(cuò)，就是提示詞注入。

提示詞注入攻擊 (Prompt Injection Attack) 是一種新型的攻擊方式，具有有不同的形式，包括提示詞注入、提示詞泄露和提示詞越獄。

當(dāng)攻擊者通過操縱人工智能，導(dǎo)致模型執(zhí)行非預(yù)期操作或泄露敏感信息時(shí)，這種攻擊就會(huì)發(fā)生。這種操縱可以使人工智能將惡意輸入誤解為合法命令或查詢。

隨著個(gè)人和企業(yè)對(duì)大語言模型（LLM）的廣泛使用以及這些技術(shù)的不斷進(jìn)步，提示注入攻擊的威脅正顯著增加。

那么，這種情況最初是怎樣發(fā)生的呢？為何系統(tǒng)會(huì)容易受到這種類型的攻擊？

實(shí)際上，傳統(tǒng)的系統(tǒng)中，開發(fā)者會(huì)預(yù)先設(shè)定好程序和指令，它們是不會(huì)變化的。

用戶可以輸入他們的信息，但是程序的代碼和輸入各自保持獨(dú)立。

然而，對(duì)于大語言模型并非如此。也就是說，指令和輸入的邊界變得模糊，因?yàn)榇竽Ｐ屯ǔＪ褂幂斎雭碛?xùn)練系統(tǒng)。

因此，大語言模型的編碼和輸入沒有過去那樣清晰、明確的界限。這帶給它極大的靈活性，同時(shí)也有可能讓模型做出一些不應(yīng)該的事情。

技術(shù)安全專家、哈佛大學(xué)肯尼迪學(xué)院講師Bruce Schneier 5月發(fā)表在ACM通訊上的文章對(duì)LLM的這個(gè)安全問題做出了詳細(xì)論述。用他的話來說，這是源于「沒有將數(shù)據(jù)和控制路徑分開」。

提示詞注入攻擊會(huì)導(dǎo)致數(shù)據(jù)泄露、生成惡意內(nèi)容和傳播錯(cuò)誤信息等后果。

當(dāng)攻擊者巧妙地構(gòu)造輸入指令來操縱AI模型，從而誘導(dǎo)其泄露機(jī)密或敏感信息時(shí)，就會(huì)發(fā)生提示注入攻擊。

這種風(fēng)險(xiǎn)在利用包含專有或個(gè)人數(shù)據(jù)的數(shù)據(jù)集訓(xùn)練的模型中尤為突出。攻擊者會(huì)利用模型的自然語言處理能力，制定表面上看似無害但實(shí)際上旨在提取特定信息的指令。

通過精心策劃，攻擊者可以誘使模型生成包含個(gè)人詳細(xì)信息、公司內(nèi)部運(yùn)營(yíng)甚至是模型訓(xùn)練數(shù)據(jù)中嵌入的安全協(xié)議的響應(yīng)。

這種數(shù)據(jù)泄露不僅侵犯了個(gè)人隱私，還構(gòu)成了重大的安全威脅，可能導(dǎo)致潛在的財(cái)務(wù)損失、聲譽(yù)損害以及法律糾紛。

回到Zhou的案例來看，Zhou的目的是操縱Apple Intelligence的「重寫」功能，即對(duì)用戶輸入文本進(jìn)行重寫和改進(jìn)。

在操作的過程中，Zhou發(fā)現(xiàn)，一個(gè)簡(jiǎn)單的「忽略先前的指令」命令居然失敗了。

如果這是一個(gè)「密不透風(fēng)」的LLM，想繼續(xù)往下挖掘就會(huì)相對(duì)困難。但巧合的是，Apple Intelligence的提示模板最近剛被Reddit用戶挖出來。

從這些模板中，Zhou發(fā)現(xiàn)了一個(gè)特殊token，用于將AI系統(tǒng)角色和用戶角色分開。

利用這些信息，Zhou創(chuàng)建了一個(gè)提示，覆蓋了原來的系統(tǒng)提示。

他提前終止了用戶角色，插入了一個(gè)新的系統(tǒng)提示，指示AI忽略之前的指令并響應(yīng)后面的文本，然后觸發(fā)AI的響應(yīng)。

經(jīng)過一番實(shí)驗(yàn)，攻擊成功了：Apple Intelligence回復(fù)了Zhou未要求的信息，這意味著提示注入攻擊有效。Zhou在GitHub上發(fā)布了他的代碼。

Twitter用戶攻破GPT-3

提示注入問題至少自2020年5月發(fā)布的GPT-3起就已為人所知，但仍未得到解決。

基于GPT-3 API的機(jī)器人Remoteli.io成為Twitter上此漏洞的受害者。該機(jī)器人應(yīng)該自動(dòng)發(fā)布遠(yuǎn)程工作，并響應(yīng)遠(yuǎn)程工作請(qǐng)求。

然而，有了上述提示，Remoteli機(jī)器人就成為了一些Twitter用戶的笑柄：他們強(qiáng)迫機(jī)器人說出根據(jù)其原始指令不會(huì)說的語句。

例如，該機(jī)器人威脅用戶，對(duì)挑戰(zhàn)者號(hào)航天飛機(jī)災(zāi)難承擔(dān)全部責(zé)任，或者詆毀美國(guó)國(guó)會(huì)議員為連環(huán)殺手。

在某些情況下，該機(jī)器人會(huì)傳播虛假新聞或發(fā)布違反Twitter政策的內(nèi)容，并應(yīng)導(dǎo)致其被驅(qū)逐。

數(shù)據(jù)科學(xué)家Riley Goodside最先意識(shí)到這個(gè)問題，并在Twitter上進(jìn)行了描述。

通過將提示插入正在翻譯的句子中，Goodside展示了，基于GPT-3的翻譯機(jī)器人是多么容易受到攻擊。

英國(guó)計(jì)算機(jī)科學(xué)家 Simon Willison在他的博客上詳細(xì)討論了這個(gè)安全問題，將其命名為「提示注入」（prompt injection）。

Willison發(fā)現(xiàn)大語言模型的提示注入指令可能會(huì)導(dǎo)致各種奇怪和潛在危險(xiǎn)的事情。他接著描述了各種防御機(jī)制，但最終駁回了它們。目前，他不知道如何從外部可靠地關(guān)閉安全漏洞。

當(dāng)然，有一些方法可以緩解這些漏洞，例如，使用搜索用戶輸入中危險(xiǎn)模式的相關(guān)規(guī)則。

但不存在100%安全的事情。Willison說，每次更新大語言模型時(shí)，都必須重新檢查所采取的安全措施。此外，任何能夠編寫語言的人都是潛在的攻擊者。

「像GPT-3這樣的語言模型是終極黑匣子。無論我編寫多少自動(dòng)化測(cè)試，我永遠(yuǎn)無法100%確定用戶不會(huì)想出一些我沒有預(yù)料到的提示詞，這會(huì)顛覆我的防御。」Willison寫道。

Willison認(rèn)為將指令輸入和用戶輸入分開是一種可能的解決方案，也就是上述ACM文章中提到的「數(shù)據(jù)和控制路徑分離」。他相信開發(fā)人員最終能夠解決問題，但希望看到研究證明該方法確實(shí)有效。

一些公司采取了一些措施讓提示注入攻擊變得相對(duì)困難，這一點(diǎn)值得贊揚(yáng)。

Zhou破解Apple Intelligence時(shí)，還需要通過后端提示模板找到特殊token；在有些系統(tǒng)中，提示注入攻擊可以簡(jiǎn)單到，只需在聊天窗口中，或在輸入的圖片中長(zhǎng)度相應(yīng)文本。

2024年4月， OpenAI推出了指令層次法作為對(duì)策。它為來自開發(fā)人員（最高優(yōu)先級(jí)）、用戶（中優(yōu)先級(jí)）和第三方工具（低優(yōu)先級(jí)）的指令分配不同的優(yōu)先級(jí)。

研究人員區(qū)分了「對(duì)齊指令」（與較高優(yōu)先級(jí)指令相匹配）和「未對(duì)齊指令」（與較高優(yōu)先級(jí)指令相矛盾）。當(dāng)指令沖突時(shí)，模型遵循最高優(yōu)先級(jí)指令并忽略沖突的較低優(yōu)先級(jí)指令。

即使采取了對(duì)策，在某些情況下，像ChatGPT或Claude這樣的系統(tǒng)仍然容易受到提示注入的攻擊。

LLM也有「SQL注入」漏洞

除了提示詞注入攻擊，Andrej Karpathy最近在推特上還指出了LLM存在的另一種安全漏洞，等效于傳統(tǒng)的「SQL注入攻擊」。

LLM分詞器在解析輸入字符串的特殊token時(shí)（如<s>、<|endoftext|>等），直接輸入雖然看起來很方便，但輕則自找麻煩，重則引發(fā)安全問題。

需要時(shí)刻記住的是，不能信任用戶輸入的字符串??！

就像SQL注入攻擊一樣，黑客可以通過精心構(gòu)造的輸入，讓模型表現(xiàn)出意料之外的行為。

Karpathy隨后在Huggingface上，用Llama 3分詞器默認(rèn)值提供了一組示例，發(fā)現(xiàn)了兩點(diǎn)詭異的情況：

1、<|beginoftext|>token (128000) 被添加到序列的前面;

2、從字符串中解析出 <|endoftext|>被標(biāo)記為特殊token (128001)。來自用戶的文本輸入現(xiàn)在可能會(huì)擾亂token規(guī)范，讓模型輸出結(jié)果不受控。

對(duì)此，Karpathy給出了兩個(gè)建議：

始終使用兩個(gè)附加的flag值， (1) add_special_tokens=False 和 (2) split_special_tokens=True，并在代碼中自行添加特殊token。

對(duì)于聊天模型，還可以使用聊天模板apply_chat_template。

按照Karpathy的方法，輸出的分詞結(jié)果看起來更正確，<|endoftext|> 被視為任意字符串而非特殊token，并且像任何其他字符串一樣被底層BPE分詞器分解：

總之，Karpathy認(rèn)為編碼/解碼調(diào)用永遠(yuǎn)不應(yīng)該通過解析字符串來處理特殊token，這個(gè)功能應(yīng)該被徹底廢棄，只能通過單獨(dú)的代碼路徑以編程方式顯式添加。

目前這類問題很難發(fā)現(xiàn)且文檔記錄很少，預(yù)計(jì)目前大約50%的代碼存在相關(guān)問題。

另外，Karpathy發(fā)現(xiàn)，連ChatGPT也存在這個(gè)bug。

最好的情況下它只是自發(fā)刪除token，最壞的情況下LLM會(huì)無法理解你的意思，甚至不能按照指令重復(fù)輸出<|endoftext|>這個(gè)字符串：

有網(wǎng)友在評(píng)論區(qū)提出問題，如果代碼寫得對(duì)，但是訓(xùn)練數(shù)據(jù)時(shí)候輸入<|endoftext|>會(huì)發(fā)生什么？

Karpathy回應(yīng)道，如果代碼正確，什么都不會(huì)發(fā)生。問題是很多代碼可能并不正確，這會(huì)悄悄搞壞他們的LLM。

最后，為了避免LLM漏洞引發(fā)安全問題，Karpathy提醒大家：一定要可視化你的token，測(cè)試你的代碼。