CVE-2019-11932 为 Android Gif 库 android-gif-drawable 的 double free 漏洞。具体分析可以参考以下两篇文章：
How a double-free bug in WhatsApp turns to RCE
WhatsApp UAF 漏洞分析（CVE-2019-11932）
我这里列出当时纠结比较久的知识点，想清楚这几个知识点后，再去理解这个漏洞的成因和利用就会变得简单了。

1. jemalloc 与 free

不同操作系统的 malloc 实现也是不同的，比如：
dlmalloc 用于 Android 4.4 及以下
ptmalloc dlmalloc 的改进版，主要用于 ubuntu
jemalloc 用于 firefox 以及 Android 5.0 之后
Scudo 最新的 Android R 将会改用这个堆分配器
这次的运行环境为 Android 9 ，jemalloc 是这次的主角。顺带提一下，在 dlmalloc 中，free 会通过 unlink 操作删除双向链表节点，free 两次可以造成任意地址写。jemalloc 在 free 一个指针两次后，接下来连续 malloc 两个同样大小的内存时，会返回同一个地址，测试代码如下:

#include <stdlib.h>
#include <stdio.h>

int main() {
    char* bytes = (char*)malloc(0x80);
    printf("malloc bytes at %16p\n", bytes);
    char* bytes2 = (char*)malloc(0x80);
    printf("malloc bytes2 at %16p\n", bytes2);
    // free 同一个指针两次
    free(bytes);
    printf("free() once\n");
    free(bytes);
    printf("free() twice\n");
    // 申请同样大小的内存两次
    char* bytes3 = (char*)malloc(0x80);
    printf("malloc bytes3 at %16p\n", bytes3);
    char* bytes4 = (char*)malloc(0x80);
    printf("malloc bytes4 at %16p\n", bytes4);
}

手机上运行结果：

$ ./doublef                                                                                 
malloc bytes at       0xf6393000
malloc bytes2 at       0xf6393080
free() once
free() twice
malloc bytes3 at       0xf6393000 <- 地址一样
malloc bytes4 at       0xf6393000 <- 地址一样

可以看到，两次 malloc 返回了同一个内存地址，而这个漏洞正式通过这种方式，让申请的内存空间与 gif 库中关键的结构体 GifInfo 大小一致，这样申请的内存地址实际就为 GifInfo 的内存地址。

2. realloc 与 free

这个漏洞并不是在使用 free 释放内存时产生的问题，而是 realloc。realloc 的函数原型如下：
void *realloc(void *ptr, size_t size);
当第二个参数 size 为 0 时，就会去 free 第一个参数 ptr，测试代码如下:

#include <stdlib.h>
#include <stdio.h>

int main() {
    char* bytes = (char*)malloc(0x80);
    printf("malloc bytes at %16p\n", bytes);
    char* ptr = realloc(bytes, 0x80);
    printf("realloc 0x80, ptr at %16p\n", ptr);
    // realloc 指针两次
    char* ptr2 = realloc(ptr, 0);
    printf("realloc 0 once, ptr2 at %16p\n", ptr2);
    char* ptr3 = realloc(ptr, 0);
    printf("realloc 0 twice, ptr3 at %16p\n", ptr3);
    // 申请内存两次，看看结果
    char* bytes3 = (char*)malloc(0x80);
    printf("malloc bytes3 at %16p\n", bytes3);
    char* bytes4 = (char*)malloc(0x80);
    printf("malloc bytes4 at %16p\n", bytes4);
}

可以看到，已经产生 double free 的问题：

./realloc                                                                                   
malloc bytes at       0xed313000
realloc 0x80, ptr at       0xed313000
realloc 0 once, ptr2 at              0x0
realloc 0 twice, ptr3 at              0x0
malloc bytes3 at       0xed313000 <- 地址一样
malloc bytes4 at       0xed313000 <- 地址一样

3. 漏洞成因简析：

gif 是由多个画面帧组成，展示一个 gif 文件的方式主要有两种: 1. 把所有帧都加载到内存中，然后逐帧渲染;2. 申请一片共用内存空间，每次只加载一帧到这片内存，之后的帧需要更大的空间，再一点点扩大。android-gif-drawable 选择的就是第二种方式，这样更节约内存。在 DDGifSlurp 函数中对每个 gif 帧进行解析，存在漏洞的代码如下：

void DDGifSlurp(GifInfo *info, bool decode, bool exitAfterFrame) {
......
    do {
            ......
                if (decode) {
                    const int_fast32_t widthOverflow = gifFilePtr->Image.Width - info->originalWidth;
                    const int_fast32_t heightOverflow = gifFilePtr->Image.Height - info->originalHeight;
                    const uint_fast32_t newRasterSize = gifFilePtr->Image.Width * gifFilePtr->Image.Height;
                    // 判断不严谨的地方
                    if (newRasterSize > info->rasterSize || widthOverflow > 0 || heightOverflow > 0) {
                        // 这里调用 realloc，造成 double free
                        void *tmpRasterBits = reallocarray(info->rasterBits, newRasterSize, sizeof(GifPixelType));
                        if (tmpRasterBits == NULL) {
                            gifFilePtr->Error = D_GIF_ERR_NOT_ENOUGH_MEM;
                            break;
                        }
                        info->rasterBits = tmpRasterBits;
                        info->rasterSize = newRasterSize;
                    }
                    ......
        }
    } while (RecordType != TERMINATE_RECORD_TYPE);

    info->rewindFunction(info);
}

info->rasterBits 这个指针就是我们刚刚讲过的共用内存空间。每次解析一个gif帧，都会执行这一段代码，由于判断不够严谨，我们可以通过控制使 newRasterSize 的大小为0，导致 info->rasterBits 被 realloc 两次，触发 double free。

4. 漏洞利用简述：

具体的利用方式可以参考原作者的文章，我这里大致说一下思路。如果解析同一个 gif 文件两次，就可以达到 free 两次，再 malloc 两次的效果。这里只需要把 malloc 的大小控制为 0xA8，也就是保持和关键结构体 GifInfo 一致，这样申请堆返回的地址实际就为 GifInfo 的地址。之后会把 gif 帧写入这块地址，也就完成对 GifInfo 结构体的覆盖。选择此结构体的原因是因为它含有一个函数指针，如下：

struct GifInfo {
    void (*destructor)(GifInfo *, JNIEnv *);  <- 第一处指针
    GifFileType *gifFilePtr;
    GifWord originalWidth, originalHeight;
    uint_fast16_t sampleSize;
    long long lastFrameRemainder;
    long long nextStartTime;
    uint_fast32_t currentIndex;
    GraphicsControlBlock *controlBlock;
    argb *backupPtr;
    long long startPos;
    unsigned char *rasterBits;
    uint_fast32_t rasterSize;
    char *comment;
    uint_fast16_t loopCount;
    uint_fast16_t currentLoop;
    RewindFunc rewindFunction;   <- 第二处指针
    jfloat speedFactor;
    uint32_t stride;
    jlong sourceLength;
    bool isOpaque;
    void *frameBufferDescriptor;
};

在 gif 文件解析完毕后会调用 rewindFunction 函数，通过对这个函数地址的覆盖，达到控制 PC 指针的目的，可以看看文章 3. 漏洞成因简析 里的代码：

void DDGifSlurp(GifInfo *info, bool decode, bool exitAfterFrame) {
......
    do {
        ......
    } while (RecordType != TERMINATE_RECORD_TYPE);
    info->rewindFunction(info); <- 最终函数调用
}

CVE-2019-11932 关键点简析

CVE-2019-11932 关键点简析

1. jemalloc 与 free

2. realloc 与 free

3. 漏洞成因简析：

4. 漏洞利用简述：