安全路透社
当前位置:安全路透社 > 安全客 > 正文

【技术分享】分析Firefox的shared array buffer的UAF漏洞利用


0x00 前言


本文探讨了在结构化克隆算法处理shared array buffer时发生的引用泄漏的问题。同时缺少溢出检查,能被利用来执行任意代码。

分为下面几个部分:

背景,漏洞,利用,总结

我们的漏洞利用的目标是linux平台的Firefox Beta 53。请注意发布版本不受这个bug的影响,因为由于这个bug,shared array buffer从Firefox 52开始被禁用了,在Firefox53中默认禁用。完整的漏洞利用代码在这里。


0x01 背景


这个漏洞和利用需要对于结构化克隆算法和shared array buffer有基本的理解,这些将在本节介绍。

1. 结构化克隆算法

Mozilla开发者文档描述:

SCA用于Spidermonkey-internal序列化以便在不同的上下文传递对象。与json相反,它能够解决循环引用。在浏览器中,postMessage()使用序列化和反序列化的功能:

postMessage()函数在下面两种场景使用;

1. 通过window.postMessage()通信时

2. 和web workers通信时,其是并行执行JavaScript代码的捷径。

一个worker的简单流程如下:

相应的worker脚本worker_script.js能通过注册一个onmessage监听器接收obj:

在不同的窗口通信的过程是类似的。在这些情况中,接收脚本执行于不同的全局上下文中,并且无法访问发送者上下文的对象。因此对象需要传递并且在接收脚本的上下文中重新创建。为了实现这个,SCA将在发送者的上下文中序列化obj,并在接收者的上下文中反序列化,从而创建了个拷贝。

SCA的代码能在js/src/vm/StructuredClone.cpp。两个主要的结构定义:JSStructuredCloneReader和JSStructuredCloneWriter。JSStructuredCloneReader在接收线程上下文处理反序列化对象,JSStructuredCloneWriter在发送者线程上下文中处理序列化对象。处理序列化对象的主要函数是JSStructuredCloneWriter::startWrite():

根据对象的类型,如果是原始类型直接序列化,或者基于对象类型调用函数进一步序列化。这些函数确保了任何属性或者数组元素被递归序列化了。这种情况下当obj是一个SharedArrayBufferObject并且函数执行最终会调用JSStructuredCloneWriter::writeSharedArrayBuffer()。

最后,如果提供的既不是原始类型也不是序列化的对象,它将抛出错误。反序列化使用相同方式,它将序列化作为输入、创建新的对象并为他们分配内存。

2. Shared array buffer

Shared array buffer提供了一种方式来创建共享内存,其能跨上下文传递。他们通过SharedArrayBufferObjectC++类实现,其继承于NativeObject,是表示大部分JavaScript对象的基类。下面是抽象描述(如果你看源代码,你将看见它不像这个这么定义明确,但是这将帮助你理解下文描述的内存布局):

Rawbuf是一个SharedArrayRawBuffer对象的指针,其存储底层的内存缓冲区。当通过postMessage()发送时,SharedArrayBufferObjects将在接收者上下文中重新创建新的对象。另外,SharedArrayRawBuffers在不同上下文之间共享。因此SharedArrayBufferObject的单一拷贝有他们的rawbuf属性指向相同的SharedArrayRawBuffer对象。为了内存管理,SharedArrayRawBuffer保存了一个引用计数器refcount_:

引用计数器refcount_记录了有多少SharedArrayBufferObjects的引用。当序列化一个SharedArrayBufferObject时,在JSStructuredCloneWriter::writeSharedArrayBuffer()它会递增,并且在SharedArrayBufferObject终结中递减:

在反序列化时在JSStructeredCloneWriter::writeSharedArrayBuffer调用这个函数:

代码简单的递增了refcount_,并且SharedArrayRawBuffer::addReference()没有验证它溢出了并变成了0。回顾下refcount_,被定义成uint32_t整型,意味着上面的代码需要触发2^32次才能溢出。在这里的主要问题是每次调用postMessage()将创建一个SharedArrayBufferObject的拷贝,从而分配0x20字节的内存。Firefox目前堆的限制是4GB,溢出需要128G,使得不可能被利用。

2. 在SCA中的引用泄漏

然而不幸的是,有另一个bug使得我们能绕过内存限制。回顾下postMessage()首先序列化,然后反序列化对象。在反序列化过程中创建对象的拷贝,但是refcount_在序列化期间已经递增了。如果postMessage()在序列化SharedArrayBufferObject之后并在反序列化之前失败,将不创建SharedArrayBufferObject的拷贝,但是refcount_能递增。

看下序列化,有很简单的方式使其失败:

如果被序列化的对象既不是原始类型也不是SCA支持的对象,序列化将抛出一个JS_SCERR_UNSUPPORTED_TYPE的错误,将不会发生反序列化(包括内存分配)。下面是简单的PoC,能递增refcount_但不拷贝SharedArrayBuffer:

一个数组包含一个SharedArrayBuffer和一个序列化的函数。SCA首先序列化数组,然后递归序列化SharedArrayBuffer(从而递增它的原始缓冲区的refcount_),最终是函数。然而,函数序列化不支持,将抛出错误,不允许创建对象拷贝的反序列化过程。现在refcount_是2,但是只要一个SharedArrayBuffer指向原始缓冲区。使用这个引用泄漏refcount_能不分配任何内存实现溢出。


0x03 利用


虽然内存限制解决了,但是触发bug需要调用2^32次postMessage()。在现代机器上将要花几个小时执行。为了一个合理的执行时间,bug需要更快的触发。

1. 提高性能

简单的方法是每次调用postMessage()序列化多个sab:

不幸的是,SCA支持反向引用,将不会增长refcount_超过1,而是作为第一个的反向引用。因此sab的拷贝是需要的。实际上,他们也能使用postMessage()创建:

一个数组包含一个sab,被发送给脚本自身,并且当被接收时,被添加到存在的拷贝数组中。现在在拷贝中有两种不同的对象指向相同的SharedArrayRawBuffer。通过重复拷贝拷贝的数组,我们能获得大量的拷贝。在我们的漏洞利用中,我们创建了0x10000个拷贝(只需要16次调用postMessage())。然后我们使用这些拷贝完成引用泄漏,使得调用postMessage的次数达到2^32/0x10000=65536。

进一步的性能提高能通过多个web workers充分利用所有的CPU核心并行利用引用泄漏。每个worker接收一个0x10000个shared array buffer的拷贝,然后在一个循环中执行引用泄漏:

一旦执行了需要的次数,将报告给主脚本已完成你。如果所有的worker已经完成,refcount_将溢出,保存值为1.通过删除一个sab,refcount_将变为0,共享原始缓冲区将在下个垃圾回收的时候被释放。在漏洞利用中,一个SharedArrayBufferObject被垃圾回收将继而调用dropReference()。这将影响将引用计数置为0,将触发原始缓冲区的释放:

Do_gc()的一种实现在这里。

此时,SharedArrayRawBuffer被释放了,但是引用还一直在sab中,允许对释放的内存读写访问,导致UAF利用。

2. 将UAF变为读写原语

因为我们有了释放的内存的引用,我们能分配大量的对象以便在内存中分配目标对象给我们的引用。分配器通过mmap请求更多的内存,将返回SharedArrayRawBuffer的munmaped的内存。为了将这变为ArrayBuffer对象的任意读写原语。这些对象包含真实数组内容的内存区域的一个指针。如果一个ArrayBuffer分配在之前释放的内存中,指针将被覆盖指向我们想要的任意内存。

为了做到这个,我们分配0x60个ArrayBuffer。这是底层缓冲区的最大值,将在ArrayBuffer头后直接内敛存储。将每个都标记0x13371337值,然后在第一次发生时搜索那个值,我们能找到ArrayBuffer的位置:

此时,一些缓冲区应该分配在之前释放的SharedArrayRawBuffer内存中。使用那个引用我们搜索0x13371337。一旦找到,我们用另一个值0x13381338标记并保存偏移:

我们遍历所有分配的ArrayBuffer,搜索0x13381338以便找到确切的ArrayBuffer:

最后buffers[ptr_access_idx]是我们能控制(通过加减一些偏移修改sab_view[ptr_overwrite_idx])的ArrayBuffer的内存。

回顾下数组内容位于头后面,意味着头开始于sab_view[ptr_overwrite_idx-16]。指向数组缓冲区的指针能通过写sab_view[ptr_overwrite_idx-8] 和 sab_view[ptr_overwrite_idx-7]来覆盖(写64位的指针为两个32位的值)。一旦指针被覆盖了,buffers[ptr_access_idx][0]允许读写被指定位置的32位的值。

3. 实现任意代码执行

一旦能任意读写内存,我们需要一种控制RIP的方法。因为libxul.so包含了大部分的浏览器的代码,包括Spidermonkey(没有使用全部的RELRO编译),全局偏移表(GOT)能被覆盖用来改变代码执行。

首先,我们需要泄漏libxul.so的位置。我们简单的泄漏任意原生函数(如Data.now())的指针。函数内部使用JSFunction对象表示,并存储了原生实现的地址。为了泄漏那个指针,函数被设置为ArrayBuffer(能读写内存)的一个属性。接着一串指针,原生指向libxul.so的指针能被泄漏。我们不详细讨论对象属性的内存组织,因为在Phrack paper中有完美的描述。。现在我们有了libxul.so的Date.now()的地址,我们能硬编码Firefox beta53中的libxul.so的偏移,以便得到GOT的地址。

最后,我们使用system()(同样使用libxul.so泄漏)覆盖GOT中的一个函数。在利用中,我们使用Uint8Array.copyWithin()继而针对我们控制的字符串调用memmove,因此覆盖memmove@GOT将执行system:

这个技术是受到saelo的启发“exploit for the feuerfuchs challenge from the 33C3 CTF. “。

运行利用,弹出计算器:


0x04 总结


这个溢出的修复很快,在commit d4b0fe7948中实现了。代码添加了捕获溢出,并检测到报错。在commit c86b9cb593中修复了引用泄漏。

这个bug的触发原本估计要4个小时才能溢出。然而,使用多个worker能加快进程,在8核机器上只要大约6-7分钟能稳定的弹出计算器。完整的利用能在这找到。


原文链接:https://phoenhex.re/2017-06-21/firefox-structuredclone-refleak

未经允许不得转载:安全路透社 » 【技术分享】分析Firefox的shared array buffer的UAF漏洞利用

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册