Android本地服务漏洞挖掘技术 - 中篇

在Android 8之前，绝大多数Binder服务都属于此类。此时的Android安全还是一片蓝海，且AOSP的代码质量也并不高，因此众多白帽子发现了大量的安全漏洞。

收集信息
通常可以通过两种方式定位到服务和入口函数：
其一，使用系统自带的service list命令，不过由于这个列表中大量的服务都是纯Java服务，如果是想挖掘内存破坏相关漏洞，需要更多关注C/C++服务。

其二，在Android源码中查找onTransact函数，比如可以在cs.android.com中得到如下结果：

漏洞挖掘
除了权限问题以外，大部分漏洞主要是由于服务端未正确校验客户端传入的Parcel数据，导致的各类内存破坏漏洞，如未初始化内存，越界读写，类型混淆等。挖掘方法同样分为人工审计和模糊测试两种，不过根据个人经验来看，模糊测试并不适用，这是因为：
1.Parcel数据除了常规的uint32，uint8等整型以外，还会包含一些特殊类型，如文件句柄，native handle，parcelable对象等，这使得如果采用afl或libfuzzer的变异策略，那么就很难能够触发到深层次的代码路径；
2. 服务的各个接口直接通常存在上下文关系，即要触发B接口，首先需要调用A接口，这也使得传统模糊测试很难做到；
3.某些深层次服务需要通过公开服务的接口获得；
4.服务代码的复杂度较低，人工审计从onTranscat函数跟踪数据流转并不会显得低效；

未初始化内存
我们以CVE-2020-0134为例，代码在栈上声明了state变量，但并没有初始化值，接着调用getOfflineLicenseState函数以为其赋值。

可以看到在某些条件下，getOfflineLicenseState函数会提前返回，并不会对state赋值。

接着代码调用reply->writeInt32(static_cast<DrmPlugin::OfflineLicenseState>(state));，将未初始化的state值返回给客户端，从而导致内存信息泄露。

除了这种直观的漏洞模式以外，在Origin Binder服务中，未初始化内存还有以下几种模式：
1.Parcel::read(void* outData, size_t len)用于从Parcel数据中读取len大小的数据到outData缓冲区中，如果Parcel数据长度小于len，那么函数会返回错误且不会清理outData缓冲区，那么如果上层代码在调用Parcel::read之前未初始化变量，且又未校验Parcel::read返回值时，即很大概率会触发漏洞；
2.某个IBinder对象的成员变量未在构造函数中初始化；

从Android 12开始，默认启用零初始化内存特性，即编译器会自动对原生代码中的堆栈变量进行赋0操作，几乎是从根本上消灭了此类型漏洞，不过根据实测，对于某些大型堆分配，由于性能的考虑，编译器似乎不一定会进行零初始化。

越界读写

我们以CVE-2020-0346为例，在ATTACH_BUFFER这个分支里，代码尝试从parcel数据中反序列化出GraphicBuffer对象。

data.read(*buffer.get())实际上会调用到GraphicBuffer::unflatten函数，当buf[0] == 'BHBB'时候，代码会又调用unflattenBufferHubBuffer函数。

numIntsInToken的最大值可为0xffffffff，由于该服务进程是32位进程，因此const size_t sizeNeeded = static_cast<size_t>(3 + numIntsInToken) * sizeof(int)会产生整数溢出，使得sizeNeeded小于size，从而绕过后面的合法性校验，最终在memcpy处发生越界写漏洞。

随着代码质量的改善和白帽子持之以恒的挖掘，从Android 11开始，此类漏洞也几乎绝迹了。

类型混淆
我们以CVE-2021-1027为例，在SET_TRANSACTION_STATE分支中，代码从parcel数据中反序列化构造了类型为ComposerState的数组state，接着作为参数传递到setTransactionState函数。

在进入setTransactionState函数之前，我们先看看ComposerState的定义。可以看到，ComposerState为一个结构体，其中包含一个类型为layer_state_t的state成员变量，而layer_state_t中又有一个IBinder类型的成员变量surface。

再经过多轮函数调用后，代码会执行到addSurfaceChangesLocked函数，其中关键代码如下：

const sp<const Layer> layer(getLayer(state.surface));

在getLayer函数中，代码通过static_cast关键字强制将IBinder类型的weakHandle转换为Layer::Handle，根据前文的分析，这个surface成员变量的值是由客户端传入的，由于这里的强制转换并没有校验类型，因此可能导致类型混淆。

更多关于此漏洞的信息，大家可以参考谷歌提供的补丁：https://android.googlesource.com/platform/frameworks/native/+/a8c7c54eed57e5a4b56905a4fb00e27e25b1b908。

类型混淆漏洞通常更为隐蔽，也会造成更严重的安全风险。

参考：
1.https://source.android.com/docs/security/bulletin/