據(jù)業(yè)內(nèi)信息，之前我們報道過前不久 ChatGPT 出現(xiàn)的安全漏洞，引發(fā)了關(guān)于數(shù)據(jù)管理的嚴(yán)重問題，近日 OpenAI 對數(shù)據(jù)泄漏事故原因發(fā)布了一份報告。

據(jù)悉，上周 OpenAI 聊天機(jī)器人 ChatGPT 的用戶可以訪問不屬于他們的聊天記錄，不少用戶在社交網(wǎng)絡(luò)上分享的幾張截圖最終提醒了 OpenAI，該公司最終暫時讓 ChatGPT 下線以解決問題。

隨后不久 OpenAI 發(fā)布了一份事后報告，就數(shù)據(jù)泄露事件和隨后發(fā)生的服務(wù)下線做出回應(yīng)，OpenAI 在報告中解釋聲稱事故原因是使用的開源組件 redis-py 存在漏洞，redis-py 是 Redis 數(shù)據(jù)庫的 Python 客戶端。

至于暴露的信息，OpenAI 表示包括姓名、郵件地址、賬單地址、信用卡號后四位以及卡片有效期，但是只有在北美當(dāng)?shù)貢r間 3 月 20 日 1~10 點進(jìn)行特定操作(比如打開訂閱確認(rèn)郵件/管理訂閱頁面)的用戶才會受到影響，因此泄露范圍有限，而且 OpenAI 也已經(jīng)聯(lián)系開發(fā)者修復(fù)了漏洞。

以下為 OpenAI 報告內(nèi)容：

由于開源庫中的一個錯誤，我們本周早些時候?qū)?ChatGPT 下線，該錯誤允許一些用戶看到另一個活躍用戶的聊天記錄中的標(biāo)題。如果兩個用戶大約同時處于活動狀態(tài)，那么新創(chuàng)建的對話的第一條消息也可能在其他人的聊天記錄中可見。

該錯誤現(xiàn)已修補(bǔ)。除了幾個小時的歷史記錄外，我們能夠恢復(fù) ChatGPT 服務(wù)以及后來的聊天記錄功能。正如承諾的那樣，我們將在下面發(fā)布此問題的更多技術(shù)細(xì)節(jié)。

經(jīng)過更深入的調(diào)查，我們還發(fā)現(xiàn)，同樣的錯誤可能導(dǎo)致 1.2% 的 ChatGPT Plus 訂閱者在特定的 9 小時窗口內(nèi)處于活躍狀態(tài)，從而無意中看到了與支付相關(guān)的信息。在周一我們關(guān)閉 ChatGPT 之前的幾個小時內(nèi)，一些用戶可能會看到另一個活躍用戶的名字和姓氏、電子郵件地址、支付地址、信用卡號的最后四位(僅)和信用卡到期時間日期。任何時候都不會暴露完整的信用卡號碼。

我們認(rèn)為，其數(shù)據(jù)實際泄露給其他人的用戶數(shù)量極少。要訪問此信息，ChatGPT Plus 訂閱者需要執(zhí)行以下操作之一：

• 打開太平洋時間 3 月 20 日星期一凌晨 1 點到 10 點發(fā)送的訂閱確認(rèn)電子郵件。由于該錯誤，該窗口期間生成的一些訂閱確認(rèn)電子郵件被發(fā)送給了錯誤的用戶。這些電子郵件包含另一個用戶信用卡號的最后四位數(shù)字，但沒有顯示完整的信用卡號。在 3 月 20 日之前，可能有少量訂閱確認(rèn)電子郵件被錯誤地處理，盡管我們尚未確認(rèn)任何此類情況。
• 在太平洋時間 3 月 20 日星期一凌晨 1 點到 10 點之間，在 ChatGPT 中單擊“我的帳戶”，然后單擊“管理我的訂閱”。在此窗口中，另一個活躍的 ChatGPT Plus 用戶的名字和姓氏、電子郵件地址、付款地址、信用卡號碼的最后四位(僅)和信用卡到期日期可能是可見的。這也可能發(fā)生在 3 月 20 日之前，盡管我們尚未確認(rèn)任何此類情況。

我們已聯(lián)系受影響的用戶通知他們的付款信息可能已被泄露。我們相信用戶數(shù)據(jù)不會持續(xù)存在風(fēng)險。

OpenAI 的每個人都致力于保護(hù)我們用戶的隱私并確保他們的數(shù)據(jù)安全。這是我們非常認(rèn)真對待的責(zé)任。不幸的是，本周我們沒有達(dá)到這一承諾，也沒有達(dá)到用戶的期望。我們再次向我們的用戶和整個 ChatGPT 社區(qū)致歉，并將努力重建信任。

在技術(shù)細(xì)節(jié)上，該錯誤是在 Redis 客戶端開源庫 redis-py 中發(fā)現(xiàn)的。一旦我們發(fā)現(xiàn)了這個錯誤，我們就聯(lián)系了 Redis 維護(hù)者并提供了一個補(bǔ)丁來解決這個問題。這是錯誤的工作原理：

• 我們使用 Redis 在我們的服務(wù)器中緩存用戶信息，因此我們不需要為每個請求檢查我們的數(shù)據(jù)庫。
• 我們使用 Redis Cluster 將此負(fù)載分布到多個 Redis 實例。
• 我們使用 redis-py 庫從使用 Asyncio 運(yùn)行的 Python 服務(wù)器與 Redis 交互。
• 該庫在服務(wù)器和集群之間維護(hù)一個共享連接池，并在完成后回收連接以用于另一個請求。
• 使用 Asyncio 時，使用 redis-py 的請求和響應(yīng)表現(xiàn)為兩個隊列：調(diào)用者將請求推送到傳入隊列，然后從傳出隊列彈出響應(yīng)，然后將連接返回到池中。
• 如果在請求被推送到傳入隊列之后，但在響應(yīng)從傳出隊列中彈出之前，請求被取消，我們會看到我們的錯誤：連接因此被破壞，并且為不相關(guān)請求出列的下一個響應(yīng)可以接收遺留下來的數(shù)據(jù)在連接中。
• 在大多數(shù)情況下，這會導(dǎo)致不可恢復(fù)的服務(wù)器錯誤，用戶將不得不再次嘗試他們的請求。
• 但在某些情況下，損壞的數(shù)據(jù)恰好與請求者期望的數(shù)據(jù)類型相匹配，因此從緩存中返回的數(shù)據(jù)看起來是有效的，即使它屬于另一個用戶。
• 太平洋時間 3 月 20 日星期一凌晨 1 點，我們無意中對服務(wù)器進(jìn)行了更改，導(dǎo)致 Redis 請求取消數(shù)量激增。這為每個連接返回錯誤數(shù)據(jù)創(chuàng)造了一個小概率。

此錯誤僅出現(xiàn)在 Redis Cluster 的 Asyncio redis-py 客戶端中，現(xiàn)已修復(fù)。

隨著我們調(diào)查的結(jié)束，支持和通知我們的用戶是我們的首要任務(wù)。 我們采取了以下措施來改進(jìn)我們的系統(tǒng)：

• 廣泛測試了我們對潛在錯誤的修復(fù)。
• 添加了冗余檢查以確保我們的 Redis 緩存返回的數(shù)據(jù)與請求用戶匹配。
• 以編程方式檢查我們的日志，以確保所有消息僅對正確的用戶可用。
• 關(guān)聯(lián)多個數(shù)據(jù)源以準(zhǔn)確識別受影響的用戶，以便我們可以通知他們。
• 改進(jìn)了日志記錄以識別何時發(fā)生并完全確認(rèn)它已停止。
• 提高了我們的 Redis 集群的穩(wěn)健性和規(guī)模，以減少在極端負(fù)載下出現(xiàn)連接錯誤的可能性。

最后，Redis 開源維護(hù)者是出色的合作者，他們迅速解決了錯誤并推出了補(bǔ)丁。Redis 和其他開源軟件在我們的研究工作中發(fā)揮著至關(guān)重要的作用。它們的重要性不可低估——如果沒有 Redis，我們將無法擴(kuò)展 ChatGPT。我們致力于不斷支持和貢獻(xiàn) Redis 社區(qū)。