ChatGPT數(shù)據(jù)泄露，技術(shù)細(xì)節(jié)公布

在上周一，ChatGPT 遭遇了一次用戶數(shù)據(jù)泄漏事件，許多 ChatGPT 的用戶都在自己的歷史對話中看到了其他人的對話記錄。不光是對話的歷史記錄，不少 ChatGPT Plus 用戶還在 Reddit 和 Twitter 等平臺發(fā)出了截圖，表示在他們的訂閱頁面上看到了其他人的電子郵件地址。

事件發(fā)生后，OpenAI 臨時關(guān)閉了 ChatGPT 服務(wù)以調(diào)查問題，后續(xù) Open AI 的首席執(zhí)行官 Sam Altman 也親自發(fā)了推文，承認(rèn)他們確實遭遇了重大問題，不過當(dāng)時并沒有公布問題的細(xì)節(jié)，只表示是一個開源庫的錯誤導(dǎo)致的。

由于一個開源庫的錯誤，我們在 ChatGPT 中出現(xiàn)了一個重大問題，現(xiàn)在已經(jīng)發(fā)布了一個修復(fù)程序，我們剛剛完成了驗證。 一小部分用戶能夠看到其他用戶的對話歷史的標(biāo)題。

經(jīng)過多日的調(diào)查，OpenAI 日前發(fā)布了一份包含技術(shù)細(xì)節(jié)的事件報告，該事件是 Redis 客戶端開源庫中的一個錯誤所引發(fā)的，導(dǎo)致 ChatGPT 服務(wù)暴露了其他用戶的聊天查詢歷史和大約 1.2% 的 ChatGPT Plus 用戶的個人信息。

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

這個錯誤是在 Redis 客戶端開源庫 redis-py 中發(fā)現(xiàn)的。發(fā)現(xiàn)這個 bug 后，OpenAI 就立即聯(lián)系了 Redis 的維護(hù)者，提供了一個補(bǔ)丁來解決這個問題。以下是這個錯誤的具體細(xì)節(jié)：

OpenAI 使用 Redis 在他們的服務(wù)器中緩存用戶信息，所以 ChatGPT 不需要為每個請求檢查數(shù)據(jù)庫。

OpenAI 使用 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)從傳出隊列中彈出之前，請求被取消，我們就會看到錯誤：連接因此被破壞，下一個為不相關(guān)的請求出列的響應(yīng)可以接收連接中留下的數(shù)據(jù)。

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

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

在太平洋時間 3 月 20 日星期一凌晨 1 點，OpenAI 無意中給他們的服務(wù)器引入了一個變化，導(dǎo)致 Redis 請求取消的情況激增。這在一定程度上引發(fā)了每個連接返回錯誤數(shù)據(jù)的可能性。

這個錯誤只出現(xiàn)在 Redis Cluster 的 Asyncio redis-py 客戶端，現(xiàn)在已經(jīng)被修復(fù)。

經(jīng)過深入調(diào)查，OpenAI 發(fā)現(xiàn)一些用戶有可能看到其他活躍用戶的姓名、電子郵件地址、賬單地址、信用卡號碼的最后四位數(shù)和信用卡到期日，OpenAI 特別強(qiáng)調(diào)道，完整的信用卡號碼并沒有暴露。

這部分受影響的用戶占 ChatGPT Plus 用戶總數(shù)的 1.2%，目前他們正在聯(lián)系了所有受影響的 ChatGPT 用戶。

審核編輯 ：李倩