博客地址：https://jinyu00.github.io/

接下来要学习安卓的漏洞利用相关的知识了，网上搜了搜，有大神推荐 stagefright 系列的漏洞。于是开干，本文分析的是 google 的 exploit. 本文介绍的漏洞是 CVE-2015-3864 , 在 google的博客上也有对该 exploit 的研究。

对于堆喷射部分我非常疑惑，请比较忙的大佬们看看最后堆喷射部分，希望可以给予解答

我之前下载下来了:

pdf版本 的链接：在这里

exploit 的链接： https://www.exploit-db.com/exploits/38226/

分析环境：

这个漏洞是一个文件格式相关漏洞，是由 mediaserver 在处理 MPEG4 文件时所产生的漏洞，漏洞的代码位于 libstagefright.so 这个库里面。

要理解并且利用 文件格式 类漏洞，我们就必须要非常清楚的了解目标文件的具体格式规范。

先来一张总体的格式图

mp4 文件由 box 组成，图中那些 free, stsc等都是box, box 里也可以包含 box ,这种 box 就叫 containerbox .

每个 box 前四个字节为 box 的 size

第二个四字节为 box 的 type，box type 有 ftyp,moov,trak 等等好多种，moov 是 containerbox ,包含 mvhd 、trak 等 box

还有一些要注意的点。

下面来看两个实例。

实例一

实例二

现在我们对该文件的格式已经有了一个大概的了解，这对于漏洞利用来说还不够，接下来我们要去看具体的解析该文件格式的代码是怎么实现的。

解析文件的具体代码位于 MPEG4Extractor.cpp 中的 MPEG4Extractor::parseChunk 函数里面。
该函数中的 chunk 对应的就是 box, 函数最开始先解析 type 和 size .

通过注释和代码，我们知道对于 size 的处理和前面所述是一致的。然后就会根据不同的 chunk_type ,进入不同的逻辑，

如果 box 中还包含 子 box 就会递归调用该函数进行解析。

CVE-2015-3864 漏洞产生的原因是，在处理 tx3g box时，对于获取的 size 字段处理不当，导致分配内存时出现整数溢出，进而造成了堆溢出。

size 为之前所解析的所有 tx3g box 的长度总和。chunk_size 为当前要处理的 tx3g box 的长度。然后 size + chunk_size 计算要分配的内存大小。 chunk_size 是 uint64_t 类型的，chunk_size 我们在文件格式中我们所能控制的最大大小为 0xFFFFFFFFFFFFFFFF ( 看 part1 实例二 ) ，也是 64 位，但是我们还有一个 size 为可以控制，这样一相加，就会造成 整数溢出 ， 导致分配小内存。而我们的 数据大小则远远大于分配的内存大小，进而造成堆溢出。

概述

现在我们已经拥有了堆溢出的能力，如果是在 ptmalloc 中，可以修改下一个堆块的元数据来触发 crash ，甚至可能完成漏洞利用。不过从 android 5开始，安卓已经开始使用 jemalloc 作为默认的堆分配器。

在 jemalloc 中，小内存分配采用 regions 进行分配， region 之间是没有 元数据 的 （具体可以去网上搜 jemalloc 的分析的文章），所以 在 ctf 中常见的通过修改 堆块元数据 的漏洞利用方法在这里是没法用了。

不过所有事情都有两面性。region 间是直接相邻的，那我就可以很方便的修改相邻内存块的数据。 如果我们在 tx3g 对应内存块的后面放置一个含有关键数据结构的内存块，比如一个对象，在 含有虚函数 的类的 对象 的 开始4字节（32位下），会存放一个 虚表指针 .

在 对象 调用 虚函数 时会从 虚表指针 指向的位置的 某个偏移（不同函数，偏移不同） 处取到相应的函数指针，然后跳过去执行。

如果我们修改对象的虚表指针，我们就有可能在程序调用虚函数时，控制程序的流程。

一些重要的 chunk_type(box type)

tx3g box

上一节提到，我们可以修改对象的虚表指针，以求能够控制程序的跳转。那我们就需要找到一个能够在解析 box 数据能时分配的对象。

MPEG4DataSource 就是这样一个类。

可以看到该对象继承自 DataSource, 同时还有几个虚函数。

我们可以在ida中看看虚表的构成。

可以看到 readAt 方法在虚表的第7项，也就是虚表偏移 0x1c 处。同时MPEG4DataSource在我这的大小为 0x20 .再看一下漏洞位置的代码。

可以看到如果当前解析的 tx3g box 不是第一个tx3g box（即size>0），会先调用 memcpy , 把之前所有 tx3g box中的数据拷贝到刚刚分配的内存。

如果我们先构造一个 tx3g ，其中包含的数据大于 0x20, 然后在构造一个 tx3g 构造大小使得 size+chunk_size = 0x20, 然后通过 memcpy 就可以覆盖 MPEG4DataSource 的虚表了。exploit 中就是这样干的。

pssh box

看看代码

划线位置说明了 pssh 的结构。

这里先分配 pssh.datalen 大小的内存，然后把 pssh.data 拷贝到刚刚分配的内存。完了之后会把 分配到的 PsshInfo 结构体增加到 类属性值 Vector<PsshInfo> mPssh 中, mPssh 在 MPEG4Extractor::~MPEG4Extractor()中才会被释放。

所以在解析完 MPEG4格式前，通过 pssh 分配的内存会一直在内存中。

avcC box 和 hvcC box
这两个 box 的处理基本一致，以 avcC 为例进行介绍。解析代码如下

首先根据 chunk_data_size 分配 ABuffer 到 buffer，chunk_data_size 在 box 的 size 域指定，注意buffer是一个智能指针，在这里，它会在函数返回时释放。

ABuffer 中是直接调用的 malloc 分配的内存。

接下来读取数据到 buffer->data(), 最后调用 mLastTrack->meta->setData 保存数据到 meta, 在 setData 内部会先释放掉之前的内存，然后分配的内存，存放该数据，此时分配内存的大小还是chunk_data_size, 我们可控。

hvcC 的处理方式基本一样。所以通过这两个 box 我们可以 分配指定大小的内存，并且可以随时释放前面分配的那个内存块 。我们需要使用这个来布局tx3g内存块 和 MPEG4DataSource内存块。

修改对象虚表指针

下面结合exploit 和上一节的那几个关键 box ，分析通过布局内存，使得我们可以修改 MPEG4DataSource 的虚表指针。
为了便于说明，取了 exploit 中的用于 修改对象虚表指针的相关代码进行解析 ( 我调试过程做了部分修改 )

首先看到第7，8行，构造了第一个 tx3g box, 大小为 0x3a8， 后面在触发漏洞时，会先把这部分数据拷贝到分配到的小内存buffer中，然后会溢出到下一个 region 的 MPEG4DataSource内存块。使用 cyclic 可以在程序 crash 时，计算 buffer 和 MPEG4DataSource 之间的距离。

第 13 行，调用了 memory_leak 函数， 该函数通过使用 pssh 来分配任意大小的内存，在这里分配的是 alloc_size ，即 0x20. 因为MPEG4DataSource 的大小为 0x20 ,就保证内存的分配会在同一个 run 中分配。这些这样这里分配了 4 个 0x20 的内存块，我认为是用来清理之前可能使用内存时，产生的内存碎片，确保后面内存分配按照我们的顺序进行分配。此时内存关系

第 17 到 25 行，清理内存后,开始分配 avcC 和 hvcC, 大小也是 0x20， 然后在第 25 行又进行了内存碎片清理，原因在于我们在分配 avcC 和 hvcC时，会使用到 new ABuffer(chunk_data_size),这个临时的缓冲区，这个会在函数返回时被释放（请看智能指针相关知识）

同时多分配了几个 pssh 确保可以把 avcC 和 hvcC包围在中间。所以现在的内存关系是

然后是 第 29 行， 再次分配 hvcC ,不过这次的大小 为 alloc_size * 2, 触发 hvcC 的释放，而且确保不会占用 刚刚释放的 内存.（jemalloc中 相同大小的内存在同一个run中分配）

接下来构造 stbl 用 MPEG4DataSource 占据刚刚空出来的 内存。

接下来， 第 38 行用同样的手法分配释放 avcC

然后使用整数溢出，计算得到第二个 tx3g 的长度值，使得最后分配到的内存大小为0x20, 用来占据刚刚空闲的 avcC 的 内存块，于是现在的内存布局，就会变成这样。

然后在

就会溢出修改了 MPEG4DataSource 的虚表指针。然后在下面的 readAt 函数调用出会 crash.

我测试时得好几次才能成功一次，估计和内存碎片相关。

可以看到断在了<android::MPEG4Extractor::parseChunk(long+0> ldr r6, [r2, #28],去 ida 里面找到对应的位置。

r2存放的就是虚表指针，可以确定成功修改了 虚函数表指针。

偏移也符合预期。

堆喷射

上面我们已经成功修改了MPEG4DataSource 的虚表指针,并在虚函数调用时触发了 crash .

我们现在能够修改对象的 虚表指针，并且能够触发虚函数调用。我们需要在一个可预测的内存地址精准的布置我们的数据，然后把虚表指针修改到这里，在 exploit 中使用了

来进行堆喷射

heap_spray 函数 就是使用 pssh 来喷射的内存。每次分配 0x100 页，共分配了 0x10 次。 exploit 作者在 博客中写道，这样就可以在可预测的内存地址中定位到特定数据。在这里就是 用于 stack_pivot 的 gadget.

对于这一点，我很疑惑，有大佬可以告诉我为什么可以这样吗？ 或者有没有相关的 paper 来介绍为什么可以在 可预测的地址 精确的布置我们的数据

这个 exploit 写的确实强悍，提示我在进行漏洞利用时，要关注各种可能分配内存的地方，灵活的使用代码中的内存分配，来布局内存。 同时研究一个漏洞要把相关知识给补齐。对于这个漏洞就是 MPEG4 的文件格式和 相关的处理代码了。

一些tips：

使用的一些脚本。

使用 gdbserver attach mediaserver 并转发端口的脚本

gdb 的调试脚本

参考：

https://census-labs.com/media/shadow-infiltrate-2017.pdf

https://googleprojectzero.blogspot.hk/

http://blog.csdn.net/zhuweigangzwg/article/details/17222951

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！