Android libcutils库中整数溢出导致的堆破坏漏洞的发现与利用

作者：龚广(@oldfresher)

1.漏洞代码的位置

本文次涉及的漏洞位于创建native handle的函数，如下代码片段所示[1],每一个GraphicBuffer对象都包含一个native handle 的指针，通过native handle，GraphicBuffer可以跨进程共享图像系统所需的内存。

native_handle_t* native_handle_create(int numFds, int numInts) {  native_handle_t* h = malloc(    sizeof(native_handle_t) + sizeof(int)*(numFds+numInts));//---------->整数溢出位置   h->version = sizeof(native_handle_t);  h->numFds = numFds;  h->numInts = numInts;  return h; } 

status_t GraphicBuffer::unflatten(  void const*& buffer, size_t& size, int const*& fds, size_t& count) { …  native_handle* h = native_handle_create(numFds, numInts);  memcpy(h->data,   fds,     numFds*sizeof(int));   // ------------>这里会导致堆破坏  memcpy(h->data + numFds, &buf[10], numInts*sizeof(int)); … } 

当传入的numFds和numInts被恶意构造后，h分配的缓冲区小于预期的大小，后续的memcpy会导致堆破坏。只影响Lollipop以上版本的函数如下，这个函数在所有的Android版本中都存在，不过只在Android 5.0以上才会被调用，其它版本不能触发。

native_handle* Parcel::readNativeHandle() const { ...  native_handle* h = native_handle_create(numFds, numInts);  for (int i=0 ; err==NO_ERROR && i<numFds ; i++) {   h->data[i] = dup(readFileDescriptor());   if (h->data[i] < 0) err = BAD_VALUE;  }  err = read(h->data + numFds, sizeof(int)*numInts);   ----------------->堆破坏位置 ...  return h; } 

read 函数类似与memcpy,后从Parcel中读取 sizeof ( int )* numInts 到h-> data + numFds ，因为分配给h的堆内存小于预期，所以read会导致堆破坏. 因为unflatten堆破坏时破坏的大小不好控制，我将使用这个函数来介绍此漏洞的利用。这个漏洞能被利用来提权的关键是numFds,numInts以及拷贝到native handle中的内容都可以被跨进程控制，从而使得低权限的进程可以注入代码到高权限进程而达到提权。

2.利用方法

如果A进程可以获得B进程的带IGraphicProducer接口的binder代理对象，那么A进程可以通过跨进程的binder调用利用此漏洞可获得B进程的权限。成功利用的关键函数是IGraphicProducer的setSidebandStream[4]函数。

case SET_SIDEBAND_STREAM: {  CHECK_INTERFACE(IGraphicBufferProducer, data, reply);  sp<NativeHandle> stream;  if (data.readInt32()) {   stream = NativeHandle::create(data.readNativeHandle(), true);    }  status_t result = setSidebandStream(stream);  reply->writeInt32(result);  return NO_ERROR; } break; 

上述代码描述了 BnGraphicBufferProducer 如何处理其它进程发来的 SET_SIDEBAND_STREAM 事件，从代码中可以看到，从其他进程传来的parcel中的数据没有做任何检查，直接传给了 readNativeHandle ，从而导致numFds,numInts和其它被拷贝到所分配的堆内存的数据可以被发起binder调用的进程任意构造，使得利用成为可能。

下图是攻击场景图，低权限进程通过binder调用，利用此漏洞可获得高权限进程的权限：

Figure1. 攻击场景

3.如何获得system_server的权限

Figure2. SELinux domains

如上图所示，虽然surfaceflinger也是已系统用户运行的，但是因为SElinux的存在surfaceflinger是运行在u:r:surfaceflinger:s0域中，而此域除了访问图形设备外，其它的权限很少，这是为什么已经获得system用户权限后还要继续注入system_server的原因。system_server可以看在是Android的“内核“，可以访问的资源很多，如果把root权限比作神的，能注入system_server应该算是“半神“。下图描述了我们通过调用哪些接口，一步步的获得system_server的权限。

Figure 3. 三步走获得system_server权限

如上图所示，一个普通应用程序通过调用IMediaRecord的querySurfaceMediaSource函数能够获得mediaserver进程导出的IGraphicProducer，从而普通应用程序可以注入代码到mediaserver(详情见后续章节），因为mediaserver有ACCESS_SURFACE_FLINGER的权限，所以注入到mediaserver中的代码可以通过调用ISurfaceComposer的createSurface函数获得surfaceflinger导出的IGraphicProducer接口，然后同过setSidebandStream可以拿下surfaceflinger。surfaceflinger 通过调用IWindowsManager的screenShotApplication 触发system_server 调用 ISurfaceComposer captureScreen , 这个binder调用会将system_server 导出的一个 IGraphicProducer作为参数传给surfaceflinger,从而surfaceflinger可以获得system_server的IGraphicProducer接口，从而拿下system_server.

4.mediaserver注入详解

我们需要经过三步才能获得system_server的权限，但是由于NX,ASLR,SELinux，je_malloc和多个binder 服务线程相结合带来的障碍，每一步都很复杂，本节将以mediaserver为例详细介绍如何通过libutils的漏洞注入mediaserver. 简单来说，需要经过5步才能成功。

1)控制binder服务线程

当使用je_malloc时，每一个线程都与一个特定的arena关联，不同的线程从堆上分配内存时将使用不同的arena,每个arena又关联一个或多个chunk,故分配给不同的线程的小块堆内存将使用不同的chunk, Android中每个chunk的大小是1MB。图4展示了je_malloc堆的离散性。

Figure 4.je_malloc 中堆的分布

binder 服务线程处理binder代理发起的binder调用，服务线程的调用随着并行的binder调用的增加而增多，一般都有一个最大值。就mediaserver而言，进程刚启动时binder服务线程的数目是4，最多可以增加到17个,图5显示了mediaserver中binder服务线程最多时的状况.

Figure 5.mediaserver 的服务线程

当一个binder调用到达mediaserver时，系统会随机的选择一个服务线程来处理这个调用，而我们知道，不同的线程分配的堆内存位于不同的chunk中，所以，如果所有的线程都处于active状态时，通过binder调用分配的内存可能位于不同的chunk中，从而使得通过binder调用进行堆风水基本不可能。解决方法是只让一个binder服务线程处于active状态，挂起其余的所有binder服务线程，从而多次binder调用所分配的堆内存可以位于同一个chunk中。

IGraphicProducer接口可以通过attachBuffer函数将一个GraphicBuffer加入到bufferqueue.而每一个bufferqueue只能存储特定数量的GraphicBuffer, Lollipop中是64个，当bufferqueue中的GraphicBuffer已经达到64个后，如果还调用attachBuffer,处理attachBuffer的binder服务线程将会挂起，一直等到有bufferqueue中GraphicBuffer小于64为止，通过这种方法，可以挂起mediaserver中的16个binder线程，剩下的那个将服务我们发起的攻击性binder调用。

2) 泄漏堆的内容

因为ASLR的存在，要想利用次漏洞，我们需要从mediaserver中泄漏地址信息，在je_malloc中，同一个线程中分配的相同大小的小块内存将占据相邻的region(je_malloc中有对region的定义)，与dl_malloc不用的是，相邻region之间没有任何元数据。我们可以通过attachBuffer在mediaserver的堆上生成很多的native handle, native handle的结构如下，native handle 的大小由numFds和numInts决定，正常的native handle中numFds=2，numInts=12,分配的堆的大小是80。

我们先通过attachBuffer分配多个正常的native handle，然后通过setSidebandStream构造一个畸形的native handle(numFds=-35 ,numInt=64),readNativeHandle会将相邻的一个正常的native handle的numInts修改为较大的值, 当通过requestBuffer请求返回被修改的native handle 时，堆内容将会被泄漏。

Figure 6. 从mediaserver中泄漏堆内容

3)泄漏栈的基地址

因为NX的存在，我们需要使用ROP来绕过NX，而ROP需要能控制栈内容，所有我们需要知道栈的位置。知道了栈的位置，我们可以通过此漏洞重写栈，从而可以将堆破坏漏洞转化为栈重写从而执行ROP。

我们已经知道如何泄漏堆的内容，所以我们可以在堆上搜索特定的数据结构来泄漏栈的基址。被搜索的关键数据结构为pthread_internal_t.

上述地址范围是一个pthread_internal_t的内容，从彩色高亮的区域我们可以得知这个结构描述的线程的一些属性，tid 是 0xb58, pid 是 0xa53, 线程的栈的基址在0xae7df000. 因为这个结构中包含了线程的栈的基址，我们可以在泄漏的堆内存中搜索这样的结构来得到栈的基址。搜索的特征为栈大小(0x000fe000) 和guard_size(0x00001000)。每一个通过pthread_create创建出来的binder服务线程都会分配一个pthread_internal_t的对象，一般来说，新创建出来的线程会被分配一个较大的tid. 因为mediaserver中除了binder服务线程外还有别的线程，别的线程的状态不好控制，我们需要找到一个binder server线程对应的pthread_internal_t, 我们应该还记得binder server线程可以被动态触发创建的，这样就使得binder线程可以有一个较大的tid，我们可以搜索多个pthread_internal_t的对象，然后选择其中tid最大的一个，则有很大的概率这个线程是处于挂起状态的binder服务线程，处于挂起状态的binder服务线程的调用栈是固定的，如图7所示，我们可以通过重写它的返回地址来触发ROP的执行.

Figure 7. 处于阻塞状态的binder服务线程

4)泄漏共享库(so)基址

我们需要模块的基值来来构造ROP。为了有更多模块来搜索ROP，我们可能需要泄漏多个模块基址。泄漏libui.so的基址很容易。唯一需要做的是通过在泄漏的堆内存中搜索GraphicBuffer对象，GraphicBuffer对象包含一个 android_native_base_的子结构。这个结构中的incRef和decRef是指向libui.so中相应函数的函数指针。找到这个结构就能计算出libui.so的基址。GraphicBuffer具有特定特征，很容易搜索到。

为了比较方便的写shellcode，最好是能找到libc.so的基址，这样我们可以在shellcode中调用libc的函数，libui.so的GOT中有memcpy的地址，memcpy为libc.so中的函数，如果能泄漏libui.so的GOT表我们就能获得libc.so的基地址。由于这个漏洞的局限性，要泄漏libui.so的GOT并不容易。从前面章节得知，我们可以通过修改numFds和numInts来泄漏堆内存，但这中方法只能泄漏连续的内存，因为泄漏内存的的逻辑是memcpy,如果泄漏的地址空间中有没有被映射的内存，则memcpy直接会发生段错误。令一个限制是binder调用只能返回小于1MB的内存。堆内存和libui.so直接一般情况都存在没有映射的页面，而且两者直接的距离也超过了1MB,所以不能通过简单的修改numFds和numInts来泄漏libui.so的GOT。因为GraphicBuffer包含了native handle的指针，我们可以修改这个指针，使其指向一个伪造的native handle对象，则可以泄漏地址空间中紧跟这个native handle对象后的内存内容。泄漏的大小由伪造的numFds和numInts决定。通过这样的方法，我们同样可以泄漏libc.so的GOT,从而得到dlopen和dlsym的地址，有了这两个函数，我们可以直接用高级语言写shellcode.

5)控制je_malloc下次分配内存的位置

通过构造特殊的numFds和numInts，我们只能写紧临native handle的连续内存，因为je_malloc中栈和堆的地址空间通常不是相邻的。所有我们需要找到一个重写栈的方法，也就是将这个漏洞转换为一个任意地址写的漏洞。我们可以通过修改je_malloc中的tcache的指针表来实现. 当使用je_malloc并激活了tcache机制时，每一个线程都会为分配的小对象维护一个cache,这个cache存储在一个叫tcache_t的结构中。对每一种特定大小区间的对象，tcache_t都为其维护了一个指针表。在Android的je_malloc实现中，共有31大小区间。见下示gdb输出

5.绕过SELinux加载so

因为SELinux的存在，普通应用创建的文件一般被标记为app_data_file 或 apk_data_file. mediaserver 没有权限执行带这些标签的文件. 所以不能在shellcode里使用system或dlopen执行普通应用提供的执行文件。幸运的是，mediaserver 有execmem 权限。

allow mediaserver self:process execmem;             ————>SELinux policy

我们可以通过mprotect修改匿名内存为可执行(这在surfaceflinger中是不行的)，从而能执行shellcode. 然后在shellcode里实现从内存中加载so的机制（详见PoC)，从而带 app_data_file 或 apk_data_file的文件可以以二进制流的形式通过漏洞传给mediaserver，然后通过load so from memroy模块加载执行。

Figure 8. 加载共享库流程

因为mediaserver在Lollipop下没有执行/system/bin/sh的权限，我通过注入busybox到mediaserver来执行shell命令，如果利用成功，可以得到一个从mediaserver反弹的shell（如图9）,细节请见PoC.

Figure 9. 带mediaserver权限的shell

6.溢出surfaceflinger和system_server

[引用]