ChatGPT 修复他人错误，却无法修正自身问题！OpenAI 揭示 Redis 开源数据库的漏洞

ChatGPT 的火爆，超出了很多人的想象。今年初，根据 UBS（瑞士银行巨头瑞银集团）的一份报告显示，ChatGPT 推出仅两个月后，它在 2023 年 1 月末的月活用户已经突破了 1 亿，成为史上用户数增长最快的消费者应用。

不过，就是这样一款应用，最近却被推上风口浪尖，只因不少用户发现自己竟然可以看到别人与 ChatGPT 的聊天记录。

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

这导致 OpenAI 曾一度选择紧急关闭 ChatGPT。经过几天的排查，直至近日，OpenAI 正式公开了此次事件的技术原因，其表示，是开源库 Redis 中的一个 Bug 才导致了 ChatGPT 服务暴露了其他用户的个人信息和聊天标题。

而这究竟是怎么一回事，我们将通过 OpenAI 的官方公告了解事情的真相。

事件始末

在上周，CSDN 报道过此事，彼时有一位 Reddit 用户率先发现，在与 ChatGPT 聊天记录栏中，多出了许多陌生的对话标题，这也让他产生了“ChatGPT 或我是被黑了吗？”的错觉。

没想到的是，这条帖子迅速引发了多人的关注，也有很多用户在下方留言称自己也遇到了同样的问题，一位 Twitter 用户 Jordan L Wheeler 表示：“我看不到内容，但可以看到他们最近的对话标题。”

OpenAI 在公告中对这种情况进行了解释，「如果两个用户大约同时在线活跃，那么新创建的对话的第一条消息也有可能在其他人的聊天记录中可见」。

技术细节

至于为什么会出现这种状况，OpenAI 进一步补充说，该错误是在 Redis 客户端开源库 redis-py 中发现的。以下是 Bug 的工作原理：

• OpenAI 使用 Redis 在其服务器中缓存用户信息，因此他们不需要为每个请求检索一遍数据库。

• 该团队使用 Redis Cluster 将此负载分布到多个 Redis 实例中。

• OpenAI 使用 redis-py 库，从基于 Asyncio 运行的 Python 服务器与 Redis 交互。

• 该库在服务器和集群之间维护一个共享连接池，并在完成后回收连接以用于另一个请求。

• 当使用 Asyncio 时，redis-py 的请求和响应表现为两个队列：调用者将请求推送到传入队列，然后从传出队列弹出响应，并将连接返回到池中。

• 如果在请求被推送到传入队列之后，但在响应从传出队列中弹出之前，请求被取消，OpenAI 便可以看到错误所在：连接因此被破坏，下一个为不相关的请求去排队的响应可以接收连接中留下的数据。

• 在大多数情况下，这会导致不可恢复的服务器错误，用户将不得不再次尝试他们的请求。

• 但在某些情况下，损坏的数据恰好与请求者期望的数据类型相匹配，因此从缓存中返回的数据看起来是有效的，即使它属于另一个用户。

• 太平洋时间 3 月 20 日星期一凌晨 1 点，OpenAI 无意中对服务器进行了更改，导致 Redis 请求取消数量激增。这为每个连接返回错误数据带来了一个小概率事件。

OpenAI 表示，这个错误只出现在 Redis Cluster 的 Asyncio redis-py 客户端中，在发现的第一时间，便联系了 Redis 维护者，现已修复。

不过，OpenAI 也承认这个错误会在其他地方带来一些影响，比如可能导致 1.2% 的 ChatGPT Plus 订阅者在特定的 9 小时（太平洋时间 3 月 20 日星期一凌晨 1 点到 10 点）无意中看到了别人与支付相关的信息，包括会看到另一个活跃用户的名字和姓氏、电子邮件地址、支付地址、信用卡号的最后四位（仅）和信用卡到期时间日期。

OpenAI 称已经联系受影响的用户并通知他们的付款信息可能已被泄露。同时，该研发团队也添加了冗余检查以确保 ChatGPT 应用程序的 Redis 缓存返回的数据与请求用户匹配。

OpenAI 也修复了关键账户接管漏洞

在另一个与缓存相关的问题中，OpenAI 还解决了一个关键的帐户接管漏洞。

该漏洞最初由安全研究员 Gal Nagli 发现，它绕过了 OpenAI 在 chat.openai[.]com 上实施的保护措施，可以被利用来控制另一个用户的帐户，查看他们的聊天记录，并在他们不知情的情况下访问账单信息。

实现这一目标的方法是，首先创建一个特制的链接，将一个 .CSS 资源加载到 "chat.openai[.]com/api/auth/session/"端点上，并诱使用户点击该链接，导致包含有 accessToken 字符串的 JSON 对象的响应被缓存在 Cloudflare 的 CDN 中。

对 CSS 资源的缓存响应（其 CF-Cache-Status header 值设置为HIT）然后被攻击者滥用，以收获目标的 JSON Web Token（JWT） 凭证并接管账户。

Nagli 表示，OpenAI 在负责任的披露后两小时内就修复了该漏洞，表明了问题的严重性。

开源维护者是否要为商业公司的使用负责到底？

不过，虽然 OpenAI 在公告中一直强调，“Redis 开源维护者是出色的合作者，他们迅速解决了错误并推出了补丁。Redis 和其他开源软件在我们的研究工作中发挥着至关重要的作用。它们的重要性不可低估——如果没有 Redis，我们将无法扩展 ChatGPT。”

但是，对于 ChatGPT 具备捉 Bug 能力，却避免不了自己的 Bug，而且 Redis 承担主责这一情况，也引发了不少网友的讨论，甚至称「ChatGPT 惹的祸，终是要让开源软件来担着了」。

这也让很多人联想到了当初风靡全球的 Log4j 2 漏洞，以及 Curl 创始人 Daniel Stenberg 剑指苹果的事件：

第三方公司在商业化产品中使用开源项目，从中赚得盆满钵满，而自己从未提供技术资金支持，当遇到问题时，又推回给开源开发者，一味“白嫖”只拿钱不办事，再次增加了开源开发者的负担。

对此，你认为开源维护者是否要为商业软件的安全问题负责到底？