时间：2024-04-08 00:59:53
ChatGPT 的一个严重bug 已经7 天仍未完全修复，OpenAI 指出Redis 开源库中的一个错误是导致该问题的原因作者| 褚星娟最近，不少ChatGPT 用户表示看到了别人的聊天查询出现。使用ChatGPT 时的历史记录。 “这个应用程序显示了其他人的聊天记录和内容。我没有输入任何这些提示或问题，”一位Twitter 用户说道。这意味着使用不同帐户的完全陌生人可以查看其他人的历史记录，而无需执行任何特殊操作。此外，一些用户表示他们看不到完整的聊天记录，但可以看到对话标题。
这个问题最早是在3 月20 日发现的。 OpenAI 不久后让ChatGPT 下线以调查该问题，但没有立即说明导致中断的原因。 OpenAI CEO Sam Altman 3 月23 日发推文称，“开源库的一个bug 导致ChatGPT 出现严重问题。修复版本已经发布，刚刚经过验证。用户现在可以查看。这只是一小部分。”它，”他道歉。 “其他用户的对话历史标题。我们深表歉意。”第二天，OpenAI 官方发布声明解释了问题发生的原因。 OpenAI 表示，该错误是由Redis 开源库中的错误引起的。如果两个用户大约在同一时间处于活动状态，则新创建的对话的第一条消息也可能会出现在另一个用户的聊天历史记录中。此外，此错误可能意外暴露了1.2% 的ChatGPT Plus 用户的支付相关信息。某些用户可能会看到其他活跃用户的姓名、电子邮件地址、付款地址、信用卡号的最后四位数字（仅）以及信用卡到期日期。 OpenAI 强调信用卡号码从未被完全披露。 OpenAI 在一份声明中表示：“该漏洞目前正在修复中。”但据软件安全公司Sonatype 称，尽管Redis 在4.5.3 版本中发布了修复程序并进行了一些向后移植，但它仍被认为未修复，因为测试人员仍然能够重现该问题。
最后发生了什么？据OpenAI称，该漏洞是在Redis客户端开源库redis-py中发现的。 OpenAI 发现了该错误，联系了Redis 维护人员，并提供了补丁来解决该问题。 OpenAI 使用Redis 在服务器上缓存用户信息，因此无需在每次请求时都检查数据库。 OpenAI 使用Redis 集群将此负载分配到多个Redis 实例，并使用redis-py 库连接到使用Asyncio 运行的Python 服务器中的Redis。该库在服务器和集群之间维护一个共享连接池，并在完成后回收连接以用于处理另一个请求。使用Asyncio 时，redis-py 请求和响应表现为两个队列。调用者将请求推送到接收队列，从发送队列弹出响应，并将连接返回到池中。如果请求被推送到接收队列，然后在从发送队列中弹出响应之前被取消，则可能会出现错误。结果，连接中断，并且出列到不相关请求的下一个响应可以接收数据。连接仍然存在。在大多数情况下，这将导致不可恢复的服务器错误，并且用户必须重试请求。然而，在某些情况下，损坏的数据恰好与请求者期望的数据类型匹配，因此从缓存返回的数据看起来是有效的，即使它属于不同的用户。太平洋时间3 月20 日星期一凌晨1 点，OpenAI 团队无意中对服务器进行了更改，导致Redis 请求取消激增，并且每个连接都有可能返回不正确的数据。据OpenAI 称，这个bug 仅发生在Redis Cluster 的Asyncio redis-py 客户端中，现已修复。事件发生后，OpenAI 采取了以下措施来改进系统。
广泛的测试和潜在的错误修复。添加了冗余检查，以确保从Redis 缓存返回的数据与请求用户匹配。以编程方式检查日志，以确保所有消息仅可供正确的用户使用。我们关联了多个数据源，以帮助我们查明受影响的用户并通知相关用户。我们改进了日志记录，以识别何时发生这种情况并完全确认它已停止。 Redis 集群现在更加稳健和可扩展，减少了极端负载条件下连接失败的可能性。在官方声称已修复该漏洞后，安全研究员Gal Nagli 在Twitter 上写道，每次用户登录ChatGPT 时，OpenAI 的应用程序都会存储用户的帐户上下文（电子邮件、姓名、图像、accessToken 等）。我补充说，它将从服务器检索。示意图如下所示。
Nagli 说：“从总体上看，这个漏洞非常简单。如果你可以强制负载均衡器将请求缓存到特定路径，你就可以从缓存的响应中读取受害者的敏感数据。在这种情况下，漏洞不会直接发生；要使此漏洞发挥作用，缓存必须在CF-Cache-Status 响应中看到“HIT”。这意味着缓存会缓存数据并将其提供给缓存。 “以下请求位于同一区域。收到‘动态’响应，并且没有缓存任何数据。 Nagli 说，为了实现这一目标，首先创建一个专门设计的链接，将.CSS 资源附加到“chat.openai[.]com”。 /api/auth/session /' 诱骗受害者点击链接。这会在Cloudflare 的CDN 中缓存包含accessToken 字符串的JSON 对象。攻击者可以利用缓存的CSS 资源响应（CF-Cache-Status 标头值设置为HIT）来获取目标的JSON Web 令牌(JWT) 凭据并接管帐户。 Nagli 表示，OpenAI 在发布后两小时内负责任地修复了该错误，表明了问题的严重性。在Sonatype，我们认为这是由于Redis 并发争用问题造成的。 Redis 团队还针对AsyncIO 竞争条件提供了紧急修复（#2624、#2579），但问题并未完全解决。
开源软件有责任吗？对于OpenAI的解释，一些开发者表示，“将责任推到开源身上不是一个好主意”，“将闭源产品的错误归咎于开源库也不是一个好主意” “这是不公平的。毕竟，在ChatGPT 对MIT 许可证依赖项施加压力之前，这些错误并没有被注意到，而正是ChatGPT 在预发布的QA 测试中未能消除这些错误。”一位网友说道。“阿布贾扎尔”说道。鉴于OpenAI 本身正在努力变得尽可能闭源，阿布贾扎尔在声明第一行中提及开源软件作为中断的原因似乎有点不合适，我是这么认为的。 “我认为开源是生命的开始。最后一行对Redis 团队的感谢绝非巧合。许多软件工程之外的人认为这是‘开源导致了OpenAI 的崩溃’。”被解释为”：在声明的最后，OpenAI 写道：Redis 开源维护者是伟大的合作者，能够快速解决bug 并发布补丁。 Redis 和其他开源软件在我们的研究工作中发挥着重要作用。它们的重要性不容低估。 —— 如果没有Redis，则无法扩展ChatGPT。我们致力于持续支持Redis 社区并为其做出贡献。有网友表示：“如果OpenAI试图对Redis追究潜在的法律责任，我会非常生气。”网友“YPPH”表示，“如果有人要求ChatGPT 生成代码，然后不假思索地复制粘贴到自己的项目中，OpenAI 会怎么看待这种说法？错误是由ChatGPT 生成的错误代码引起的。”不过，也有网友表示，OpenAI并没有责怪任何人，只是客观地说明库中的错误是导致问题的原因。开发者“random_cynic”写道，“具有讽刺意味的是，这种疯狂的声明对开源开发者形象的损害比OpenAI 或任何提及导致该错误的开源库的新闻稿还要严重。”许多库都可能发生这种情况，因此值得一提的是导致该错误的开源库。”这基本上是开源的要点之一。
OpenAI 还有很长的路要走，这一事件促使其他用户抱怨他们之前遇到的错误。 “这让我想起了我遇到的第一个错误：