Cloudflare Proxies 内存泄漏，又称“Cloudbleed”

一个缓冲区溢出缺陷导致了数据泄露，少量发往 Cloudflare proxies 的请求拿到了其他不相关请求数据，包括潜在的敏感数据，例如密码、其他秘密信息。这个问题已经被命名为“Cloudbleed”，由谷歌零漏洞项目组研究员 Tavis Ormandy 发现并记录。部署了修复程序并尝试清空搜索引擎缓存之后，Cloudflare 的 John Graham-Cumming 在一篇博客文章里详细地做出了解释。尽管有一些敏感数据泄漏，Cloudflare 的创始人和CEO Matthew Prince 在推特发表申明“我认为我们很大程度上避开了实际影响”。

在这篇解释性博客文章，以及CEO Matthew Prince致客户的邮件里，Cloudflare 费尽心力强调要保护好SSL 私钥，因为这些私钥被用于单独隔离的Nginx 实例中。这次泄漏是由于Nginx 插件组合引起的，Cloudflare 使用这些插件去处理客户请求。新引入的插件让一个隐藏在老插件里的问题暴露了出来，在解析不规范的HTML 文档时会出现问题。

这次事故预计已经影响了2017 年2 月13 日到2017 年2 月18 日之间，通过Cloudflare proxies 的每3,300,000 个HTTP 请求当中的1 个。安全专家Troy Hunt 在他的文章“实际思考CloudBleed ”中指出，这一可能性可以和“中大奖”相媲美，虽然这里的问题有双重性：首先，制造泄漏的网站本身也是无辜的受害网站，它又进一步放大了泄露问题，其次，我们没有办法“检查信息”，确保是否是泄漏受害者（同样适用于调用Cloudflare 和它们的访客网站）。Tony 指出这些访客或者例如博客一类的公共站点没有什么可以担心的，对于那些对数据敏感的网站来说就不一样了，例如约会网站和银行。AgileBits 费尽全力指出 1-Password 是安全的，同时 Monzo 指出这次问题只是潜在地影响了开发人员 API 用户的一小部分。

Cloudflare 推迟了通知时间，同时联合搜索引擎一起清空缓存数据，追踪从 161 个独立域名发送过来的 770 个请求 URI。这样做的目的是防止通过进入搜索引擎缓存的方式使用私人数据。虽然 Cloudflare 和 Google 从一开始就进行合作，这个问题看起来有点紧迫，清除行动可能没有像最初预期的那么快完成。

Graham-Cumming 的博客文章建议事故修复之后，通过非常容易理解的日志引导，允许 Cloudflare 确定问题的范围和规模，并且设定补救措施的目标。就像最初希望的那样达到目标。它的观点是，Cloudflare 躲过的风险很有可能是真实的，不仅仅危害了 Cloudflare 和它们的客户，也对大量的 web 用户产生危害。Cloudflare 预估可以在大于所有 web 峰值的 10% 的情况下正常工作，而且对于大多数人来说，不可能一天内不使用 Cloudflare，因为它为很多程序提供后台支撑。如果这个缺陷已经明晰，那么它应该很快就会被注意到，但是也可能对于Cloudflare 和它的客户造成更大的伤害。使用类似于Cloudflare 一类服务的风险正在增加，它们充当了web 用户和真实访问服务之间的“裁判”角色，必须找到平衡方式，就好像加强羊群内部的群体免疫能力一样。事情的另一面，很少有组织愿意对于自身基础设施这类错误进行快速而彻底地响应，就像Cloudflare 做的那样。他们使用的全局特性标志允许他们快速地把引起问题的堆栈信息移除掉。

事故发生后我们通常会问：“我是不是应该修改密码？”，舆论（反感风险）的回答是应该，安全比到时候说抱歉有用得多。总的来说，任何一个人的私密信息被以一个可以利用的方式泄漏的机会非常低（可能远远低于相同的私密信息通过恶意软件或者其他类似方式泄漏的可能性）。Cloudflare 和更广义的网络安全社区已经从这起事故中学到了很多，但是当类似于C 语言这样的不安全语言被继续用在对安全敏感的基础设施领域的话，我们可以确信类似的事故会再次发生（是的，再一次发生时 goto 陷阱仍然会是元凶）。

查看英文原文： Cloudbleed - Cloudflare Proxies Memory

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。