Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

【技术分享】Cloudflare解析器bug导致内存泄漏事件报告

0
0
【技术分享】Cloudflare解析器bug导致内存泄漏事件报告

2017-02-24 18:37:19
来源:cloudflare.com 作者:myswsun

阅读:616次
点赞(0)
收藏





【技术分享】Cloudflare解析器bug导致内存泄漏事件报告

翻译:myswsun

预估稿费:260RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


0x00 前言

上星期五,来自谷歌Project Zero组织的Tavis Ormandy联系Cloudflare,报告了我们的边界服务器的一个安全问题。他看到经过Cloudflare的一些HTTP请求返回了崩溃的网页。

它出现在一些不寻常的情况下,在下面我将详细介绍,我们的边界服务器运行时缓冲区越界了,并返回了隐私信息,如 HTTP cookies,认证令牌,HTTP POST体和其他敏感数据的内存。并且有些数据会被搜索引擎缓存。

为了避免怀疑,Cloudflare客户的SSL私钥没有泄漏。Cloudflare总是通过一个隔离的Nginx实例来结束SLL连接,因此不受这个bug影响。

我们快速的确认了这个问题,并关闭了3个Cloudflare功能(邮件混淆,服务端排除和自动HTTPs重写),这些都用来了相同的HTML解析器链,会导致泄漏。这样在一个HTTP响应中就不会有内存返回了。

因为这个bug的严重性,来自San Francisco和 London的软件工程师、信息安全和操作的交叉功能团队充分了解了潜在的原因,为了降低内存泄漏的影响,和谷歌和其他搜索引擎团队一起将缓存的HTTP响应移除了。

拥有一个全球化的团队,每12小时为间隔,每天24小时交替解决这个问题。团队持续的努力确保了问题的圆满解决。作为服务的一个优势是这个bug从报告到解决,花了几分钟到几小时,而不是几个月。针对这样的bug部署修复方案的工业标准通常是3个月;我们在小于7个小时就圆满解决,47分钟内就缓解了bug。

这个bug是严重的,因为泄漏的内存包含了隐私信息,并且还会被搜索引擎缓存。我们还没有发现这个bug的漏洞利用或者它们存在的报告。

影响最大的时期是2月13日到2月18号,通过Cloudflare的每3,300,000个HTTP请求中约有1个可能导致内存泄漏(约为请求的0.00003%)。

我们感谢它由世界顶级安全研究团队发现并报告给我们。

本文很长,但是作为我们的传统,我们倾向于对我们的服务出现的问题保持开放和技术上的详细描述。


0x01 运行时解析并修改HTML

很多Cloudflare服务依赖通过我们的边界服务器时解析和修改HTML页面。例如,我们能通过修改HTML页面来插入谷歌分析标签,安全的重写http://链接为https://,排除来自机器人的部分页面,模糊电子邮件地址,启用AMP等。

为了修改页面,我们需要读取并解析HTML以发现需要修改的元素。因为在Cloudflare的早期,我们已经使用了用Ragel编写的解析器。一个独立的.rl文件包含一个HTML解析器,被用来在Cloudflare平台修改HTML。

大约一年前,我们认为Ragel解析器维护起来太复杂,并且我们开始写一个新的解析器(cf-html)来替代它。这个解析器能正确处理html5,而且非常非常快且易维护。

我们首先将这个解析器用于自动HTTP重写功能,并一直慢慢地迁移cf-html替换Ragel。

Cf-html和老的Ragel解析器都作为Nginx模块实现,并编译到我们的Nginx构建中。这个Nginx过滤模块解析包含HTML响应的缓冲区(内存块),做出必要的修改,并将缓冲区传递给下一个过滤模块。

这样,引起内存泄漏的bug在我们的Ragel解析器中已存在多年,但是因为我们内部Nginx使用缓冲区的方式,并没有内存泄漏。Cf-html巧妙的改变了缓冲去,导致在cf-html中不会有问题。

因为我们知道了这个bug是由激活cf-html引起的(但是之前我们知道为什么),我们禁用了使用它的3个功能。Cloudflare每个功能都有一个相应的功能标志,我们称之为全局杀手。我们在收到问题细节报告后的47分钟时启用了邮件混淆的全局杀手,并在3小时5分钟后关闭了自动HTTP重写。邮件混淆功能在2月13号已经修改了,并且是内存泄漏的原因,因此禁用它快速地阻止了几乎所有的内存泄漏。

在几秒内,这些功能在全球范围内被禁用。我们确定没有通过测试URI来泄漏内存,并且谷歌的二次校验也一样。

然后,我们发现了第三个功能(服务端排除)也有这个漏洞,但是没有全局杀手开关(它非常老,在全局杀手之前实现)。我们为服务端排除实现了一个全局杀手,并全球部署补丁。从发现服务端排除是个问题到部署补丁只花了3个小时。然而,服务端排除很少使用,且只针对对恶意的IP地址才激活。


0x02 bug的根因

Ragel代码转化为C代码,然后编译。这个C代码使用经典的C方法,指向HTML文档的指针被解析,并且Ragel自身给用户提供了针对这些指针大量的控制权。因为一个指针错误导致的bug的产生。

/*generatedcode*/ if(++p==pe) goto_test_eof;

bug的根因是,使用等于运算符来校验是否到达缓冲区的末端,并且指针能够步过缓冲去末端。这是熟知的缓冲去溢出。使用>=代替==来做检验,将跳过缓冲区末端。这个等于校验由Ragel自动生成,不是我们编写的代码。意味着我们没有正确的使用Ragel。

我们编写的Ragel代码包含了一个bug,其能引起指针越界且给了等号校验造成缓冲区溢出的能力。

下面是Ragel代码的一段代码,用来获取HTML <script>标签中的一个属性。第一行说的是它试图找到更多以空格,正斜杠或>结尾的unquoted_attr_char。(:>>是连接符)

script_consume_attr:=((unquoted_attr_char)*:>>(space|'/'|'>')) >{ddctx("scriptconsume_attr");} @{fhold;fgotoscript_tag_parse;} $lerr{dd("scriptconsume_attrfailed"); fgotoscript_consume_attr;};

如果一个属性格式良好,则Ragel解析器跳转到@{}代码块。如果解析属性失败(就是我们今天讨论的bug的开始),那么到$lerr{}。

举个例子,在实际情况下(细节如下),如果web页面以错误的HTML标签结尾,如:

<scripttype=

$lerr{ }块将执行,并且缓冲去将溢出。这个例子中$lerr执行dd(“script consume_attr failed”);(这是个调试语句),然后执行fgoto script_consume_attr;(转移到script_consume_attr去解析下一个属性)。

从我们的分析中看,这样错误的标签出现在大约0.06%的网站中。

如果你观察仔细,你可能已经注意到@{ }也是一个fgoto,但是在它之前执行了fhold,并且$lerr{ }没有。它没有fhold导致了内存泄漏。

在内部,生成的C代码有一个指针p,指向HTML文档中正在检测的字符。Fhold等价于p--,并且是必要的。因为当错误条件发生时,p将指向导致script_consume_attr失败的字符。

并且它非常重要,因为如果这个错误条件发生在包含HTML文档的缓冲区的末尾,则p将在文档末端的后面(p将是pe+1),且达到缓冲区末尾的校验将失败,p将在缓冲去外部运行。

添加一个fhold到错误处理函数中,能解决这个问题。


0x03 为什么

上面解释了指针如何运行超过缓冲区的末尾,但是问题内部为什么没有显示。毕竟,这个代码在生产环境上已经稳定很多年了。

回到上面定义的script_consume_attr:

script_consume_attr:=((unquoted_attr_char)*:>>(space|'/'|'>')) >{ddctx("scriptconsume_attr");} @{fhold;fgotoscript_tag_parse;} $lerr{dd("scriptconsume_attrfailed"); fgotoscript_consume_attr;};

当解析器解析超过字符范围时会发生什么,当前被解析的缓冲区是否是最后一个缓冲区是不同的。如果它不是最后一个缓冲区,那么没必要使用$lerr,因为解析器不知道是否会发生错误,因为剩余的属性可能在下一个缓冲区中。

但是如果这是最后一个缓冲区,那么$lerr被执行。下面是代码末尾如何跳过了文件末尾且运行内存。

解析函数的入口点是ngx_http_email_parse_email(名字是古老的,它不止做了邮件解析的事)。

ngx_int_tngx_http_email_parse_email(ngx_http_request_t*r,ngx_http_email_ctx_t*ctx){ u_char*p=ctx->pos; u_char*pe=ctx->buf->last; u_char*eof=ctx->buf->last_buf?pe:NULL;

你能看到p指向缓冲区的第一个字符,pe是缓冲区后的字符,且pe设置为eof。如果这是这个链中的最后一个缓冲区(有boolean last_buf表示),否者为NULL。

当老的和新的解析器在请求处理时同时存在,这类缓冲区将传给上面的函数。

(gdb)p*in->buf $8={ pos=0x558a2f58be30"<scripttype=\"", last=0x558a2f58be3e"", [...] last_buf=1, [...] }

上面是数据,last_buf是1。当新的解析器不存在时,最后一个缓冲区包含的数据如下:

(gdb)p*in->buf $6={ pos=0x558a238e94f7"<scripttype=\"", last=0x558a238e9504"", [...] last_buf=0, [...] }

最后的空缓冲区(pos和last都是NULL且last_buf=1)接着那个缓冲区,但是如果缓冲区是空的,ngx_http_email_parse_email不会被调用。

因此,只有当老的解析器存在是,最后一个缓冲区包含的数据才有last_buf是0。这意味着eof将是NULL。现在当试图在缓冲区末尾处理一个不完整的script_consume_attr。$ lerr将不会被执行,因为解析器相信(因为last_buf)可能有更多的数据来了。

当两个解析器都存在时,情况是不同的。 last_buf为1,eof设置为pe,$ lerr代码运行。下面是生成的代码:

/*#line877"ngx_http_email_filter_parser.rl"*/ {dd("scriptconsume_attrfailed"); {gotost1266;}} gotost0; [...] st1266: if(++p==pe) goto_test_eof1266;

解析器解析完字符,而试图执行script_consume_attr, p将是pe。因为没有fhold(这将做p--),当代码跳转到st1266, p增加将超过pe。

然后不会跳转到_test_eof1266(在这将执行EOF校验),并且将超过缓冲区末尾,试图解析HTML文档。

因此,bug潜伏了多年,直到在NGINX过滤器模块之间传递的缓冲区的内部风水随着cf-html的引入而改变。


0x04 继续寻找bug

在1960和1970年代,IBM的研究展示了bug集中在易错模块中。因为我们在Ragel生成的代码中找到了一个讨厌的指针溢出,所以将谨慎的去查找其他的bug。

信息安全团队的一部分人开始模糊测试生成的代码,来查找潜在的指针溢出。另一个团队使用恶意构造的web网页构建测试用例。软件工程师团队开始手动排查代码问题。

决定在生成的代码中为每个访问的指针显式添加校验,并且计入任何发生的错误。生成的错误被反馈到我们的全局错误记录基础结构,用于分析。

#defineSAFE_CHAR({\ if(!__builtin_expect(p<pe,1)){\ ngx_log_error(NGX_LOG_CRIT,r->connection->log,0,"emailfiltertriedtoaccesscharpastEOF");\ RESET();\ output_flat_saved(r,ctx);\ BUF_STATE(output);\ returnNGX_ERROR;\ }\ *p;\ }) 我们 看到日志如下:
2017/02/1913:47:34[crit]27558#0:*2emailfiltertriedtoaccesscharpastEOFwhilesendingresponsetoclient,client:127.0.0.1,server:localhost,request:"GET/malformed-test.htmlHTTP/1.1”

每行日志表示一个HTTP请求,可能有泄漏的内存。通过记录问题发生的频率,我们希望得到在错误存在时HTTP请求泄漏内存的次数的统计。

为了针对内存泄漏,下面的东西必须正确:

最后一个缓冲区包含的数据必须以以恶意格式的脚本或者img标签结束

缓冲区必须小于4K长度(否则Nginx可能崩溃)

用户必须开启邮件混淆(因为她同时使用新旧解析器)。

…或者自动HTTPs重写/服务端排除(使用了新解析器)组合另一个使用老的解析器的功能。…并且服务端排除只有在客户端IP具有较差的信誉(即它对大多数访问者不起作用)时才执行。

那就解释了为什么缓冲区溢出导致了内存泄漏的发生的情况如此少。

此外,邮件模糊功能(使用两个解析器,并会使错误发生在大多数Cloudflare网站上)仅在2月13日(Tavis报告的前四天)启用。

涉及的三个功能按如下顺序推出。内存可能泄漏的最早的日期是2016-09-22。

2016-09-22 Automatic HTTP Rewrites 启用

2017-01-30 Server-Side Excludes 整合新的解析器

2017-02-13 Email Obfuscation 部分整合新的解析器

2017-02-18 Google 报告问题给Cloudflare且泄漏结束

最大的潜在威胁发生在2月13号开始的4天内,因为自动HTTP重写没有被广泛使用,服务端排除只对恶意的IP地址才有效。


0x05 Bug的内部影响

Cloudflare在边界机器上面运行了多个独立的进程,且提供了进程和内存隔离。内存泄漏来自与一个基于Nginx的进程(处理HTTP)。它有一个独立的进程堆处理SSL,图片压缩和缓存,意味着我们很很快判断我们客户的SSL私钥没有泄漏。

然而,内存空间的泄漏包含了敏感信息。泄漏的信息中明显的一个是用于在Cloudflare机器之间安全连接的私钥。

当处理客户网站HTTP请求时,我们的边界机器在机架内,在数据中心内,以及用于记录,缓存和从源Web服务器检索网页的数据中心之间相互通信。

为了响应对互联网公司的监控活动的高度关注,我们决定在2013年加密Cloudflare机器之间的所有连接,以防止这样的攻击,即使机器坐在同一机架。

泄漏的私钥是用于此机器加密的私钥。在Cloudflare内部还有少量的密钥用于认证。


0x06 外部影响和缓存清除

更关心的事实是大量的Cloudflare客户的HTTP请求存在于转储的内存中。这意味着隐私信息泄露了。

这包括HTTP头,POST数据(可能包含密码),API调用的JSON,URI参数,Cookie和用于身份认证的其他敏感信息(例如API密钥和OAuth令牌)。

因为Cloudflare运行大型共享基础架构,因此对易受此问题影响的Cloudflare网站的HTTP请求可能会泄露不相关的其他Cloudflare站点的信息。

另一个问题是,Google(和其他搜索引擎)通过其正常的抓取和缓存过程缓存了一些泄漏的内存。我们想要确保在公开披露问题之前从搜索引擎缓存中清除这些内存,以便第三方无法搜索敏感信息。

我们倾向是尽快得到错误的消息,但我们认为我们有责任确保搜索引擎缓存在公开宣布之前被擦除。

信息安全团队努力在搜索引擎缓存中识别已泄漏内存并清除内存的URI。在Google,Yahoo,Bing和其他人的帮助下,我们发现了770个已被缓存且包含泄漏内存的独特的URI。770个独特的URI涵盖161个唯一域。泄漏的内存已经在搜索引擎的帮助下清除。

我们还进行其他搜索,寻找在像Pastebin这样的网站上可能泄漏的信息,且没有找到任何东西。


0x07 一些课题

新的HTML解析器的工程师一直担心影响我们的服务,他们花了几个小时来验证它不包含安全问题。

不幸的是,这是一个古老的软件且包含一个潜在的安全问题,而这个问题只出现于我们在迁移抛弃它的过程。我们的内部信息安全团队现在正在进行一个项目,以模糊测试旧软件的方式寻找潜在的其他安全问题。


0x08 时间点细节

我们非常感谢Google的同事就此问题与我们联系,并通过其解决方案与我们密切合作。所有这些都没有任何报告,表明外界的各方已经确定了问题或利用它。

所有时间均为UTC时间。

2017-02-18 0011 来自Tavis Ormandy的推特寻求Cloudflare的联系方式

2017-02-18 0032 Cloudflare 收到来自谷歌的bug细节

2017-02-18 0040 多个团队汇集在San Francisco

2017-02-18 0119 全球范围内关闭邮件混淆功能

2017-02-18 0122 London团队加入

2017-02-18 0424 自动HTTPs重写功能关闭

2017-02-18 0722 实现针对cf-html解析器的关闭开关,并全球部署

2017-02-20 2159 SAFE_CHAR 修复部署

2017-02-21 1803 自动HTTPs重写,服务端排除和邮件混淆重启功能


【技术分享】Cloudflare解析器bug导致内存泄漏事件报告
【技术分享】Cloudflare解析器bug导致内存泄漏事件报告
本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/

Viewing all articles
Browse latest Browse all 12749

Latest Images

Trending Articles





Latest Images