Android bug hunting from finding bugs to getting bounty 2017-06-03

Editor's Notes

• #2: 大家好，我是今天的演讲者温瀚翔，我带来的分享是Android系统漏洞挖掘从入门到挖洞到汇报到拿奖金的整个流程。
• #3: 先做一下自我介绍，我叫温瀚翔，是去年加入C0RE Team的新成员，当前研究方向是AOSP漏洞挖掘与漏洞利用。 再来介绍一下我们团队。C0RE Team成立于2015年中，隶属于360无线安全研究院。主要方向是研究Android与Linux内核安全。团队目标是发现Android以及linux内核的安全问题。发现并提交漏洞，并且能对能够利用的提权漏洞制作root方案，为360超级root提供root技术支撑。。在17年五月份之前我们一共从Google处获得了118个公开的CVE编号。就在上个月中旬，我们收到Google VRP的通知，我们是16年中-17年中的最佳安全研究团队，这个殊荣今年只有一个，给了我们。
• #4: 今天的演讲，主要的目的是为了让大家对Android漏洞挖掘有一个初步的了解，包括常见的漏洞类型，触发路径，以及几个实例。还有就是发现漏洞后该怎么提交，如何获得更多的赏金。内容比较基础实用。
• #5: 首先讲讲当前Android漏洞的概况，经过去年的Android漏洞大挖掘，AOSP漏洞包括攻击面都减少了不少，内核中由于也包含了厂商的驱动问题，所以Google也会认，所以报告的Kernel的漏洞呈上升趋势。这是我们内部统计的17年1月份到5月份的漏洞数量情况。可以看到kernel漏洞数量比AOSP的要多。但是其实AOSP中的漏洞也种类齐全一样不少，下面我们来看看Android中的常见漏洞类型。
• #6: 下面来讲一件Android中的常见漏洞类型，首先是堆/栈溢出。比如这个例子，2017-0541，这是个XMF文件解析时候导致的栈溢出漏洞，可以看到这里面check的是stackpointer这个指针，然后以这个指针的值加一作为索引对数组进行访问了，但是并没有check stack+1的值是不是到达了最大长度。如果+1后到达了的话，就会导致一个栈溢出的问题； 下面这个是整形溢出，构造TrackBase对象的时候传入的参数framecount没有很好的校验，导致buffersize可以被溢出变成一个较小的值，这个溢出后的buffersize后面被用作申请一片很小的memory，那么对这块memory的访问就都会出问题了。 这里提一下，stagefright那一批漏洞后Android给很多解码库以及mediaserver都用clang编译并打开了整形溢出检测的编译选项。所以这样的漏洞在最新版已经被缓解不少。
• #7: 这个漏洞是一个类型混淆漏洞，state是我们能控制的一个向量引用，s中的client对象是一个Ibinder对象的指针，既然是指针，那么就不能随便做类型转换，那么转换之前，检查一下这个指针指向对象的接口声明吧，看上去没毛病。可是看一下，接口声明是一个字符串。我们可以构造一个对象，也去声明满足需求的接口，那么就可以绕过这个检查，使得client指针被强转为另一种不安全的指针的情况了。而被强转后的client指针在之后就会调用到自己的类函数，由于虚表的不对等，就会导致相关问题的出现。这种漏洞在Android中见的不多，但是很有意思。 下面这个漏洞可以说算是最常见的了，空指针引用。这里举的例子是stagefright在歇息MP4文件时候遇见的NPD，如果他直接解析到一个btrt类型的chunk，那么由于mLastTrack是一个空指针，那么对其指向的对象中的变量的访问就是空指针引用了。Google最新的漏洞评定已经也是把NPD大大降级，把系统服务打崩溃的NPD已经不认了。
• #8: 再来看两个类型， 第一个TOCTOU,就是使用时机与检查时机不一致导致的问题。这里看对mCblk中的clientindex与serverindex都做了检查，看上去没问题，但是其实我们是可以通过进程间通信控制mCblk这个对象的，所以控制其值通过check，在使用的时候再修改成为恶意的值就可以了。解决这个问题的关键就是在第一次取到IPC对端值并缓存下来，而不是每一次都去读取。 第二个是缺少权限检查，这是常在Android java层中存在的问题，我们来看看0490这个漏洞。buildConfig是wifiservice下的一个进程间通信后的调用函数。在buildconfig中，传入的URI在解析后直接被调用了删除dropfile。缺少了权限检查。这一类问题往往在Java层多一些，但是native层也有。
• #9: 讲了这么多漏洞类型，这里有几个关于AOSP中漏洞的规律。通过两个方面来讲。 一方面是漏洞源码位置，主要是在系统服务中比如mediaplayerservice，audioflinger，surfaceflinger之类的；框架层的库比如，libstagefright, libmedia, 以及omx相关的库，接下来是第三方或者是跨平台使用的库比如chrome也用的libskia,或者avc,hevc等格式的多媒体文件解析库，再就是芯片厂商为了使用芯片加速绘图以及音视频解码也会使用自己的库，在AOSP源码中高通联发科英伟达都有自己的开源库。 另一个方面是常见的触发的路径，AOSP这边有两条，通过binder，与高权限的进程通信是其一。再就是通过文件，使目标进程进程在文件解析过程中出现问题。
• #10: 这个是我们总结的1月到五月份AOSP漏洞的分布位置，可以看到media还是占了很大一块的份额。因为音视频编解码框架复杂，解码过程复杂，且有时候会涉及到与厂家芯片打交道，所以问题不在少数，我们之前发现的攻击面OMX也是属于media解码中的一个通用接口层。从我们现在漏洞挖掘的收获来看，Media相关的部分由于设计复杂，有时还需要与厂家对接，所以问题很多。
• #11: 讲了这么久AOSP的，这里再讲一讲内核相关的，由于我是做AOSP漏洞挖掘的，所以对内核也只是初学者，如有不当，欢迎大家指正啊。 内核漏洞主要是分为两方面，先讲讲出问题的源码位置。问题源码的位置一般有两类位置，第一是各种子系统中的个问题，比如文件子系统VFS，又或者是网络相关子系统，内存管理子系统等。第二个方面是接触比较多的，也是存在问题数量多的地方，即设备驱动，各大厂商都有实现自己的驱动，而且其驱动的代码也是开源的。由于这部分代码写的人不是Google的员工，所以代码质量也是参差不齐。所以问题并不少。 再讲讲一般的触发路径，与内核通信，一般都是通过系统调用以及与打开的设备做ioctl之类，复杂的地方是打开设备以及调用需要有时序的安排。
• #12: 这是我们总结的一月到五月份内核漏洞的厂商分布情况，英伟达与联发科都有不少的问题。
• #13: 下面将详细讲解两个实例，AOSP与kernel各一个。 在讲AOSP漏洞之前，先跟大家说说binder吧，Binder是Android中采用的主流进程间通信框架，binder通信的底层本质是通过共享同一片物理内存来传递数据。所有的binder调用都是通过把数据封装在parcel里面然后序列化发送给binder驱动，再由binder驱动发送给对端service的。Client为了建立起与其他service的联系，需要通过向systemserver中的service_manager发送请求来得到代理引用的。 再从源码的角度看看binder通信，一般service的逻辑代码在bnxxx类的实现中，请求service的client端代码在bpxxx类的实现中。一般称clinet端为bp端,称service端为bn端。这两个类通实现了同一个接口Ixxx来保证一致性。也就是说你bp端调用了函数a(),那么 bn端在拆包后也会调用函数a()，然后这三个类也继承了相关的父类BpRefbase,Iinterface以及Bbinder,从而实现了利用底层binder框架的通信。所以如果你想找到mediaplayerservice的处理逻辑代码，那么就去找Bnmediaplayerservice的源码就可以。
• #14: 下面来看看这个例子，2015-6620，这个是flanker龚广我们先后发现并报给Google的是一个经典的越界访问的问题可以看到getcodecinfo这个binder call后,在Bn端，先检查了接口名称，然后从parcel中读取了索引index，之后就调用了bn端的getcondecinfo, getcondecinfo的代码实现在BnMediaCodecList的子类MediaCodecList中，所可以看到没有对索引做任何校验就去访问了向量mcodecinfos。itemAt的返回值是以应索作为便宜量计算出的对象的指针。所以回到这个bn端的调用，之后这个对info的调用会去查找所指向对象的虚表，然后找到对应的writetoparcel函数，所以我们就有机会控制这个索引指向到我们堆喷的内存，从而控制虚表指针，以及尝试控制虚表中的内容，最后控制函数执行流程。 这个是将索引设置为指向没有被映射的memory时候的崩溃日志。
• #15: 下面再来讲一个内核的例子，这个是内核的架构概览，我们要讲漏洞出现在设备驱动中，所以也算是设备控制的的一部分。
• #16: 这个漏洞是一个UAF漏洞，rt5677的这个设备的ioctl处理函数中，当发起的请求是CODEC DSP时，如果model_buf，会先把model_buf释放掉，然后再申请新的内存。之后进行copy_from_user将用户态的数据拷贝过来。 但是对model_buf这个变量的访问并没有锁的保护。首先不同线程间是共享model_buf这个指针的。 所以当我们起很多线程的时候， 就可以发生一个ioctl线程free了model_buf而在model_buf被设成0之前， 另一个线程又申请到了这片memory，准备做别的事情。 这时另一个线程中的ioctl已经执行了copy_from_user，那么此时就会向model_buf所指向的memory拷贝用户态数据。 那么我们就能写坏某些关键数据结构，最终可能造成提权。整个过程难点在于对时序的准确排程，但还是有成功概率的。右下角是对被free的memory进行copy_from_user是的kernel日志。
• #17: 至此我们所有的常见漏洞类型以及相关的例子就都讲完了，大家可以这页作为所以去学习。葵花宝典就是自己理解漏洞点并编写POC。写过一遍之后，Android漏洞挖掘也就入门了。关于漏洞相关的概览和分类就到这里了。下面来讲讲发现漏洞后该怎么做。
• #18: 下面我们来讲讲当发现漏洞后需要做的几件事情，首先如果你是看源码发现的问题，需要构造出一个可以调用到问题代码的有效调用路径。 然后依据这条调用路径制作POC，然后目标进程就crash了 之后的话，对这个漏洞严重性进行评定，源码中的问题可以导致哪些进程崩溃，找出最严重的，以及这种崩溃是不是持久的，即需要重新刷机才能解决。 回答了这些问题之后你就有一个自己的报告了，那么在报告的最后，附上在最新Android版本的设备或者虚拟机上的崩溃日志。 如何过去崩溃日志呢。AOSP的是通过logcat，崩溃日志的tag是大写的DEBUG,内核的话有点杂乱，但是一般就是以找到对应的记录last_kmsg的文件，或者通过bugreport也可以。
• #19: 在提交给Google的报告中，出现的内容，主要有三点，问题的描述以及触发路径，崩溃日志，以及可以复现的可执行poc,最好把源码也附上。 说到这里，提一下Google的漏洞奖励计划，Google当前会给Pixel以及Pixel XL,Pixel C设备中的漏洞提供奖金奖励。 最后一点，做这一切的速度一定要快，撞洞是一件很尴尬的事情。。。
• #20: 报完问题后不要慌，首先你会得到issueid以及androidid，然后等待漏洞评级或者被告知撞洞。。。这段时间一般两周左右，不过最近时间有点久了。。。 在Google确认问题后，你可以继续提供漏洞的补丁以及对应的CTS测项，同时Google也会给出对应的CVE编号，以及向你要致谢名单。 最后就是告诉你可以得到多少奖金，以及在这个月的安全更新中致谢。
• #21: 这个是我们总结的16年向Google报告OMX相关漏洞的时间间隔，分别是，从报告到Google确认漏洞的时间间隔，以及从确认到公开的时间间隔，可以看到确认差不多确认是13天左右，而修复基本上都是两三个月后。
• #22: 再来看看漏洞严重性对处理速度的影响，一般来说越严重的，认定要慢一些，但是认定后，严重的漏洞修，补速度会大大加快。
• #23: 再来看看Google的漏洞评级认定依据，Google以漏洞的触发源头以及漏洞目标进程权限来确定漏洞的严重性。他们于5月8号更新了漏洞评定依据。这幅图是我自己总结的漏洞评级依据图，里面展示的是每一种漏洞类型造成最严重影响的情况。下面来讲讲几种漏洞的定级：在高权限的进程中远程代码执行是critical ；对手机的远程持久拒绝服务攻击是critical（就是点了一个文件后，手机就再也不正常工作了，除了刷机才能解决）；对于高权限进程的远程权限绕过也是critical；对tee的远程数据访问是高危；但是其实在本地的在tee的任意代码执行就已经是critical； 注意到这里面的TCB，可信计算基础依赖，是指内核中的一部分，主要是驱动的代码。以及少数的几个被认作与内核一样重要的进程，init ,user event daemon以及volume daemon。Google5月8号将TCB从内核中专门区分出来，然后降低了评级，也就是说，以后驱动中可以提权的内核漏洞，也只是高危而不是严重了。。。
• #24: 再来一个这个图的使用的例子，这里面是远程代码执行，是critical，那么本地的就是high了。那么如果远程的在微信中的代码执行，那也是high。最后的link是Google对这些漏洞评级的文字描述
• #25: 讲了漏洞评定定级，再来看看Google给的奖金。Android security team于六月一号公布了新的奖金框架，这一切还是得益于龚大师在syscan上对Google的Scott提的建议。Google大大提高了漏洞利用的奖金。对于定为critical级别的漏洞利用，如果可以影响到TEE，那么奖金可以最多20万刀的样子。 那么对于没有漏洞利用的情形，Google也有做一些修改，比如他们提高了critical漏洞的基础奖金，之前是4000刀现在是6000刀。High的话也提升了500刀。但是对于patch以及cts给的附加奖金有所降低，最多只有1000刀了，不过这与之前的critical没利用一共最多给8000刀的情况还是一致的。那么也就是说，做一个完整的漏洞利用会为奖金加分不少，但是所面临的的难度也不小。而且漏洞利用属于武器化的工程，有时候靠钱可能也是买不到的。这里有个建议，是可以先提交漏洞以及poc避免后期被撞洞，再提交对应的漏洞利用。那么讲到这里一直有出现一个名词CTS，还给奖金，那么我们再来说说CTS。CTS是Android特有的完整性测试的框架。主要用于验证Android操作系统的功能完整性。Link是Google VRP的评级依据文章
• #26: Android cts在源码中有security cts的模块，security cts存在的目的就是为了确认这些安全问题都得到了修复，那么写CTS其实就相当于把我们的漏洞在cts的框架中再尝试触发一次，确认漏洞已经被修补了。Security cts在源码中的相对目录是这个。在编写CTS的时候，需要依赖Android的代码规范，编写对应的native或者java测项。在验证通过之后，再将cts的diff提交给Google，需要注意的是diff是与AOSP主线的diff而不是最新版本分支的diff。下面这个是运行cts时候的样例代码。Link是Android CTS的相关介绍。
• #27: 谢谢各位聆听，我的分享结束了，有什么问题，欢迎大家提问。
• #28: 再来看看不同种属的漏洞的处理速度，内核与厂商的一般要久一点，因为需要协调沟通，而AOSP的一般会比较快。