每日速看!ChatGPT修得了別人的Bug 修不了自己的！OpenAI直指開源數(shù)據(jù)庫Redis漏了底

作者 | 屠敏

ChatGPT 的火爆，超出了很多人的想象。今年初，根據(jù) UBS（瑞士銀行巨頭瑞銀集團(tuán)）的一份報(bào)告顯示，ChatGPT 推出僅兩個(gè)月后，它在 2023 年 1 月末的月活用戶已經(jīng)突破了 1 億，成為史上用戶數(shù)增長最快的消費(fèi)者應(yīng)用。

(相關(guān)資料圖)

不過，就是這樣一款應(yīng)用，最近卻被推上風(fēng)口浪尖，只因不少用戶發(fā)現(xiàn)自己竟然可以看到別人與 ChatGPT 的聊天記錄。

聊天信息被看光了可還行？

這導(dǎo)致 OpenAI 曾一度選擇緊急關(guān)閉 ChatGPT。經(jīng)過幾天的排查，直至近日，OpenAI 正式公開了此次事件的技術(shù)原因，其表示，是開源庫 Redis 中的一個(gè) Bug 才導(dǎo)致了 ChatGPT 服務(wù)暴露了其他用戶的個(gè)人信息和聊天標(biāo)題。

而這究竟是怎么一回事，我們將通過 OpenAI 的官方公告了解事情的真相。

事件始末

在上周，CSDN 報(bào)道過此事，彼時(shí)有一位 Reddit 用戶率先發(fā)現(xiàn)，在與 ChatGPT 聊天記錄欄中，多出了許多陌生的對(duì)話標(biāo)題，這也讓他產(chǎn)生了“ChatGPT 或我是被黑了嗎？”的錯(cuò)覺。

沒想到的是，這條帖子迅速引發(fā)了多人的關(guān)注，也有很多用戶在下方留言稱自己也遇到了同樣的問題，一位 Twitter 用戶 Jordan L Wheeler 表示：“我看不到內(nèi)容，但可以看到他們最近的對(duì)話標(biāo)題?！?/p>

OpenAI 在公告中對(duì)這種情況進(jìn)行了解釋，「如果兩個(gè)用戶大約同時(shí)在線活躍，那么新創(chuàng)建的對(duì)話的第一條消息也有可能在其他人的聊天記錄中可見」。

技術(shù)細(xì)節(jié)

至于為什么會(huì)出現(xiàn)這種狀況，OpenAI 進(jìn)一步補(bǔ)充說，該錯(cuò)誤是在 Redis 客戶端開源庫 redis-py 中發(fā)現(xiàn)的。以下是 Bug 的工作原理：

OpenAI 使用 Redis 在其服務(wù)器中緩存用戶信息，因此他們不需要為每個(gè)請(qǐng)求檢索一遍數(shù)據(jù)庫。

該團(tuán)隊(duì)使用 Redis Cluster 將此負(fù)載分布到多個(gè) Redis 實(shí)例中。

OpenAI 使用 redis-py 庫，從基于 Asyncio 運(yùn)行的 Python 服務(wù)器與 Redis 交互。

該庫在服務(wù)器和集群之間維護(hù)一個(gè)共享連接池，并在完成后回收連接以用于另一個(gè)請(qǐng)求。

當(dāng)使用 Asyncio 時(shí)，redis-py 的請(qǐng)求和響應(yīng)表現(xiàn)為兩個(gè)隊(duì)列：調(diào)用者將請(qǐng)求推送到傳入隊(duì)列，然后從傳出隊(duì)列彈出響應(yīng)，并將連接返回到池中。

如果在請(qǐng)求被推送到傳入隊(duì)列之后，但在響應(yīng)從傳出隊(duì)列中彈出之前，請(qǐng)求被取消，OpenAI 便可以看到錯(cuò)誤所在：連接因此被破壞，下一個(gè)為不相關(guān)的請(qǐng)求去排隊(duì)的響應(yīng)可以接收連接中留下的數(shù)據(jù)。

在大多數(shù)情況下，這會(huì)導(dǎo)致不可恢復(fù)的服務(wù)器錯(cuò)誤，用戶將不得不再次嘗試他們的請(qǐng)求。

但在某些情況下，損壞的數(shù)據(jù)恰好與請(qǐng)求者期望的數(shù)據(jù)類型相匹配，因此從緩存中返回的數(shù)據(jù)看起來是有效的，即使它屬于另一個(gè)用戶。

太平洋時(shí)間 3 月 20 日星期一凌晨 1 點(diǎn)，OpenAI 無意中對(duì)服務(wù)器進(jìn)行了更改，導(dǎo)致 Redis 請(qǐng)求取消數(shù)量激增。這為每個(gè)連接返回錯(cuò)誤數(shù)據(jù)帶來了一個(gè)小概率事件。

OpenAI 表示，這個(gè)錯(cuò)誤只出現(xiàn)在 Redis Cluster 的 Asyncio redis-py 客戶端中，在發(fā)現(xiàn)的第一時(shí)間，便聯(lián)系了 Redis 維護(hù)者，現(xiàn)已修復(fù)。

不過，OpenAI 也承認(rèn)這個(gè)錯(cuò)誤會(huì)在其他地方帶來一些影響，比如可能導(dǎo)致 1.2% 的 ChatGPT Plus 訂閱者在特定的 9 小時(shí)（太平洋時(shí)間 3 月 20 日星期一凌晨 1 點(diǎn)到 10 點(diǎn)）無意中看到了別人與支付相關(guān)的信息，包括會(huì)看到另一個(gè)活躍用戶的名字和姓氏、電子郵件地址、支付地址、信用卡號(hào)的最后四位（僅）和信用卡到期時(shí)間日期。

OpenAI 稱已經(jīng)聯(lián)系受影響的用戶并通知他們的付款信息可能已被泄露。同時(shí)，該研發(fā)團(tuán)隊(duì)也添加了冗余檢查以確保 ChatGPT 應(yīng)用程序的 Redis 緩存返回的數(shù)據(jù)與請(qǐng)求用戶匹配。

OpenAI 也修復(fù)了關(guān)鍵賬戶接管漏洞

在另一個(gè)與緩存相關(guān)的問題中，OpenAI 還解決了一個(gè)關(guān)鍵的帳戶接管漏洞。

該漏洞最初由安全研究員 Gal Nagli 發(fā)現(xiàn)，它繞過了 OpenAI 在 chat.openai[.]com 上實(shí)施的保護(hù)措施，可以被利用來控制另一個(gè)用戶的帳戶，查看他們的聊天記錄，并在他們不知情的情況下訪問賬單信息。

實(shí)現(xiàn)這一目標(biāo)的方法是，首先創(chuàng)建一個(gè)特制的鏈接，將一個(gè) .CSS 資源加載到 "chat.openai[.]com/api/auth/session/"端點(diǎn)上，并誘使用戶點(diǎn)擊該鏈接，導(dǎo)致包含有 accessToken 字符串的 JSON 對(duì)象的響應(yīng)被緩存在 Cloudflare 的 CDN 中。

對(duì) CSS 資源的緩存響應(yīng)（其 CF-Cache-Status header 值設(shè)置為HIT）然后被攻擊者濫用，以收獲目標(biāo)的 JSON Web Token（JWT） 憑證并接管賬戶。

Nagli 表示，OpenAI 在負(fù)責(zé)任的披露后兩小時(shí)內(nèi)就修復(fù)了該漏洞，表明了問題的嚴(yán)重性。

開源維護(hù)者是否要為商業(yè)公司的使用負(fù)責(zé)到底？

不過，雖然 OpenAI 在公告中一直強(qiáng)調(diào)，“Redis 開源維護(hù)者是出色的合作者，他們迅速解決了錯(cuò)誤并推出了補(bǔ)丁。Redis 和其他開源軟件在我們的研究工作中發(fā)揮著至關(guān)重要的作用。它們的重要性不可低估——如果沒有 Redis，我們將無法擴(kuò)展 ChatGPT?！?/p>

但是，對(duì)于 ChatGPT 具備捉 Bug 能力，卻避免不了自己的 Bug，而且 Redis 承擔(dān)主責(zé)這一情況，也引發(fā)了不少網(wǎng)友的討論，甚至稱「ChatGPT 惹的禍，終是要讓開源軟件來擔(dān)著了」。

這也讓很多人聯(lián)想到了當(dāng)初風(fēng)靡全球的 Log4j 2 漏洞，以及 Curl 創(chuàng)始人 Daniel Stenberg 劍指蘋果的事件：

第三方公司在商業(yè)化產(chǎn)品中使用開源項(xiàng)目，從中賺得盆滿缽滿，而自己從未提供技術(shù)資金支持，當(dāng)遇到問題時(shí)，又推回給開源開發(fā)者，一味“白嫖”只拿錢不辦事，再次增加了開源開發(fā)者的負(fù)擔(dān)。

對(duì)此，你認(rèn)為開源維護(hù)者是否要為商業(yè)軟件的安全問題負(fù)責(zé)到底？

關(guān)鍵詞：