ChatGPT中文网消息：近日，许多 ChatGPT 用户称，自己在使用 ChatGPT 时看到其他人的聊天查询列出现在了自己的历史记录中。
“这个应用程序正在向我显示其他人的聊天记录和内容。我没有输入任何这些提示或问题。”有推特网友称。这意味着，完全陌生的人可以使用不同的帐户查看别人的历史记录，而无需执行任何不同的操作。另外还有一些用户称自己看不到完整的聊天记录，但是可以看到对话标题。
该问题最早是在 3 月 20 日发现。不久后，OpenAI 将 ChatGPT 下线并调查问题，但没有立即提供导致中断的详细信息。
OpenAI 首席执行官 Sam Altman 在 3 月 23 日在推特上致歉，“由于开源库中的错误，我们在 ChatGPT 中遇到了一个重大问题，现在已经发布了修复程序，我们刚刚完成验证。一小部分用户能够看到其他用户对话历史的标题。我们对此感到很抱歉。”
次日，OpenAI 正式发布声明解释了该问题发生的原因。OpenAI 称这个错误是由 Redis 开源库中的一个错误导致的。如果两个用户差不多同时活跃，那么新创建对话的第一条消息也可能在另一个用户的聊天记录中可见。
另外，这个 Bug 可能导致了 1.2% ChatGPT Plus 用户的支付相关信息在无意中被泄露。一些用户可以看到另一个活跃用户的姓名、电子邮件地址、支付地址、信用卡号码的后四位数字(仅限)和信用卡到期日期。OpenAI 强调，完整的信用卡号码在任何时候都没有被曝光。
在声明中，OpenAI 表示“该错误现已修补”。但根据软件安全公司 Sonatype 的说法，尽管 Redis 在 4.5.3 版本和一些反向移植中发布了修复程序，但测试人员仍然能够重现该问题，因此认定其还未修复 Bug。
到底发生了什么?
根据 OpenAI 的说法，这个错误是在 Redis 客户端开源库 redis-py 中发现的。OpenAI 发现该错误后联系了 Redis 维护者并提供了一个补丁来解决这个问题。
OpenAI 在服务器中使用 Redis 缓存用户信息，因此不需要为每个请求检查数据库。 OpenAI 使用 Redis Cluster 将此负载分布到多个 Redis 实例上，并使用 redis-py 库来连接 Python 服务器中的 Redis ，该服务器使用 Asyncio 运行。这个库在服务器和集群之间维护一个共享连接池，并在完成后回收连接以用于处理另一个请求。
当使用 Asyncio 时，redis-py 的请求和响应表现为两个队列：调用者将请求推送到传入队列，然后从传出队列弹出响应，然后将连接返回到池中。
如果被推送到传入队列后请求被取消，但在响应从传出队列弹出之前可以看到一个 Bug：连接因此损坏，并且为无关请求退出队列的下一个响应可以接收到留在连接中的数据。
在大多数情况下，这会导致不可恢复的服务器错误，用户将不得不再次尝试进行请求。 但在某些情况下，损坏的数据恰好与请求者期望的数据类型相匹配，因此从缓存中返回的数据看起来是有效的，即使它属于另一个用户。
在太平洋时间 3 月 20 日星期一凌晨 1 点，OpenAI 团队无意中对服务器进行了更改，导致 Redis 请求取消数量激增，也使得每个连接返回错误数据的概率很小。
OpenAI 表示，此错误仅出现在 Redis Cluster 的 Asyncio redis-py 客户端中，现已修复。事故发生后，OpenAI 为改进系统采取了以下措施：
对潜在 Bug 进行了大规模测试和修复。
添加了冗余检查，以确保 Redis 缓存返回的数据与请求用户匹配。
以编程方式检查了日志，以确保所有消息仅对正确的用户可用。
关联了多个数据源来准确识别受影响的用户，以便通知相关用户。
改进了日志记录，用以识别何时发生并完全确认它已停止。
提高了 Redis 集群的稳健性和规模，减少在极端负载情况下出现连接错误的可能性。
官方声称修复 Bug 后，安全研究员 Gal Nagli 在推特上补充称，每当用户登录 ChatGPT，OpenAI 的应用程序都会从服务器获取用户的帐户上下文，如电子邮件、名称、图像和 accessToken。
Nagli 表示，“在高级视图中，该漏洞非常简单，如果设法强制负载均衡器将请求缓存在特定路径上，我们将能够从缓存的响应中读取受害者的敏感数据。在这种情况下，漏洞不会直接发生。为了让漏洞发挥作用，我们需要让 CF-Cache-Status 响应以确认缓存的‘HIT’，这意味着它缓存了数据，并将提供给跨同一区域的下一个请求。我们收到‘动态’响应，不会缓存数据。”
Nagli 称，要实现这一点，首先要创建一个特别设计的链接，将.CSS 资源附加到 “chat.openai[.]com/api/auth/session/”中，并诱骗受害者点击链接，这会让包含 accessToken 字符串的 JSON 对象被缓存在 Cloudflare 的 CDN 中。对 CSS 资源(CF-Cache-Status 头值设置为 HIT)的缓存响应然后被攻击者滥用，以获取目标的 JSON Web Token (JWT)凭据并接管帐户。
Nagli 说道，OpenAI 负责任地在披露后两小时内修复了这个 Bug，表明了问题的严重性。
Sonatype 认为，这背后是 Redis 的并发竞争问题。 Redis 团队也是对 AsyncIO 竞争条件(#2624、#2579)进行了紧急修复，但问题并没有完全解决。
开源软件担责吗?
对于 OpenAI 给出的解释，有开发者表示，“将责任推给开源可不是个好主意。”
“将闭源产品的错误归咎于开源库是不公平的。MIT 许可的依赖项明确表示没有任何保证。毕竟，在 ChatGPT 施加压力之前，该错误并未引起注意，而且是 ChatGPT 未能在其发布前的 QA 测试中排除该错误。”网友“abujazar”说道。
abujazar 认为，考虑到 OpenAI 本身在尽可能地封闭源代码，他们在声明的第一行中提到开源软件是他们中断的原因似乎有些不合适。“我认为开源作为生命的开场白，而对 Redis 团队的致谢出现在最后一行并不是巧合。许多软件工程以外的人可能会将此解读为‘开源导致 OpenAI 崩溃’。”
注：OpenAI 在声明的最后写道：Redis 开源维护者是出色的合作者，他们迅速解决了错误并推出了补丁。Redis 和其他开源软件在我们的研究工作中发挥着至关重要的作用。它们的重要性不可低估——如果没有 Redis，我们将无法扩展 ChatGPT。我们致力于不断支持和贡献 Redis 社区。
“如果 OpenAI 试图让 Redis 承担潜在的法律责任，我会非常愤怒。”有网友表示。
网友“YPPH”表示，“如果有人要求 ChatGPT 生成一些代码，然后不假思索地将其复制并粘贴到他们的项目中，我想知道 OpenAI 会如何看待这种说法：该错误是 ChatGPT 生成的错误代码造成的。”
不过也有一些网友表示，OpenAI 并没有责怪任何人，他们只是客观地表明了是那个库中的一个错误导致了问题。
开发者“random_cynic”表示，“讽刺的是，这种疯狂的言论对开源开发者的形象造成了比 OpenAI 或任何新闻稿更大的伤害。提到导致 Bug 的开源库是很重要的，因为许多其他使用它的应用程序可能也会发生这种情况。这基本上是开源的要点之一。
OpenAI，道阻且长
这次事件也引发了其他用户吐槽此前遇到的 Bug。“这让我想起了我遇到的第一个 Bug：通过 yahoo messenger 向自己发送一个 标签，你会随机得到一个从其他人和它的目标用户发回给你的消息对话。”网友“Greg Linares (Mantis)”表示。
“我有那个错误的变体，它在 0x45 (iirc) 的协议处理程序中允许用户注入格式错误的字符，并且会从消息流中泄漏，发生一次就为其他用户发送一条消息。”有网友表示，当其使用提示写出一些 React 代码时，已经发生了几次这样的错误。“它一直在提示超时，然后突然间我看到了其他人的提示。它们每次都不一样。”
Cyberhaven 首席执行官 Howard Ting 表示，“数据从本地迁移到云端，下一个重大转变将是将数据迁移到这些生成的应用程序中。” 这个转变中的数据安全问题也越来越引起人们的重视。
员工越来越多地将敏感的业务数据和隐私信息提交给 ChatGPT，比如有高管将公司的 2023 年战略文件剪切并粘贴到 ChatGPT 中，并要求它创建一个 PowerPoint 幻灯片。但 OpenAI 是否会将这些数据整合到模型中还没有明确的表示。
在最近的一份报告中，数据安全服务 Cyberhaven 检测到并阻止了其客户公司 160 万名员工中 4.2% 的人将数据输入 ChatGPT 的请求，因为存在泄露机密信息、客户数据、源代码或监管信息的风险。目前，摩根大通已经限制员工使用 ChatGPT，亚马逊、微软和沃尔玛也已向员工发出警告，要求员工谨慎使用生成式 AI 服务。
但上述问题并没有影响 OpenAI 的发展。不久前，OpenAI 宣布正式上线了以安全为核心的 ChatGPT 插件系统，ChatGPT 可以连接到第三方应用程序，与开发人员定义的 API 进行交互，从而增强自己的功能并允许其执行范围广泛的操作。
随着 OpenAI 生态的不断发展和扩大，OpenAI 必须做好应用安全运行的各方面工作。