Redis 错误导致 ChatGPT 数据泄露,技术细节一并公布
在上周一,ChatGPT 遭遇了一次用户数据泄漏事件,许多 ChatGPT 的用户都在自己的历史对话中看到了其他人的对话记录。不光是对话的历史记录,不少 ChatGPT Plus 用户还在 Reddit 和 Twitter 等平台发出了截图,表示在他们的订阅页面上看到了其他人的电子邮件地址。
事件发生后,OpenAI 临时关闭了 ChatGPT 服务以调查问题,后续 Open AI 的首席执行官 Sam Altman 也亲自发了推文,承认他们确实遭遇了重大问题,不过当时并没有公布问题的细节,只表示是一个开源库的错误导致的。
由于一个开源库的错误,我们在 ChatGPT 中出现了一个重大问题,现在已经发布了一个修复程序,我们刚刚完成了验证。
一小部分用户能够看到其他用户的对话历史的标题。
经过多日的调查,OpenAI 日前发布了一份包含技术细节的事件报告,该事件是 Redis 客户端开源库中的一个错误所引发的,导致 ChatGPT 服务暴露了其他用户的聊天查询历史和大约 1.2% 的 ChatGPT Plus 用户的个人信息。
技术细节
这个错误是在 Redis 客户端开源库 redis-py 中发现的。发现这个 bug 后,OpenAI 就立即联系了 Redis 的维护者,提供了一个补丁来解决这个问题。以下是这个错误的具体细节:
- OpenAI 使用 Redis 在他们的服务器中缓存用户信息,所以 ChatGPT 不需要为每个请求检查数据库。
- OpenAI 使用 Redis Cluster 将这一负载分布到多个 Redis 实例上。
- OpenAI 使用 redis-py 库,以便让用了 Asyncio 的 Python 服务器与 Redis 对接。
- 该库在服务器和集群之间维护一个共享的连接池,并在完成后回收连接以用于另一个请求。
- 当使用 Asyncio 时,redis-py 的请求和响应表现为两个队列:调用者将请求推送到传入队列,并从传出队列中弹出响应,然后将连接返回到池中。
- 如果在请求被推送到传入队列之后,但在响应从传出队列中弹出之前,请求被取消,我们就会看到错误:连接因此被破坏,下一个为不相关的请求出列的响应可以接收连接中留下的数据。
- 在大多数情况下,这会导致一个无法恢复的服务器错误,而用户将不得不重新尝试他们的请求。
- 但在某些情况下,损坏的数据恰好与请求者所期望的数据类型相匹配,因此从缓存中返回的数据看起来是有效的,即使这些数据属于另一个用户。
- 在太平洋时间 3 月 20 日星期一凌晨 1 点,OpenAI 无意中给他们的服务器引入了一个变化,导致 Redis 请求取消的情况激增。这在一定程度上引发了每个连接返回错误数据的可能性。
- 这个错误只出现在 Redis Cluster 的 Asyncio redis-py 客户端,现在已经被修复。
经过深入调查,OpenAI 发现一些用户有可能看到其他活跃用户的姓名、电子邮件地址、账单地址、信用卡号码的最后四位数和信用卡到期日,OpenAI 特别强调道,完整的信用卡号码并没有暴露。
这部分受影响的用户占 ChatGPT Plus 用户总数的 1.2%,目前他们正在联系了所有受影响的 ChatGPT 用户。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Twitter 称其部分源代码在网上被泄露
根据《纽约时报》的报道,一份法律文件显示,Twitter 称其部分源代码在网上被泄露,该公司已于上周五采取行动,它通过向托管代码的 GitHub 发送版权侵权通知,删除了被泄露的代码。 文件显示 Twitter 还要求美国加利福尼亚州北区地方法院命令 GitHub 识别共享代码的人以及下载代码的任何其他人。 GitHub 遵从要求,并在当天下架了代码仓库。目前还不清楚泄露的代码在网上发布了多长时间,但它似乎已经公开了至少几个月。 此外,GitHub 按照公司的透明度规则公开了 Twitter 发送的侵权通知。通知文件显示,此次被泄露的源代码是 Twitter 平台和内部工具的私有源代码。具体的仓库地址是:https://github.com/FreeSpeechEnthusiast/PublicSpace。(该帐号的名字 (FreeSpeechEnthusiast) 其实就是在内涵马斯克,毕竟他曾自称“言论自由绝对主义者”)。 两位了解内部调查情况的人士表示,Twitter 对源代码泄露事件展开了调查,处理此事的高管推测,负责此事的人去年离开了这家总部位于旧金山的公司。此外,这些高管最...
- 下一篇
字节跳动在限速器优化上的实践探索
限速器(rate limiter)是一个非常基础的网络包处理功能,被广泛应用于各类网元设备,在流量调度、网络安全等领域发挥着重要作用。常见的限速器的实现方式基于令牌桶(token bucket),尽管令牌桶的原理已经被人熟知,在具体实践中,我们也发现了一些挑战和共性问题。本文总结了近两年字节跳动系统与技术工程团队(简称 STE 团队)在限速器优化方面的一些探索,将一些经验和教训总结出来,以飨读者。 令牌桶限速器的基本原理 相信每个写网络包处理的工程师都写过基本的令牌桶限速器。令牌桶是一个形象的描述,既可以想象有一个桶可以容纳一定量的令牌(token),每放行一个数据包便消耗一定量的令牌,数据包的放行与否取决于令牌桶中的令牌个数。 图1 令牌桶图示 比如,如果令牌桶限制的是 PPS (Packet Per Second),假设一个令牌代表一个数据包。那么一个限定 PPS 为 300K/s 的限速器,每秒会产生的令牌数则是 300K 个。任何一个数据包经过这个限速器,则消耗一个令牌,如果令牌消耗到 0,则进行丢包。 假设\(P_t \) 表示到达时间是\(t\) 的数据包,令牌桶上一个经过...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 2048小游戏-低调大师作品
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,CentOS7官方镜像安装Oracle11G