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

作者 | 屠敏

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

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

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

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

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

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

事件始末

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

但是，對于 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)品中使用開源項目，從中賺得盆滿缽滿，而自己從未提供技術(shù)資金支持，當(dāng)遇到問題時，又推回給開源開發(fā)者，一味“白嫖”只拿錢不辦事，再次增加了開源開發(fā)者的負(fù)擔(dān)。

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

關(guān)鍵詞：