123,123,123

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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