没羽@阿里移动安全，更多安全类技术干货，请访问阿里聚安全博客
这是Android mediaserver的提权漏洞，利用CVE-2014-7920和CVE-2014-7921实现提权，从0权限提到media权限，其中CVE-2014-7921影响Android 4.0.3及以后的版本，CVE-2014-7920影响Android 2.2及以后的版本。Google直到Android5.1才修复这2个漏洞。该漏洞[1]披露过程如下：
2016年1月24日漏洞作者发布了漏洞分析及exploit[2]，拿到exploit后在几个Android版本上均没能运行成功，遂分析原因，学习漏洞利用思路。记录如下，欢迎大家交流学习。
不熟悉Android Binder的同学，请自行网上搜索学习资料，下面直接分析漏洞。
0x1漏洞成因
前文提到这2个漏洞出在mediaserver，mediaserver在main_mediaserver.cpp[3]实现，其main()函数中初始化了2个service：
一个是AudioFlinger[4]，service name为“media.audio_flinger”；另一个是AudioPolicyService[5]，service name为“media.audio_policy”。
1.1内存写漏洞
内存写漏洞产生在“media.audio_policy”中，接口类为IAudioPolicyService[6][7]，其中startOutput()接口存在递增的内存写漏洞，stopOutput()接口存在递减的内存写漏洞。
startOutput()接口定义为：
startOutput(audio_io_handle_t output, audio_stream_type_t stream, int session = 0)
stopOutput ()接口定义为：
stopOutput(audio_io_handle_t output, audio_stream_type_t stream, int session = 0)
1）startOutput的递增写漏洞
熟悉Android Binder的同学都知道，该接口的native类为BnAudioPolicyService[8]，当客户端请求“START_OUTPUT”code即startOutput()接口时，BnAudioPolicyService::onTransact()收到请求，然后执行下面的代码：
继续调用AudioPolicyService ::startOutput()[9]方法：
mpAudioPolicy->start_output(mpAudioPolicy, output, stream, session);
mpAudioPolicy为audio_policy类型，audio_policy:: start_output()在audio_policy_hal.cpp中被定义为ap_start_output()，该方法调用：
lap->apm->startOutput()由AudioPolicyManagerBase:: startOutput()方法实现，该方法调用：
我们来看AudioOutputDescriptor:: changeRefCount()[10]方法的代码：
当2个if语句都为假时，mRefCount[stream] += delta;语句将被执行。
此时如果索引stream可被控制，那么mRefCount内存的相对偏移内存将可被修改为加delta。恰巧stream为接口参数之一，也没校验，在AudioPolicyManagerBase:: startOutput()中传入的delta为1 ，也就是说这里存在一个递增1的内存写漏洞。这个内存写漏洞的产生需要满足以下条件：
- isDuplicated()为False：幸运的是默认情况大部分output不是duplicated的。
- (delta + (int)mRefCount[stream]) < 0：由于这个判断条件，mRefCount[stream]<0x7FFFFFFF时才会为False，这就限制了这个内存写漏洞，只能对内存内容小于0x7FFFFFFF的内存值进行递增。
2）stopOutput的递减写漏洞
stopOutput()接口类似于startOutput()接口，我们直接看AudioPolicyManagerBase::stopOutput()方法，该方法调用的是：
outputDesc->changeRefCount(stream, -1);
与startOutput()接口类似，也存在相同的写限制，不同的是这递减1的内存写漏洞。
1.2内存读漏洞
内存写漏洞也产生在“media.audio_policy”中，问题出在isStreamActive()接口。该接口定义为：
bool isStreamActive(audio_stream_type_t stream, uint32_t inPastMs)
类似于startOutput()接口，该接口调用了AudioPolicyManagerBase::isStreamActive()方法，该方法调用：
即AudioOutputDescriptor::isStreamActive()方法，该方法代码为：
如果根据isStreamActive() 返回值判断mRefCount[stream]是否为0，需要满足2个条件：
- mRefCount[stream] != 0；
- ns2ms(sysTime - mStopTime[stream]) > inPastMs：
sysTime - mStopTime[stream]为时间差值，为正值，当inPastMs>=0x80000000时，该不等式成立。
所以可以通过控制stream和inPastMs的值判断mRefCount内存相对偏移的值是否为0。
0x2利用之前
2.1利用技巧小结
1）利用内存读，模糊匹配audio_hw_device对象
audio_hw_device这个结构包含了audio硬件设备函数指针，在“media.audio_policy”和“media.audio_flinger” service提供的接口中会被调用，这有利于写exploit。audio_hw_device结构定义如下：
[图片来自原文]
分析发现audio_hw_device对象中reserved和function_ptrs-> get_supported_devices为0，其它字段为非0。该结构用0和非0的形式可表示为：
前面提到可以通过isStreamActive()接口判断内存值是否为非0，这样结合audio_hw_device结构的特征在内存中搜索，恰巧在mRefCount的上下内存区域中可以搜索到audio_hw_device对象。
2）