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

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

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

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

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

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

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

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

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

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

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

OpenAI 的每個(gè)人都致力于保護(hù)我們用戶的隱私并確保他們的數(shù)據(jù)安全。這是我們非常認(rèn)真對(duì)待的責(zé)任。不幸的是，本周我們沒(méi)有達(dá)到這一承諾，也沒(méi)有達(dá)到用戶的期望。我們?cè)俅蜗蛭覀兊挠脩艉驼麄€(gè) ChatGPT 社區(qū)致歉，并將努力重建信任。

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

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

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

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

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

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