DroidBox简介

目前Android系统最大的问题是什么?安全,这也是Android总是进不了企业的主要原因。如果问主要的安全问题是什么?我想应该是吸费、流量消耗和隐私泄漏。针对于隐私泄漏的侦测,目前有一个开源软件叫做DroidBox,算是做的不错的了。今天我们就来分析一下DroidBox是如何侦测隐私泄漏的。

DroidBox的核心技术称作TaintDroid,从字面上理解就是污染机器。我们都知道标识隐私数据并不难,只要牢牢卡住相关的API调用就可以了,问题是如何知道这些隐私数据被泄漏出去了?恶意程序拿到隐私数据后往往会做一系列的操作,包括截取,拼装,加密甚至是进程间传递,这使得隐私数据的跟踪变得相当困难。所以关键技术就演变成了:如何跟踪数据。TaintDroid的思想就是将所有隐私数据变成污染源,在程序运行的过程中如果你想对污染源进行截取,拼装,加密,传递等等操作,那么你新生成的数据也会被污染。如果有被污染的数据被泄漏出去,那么就发生了隐私泄漏。好,到这里问题变成了如何标记数据和如何进行污染。

先说比较好搞定的问题,如何进行污染。对于java操作(dex)的污染规则基本上可以用下图表示:

 DroidBox简介_第1张图片

可以看出污染的三大途径:赋值,参数传递,返回值。目前在dex里面无论怎么对隐私数据操作,都会被污染。而对于native的code, 污染会相对复杂一些,尤其是第三方的native code,但基本的理念还是一样的,这里就不详细介绍了。至于在Android里面具体污染的层次,可以用下面这张图来理解:

DroidBox简介_第2张图片

基本上能传播的方式都可以污染,Dalvik之上是变量级的污染,Native是调用级的污染,存储是文件级的污染,IPC还有消息级别的污染。

污染跟踪的问题解决了,另一个问题是如何标记,换句话说,就是在什么地方存储每块数据是否被污染的标记。对于不同的层次有不同的存储方式。最容易搞定的依然是Dalvik以上的部分,系统Native库较为难搞,最不好搞的是第三方Native库。基本上存储的方式可以用下面这张图表示:

DroidBox简介_第3张图片

对于Dalvik以上的部分,利用修改Dalvik来搞定,因为Android里面的java是32bit的,所以所有引用的大小也都是32bit,TaintDroid为每个引用多申请了一倍的空间,即64bit。程序自身还是用前32bit, 而TaintDroid就可以利用剩下的32bit, 采用bitmap的方式可以标注32种不同的隐私类型。这种方式带来的副作用不言而喻,会导致程序引用占用的内存增加一倍,而优点是可以精确定位到每个对象是否被污染。
对于Native的模块就不这么简单了,因为无法修改指针长度(改kernel应该可以,但影响面太大了)。所以TaintDroid的污染是基于调用级的,利用增加调用参数的方式来放污染标记。例如上图第三列,有一个调用的参数有两个:arg0和arg1, TaintDroid再多加3个参数,第3个参数是输出参数,调用完成后return值的标记就放在这里,第4和第5个参数是输入参数分别是arg0和arg1的污染标记。通过这种方式,在做完一次Native调用后就可以得到return值的污染标记(注意,仅仅是return值),所以这种方式被称为面向调用的污染。

 

应该说DroidBox最核心的东西就这么多了,那么TaintDroid是否就完美了呢?显然不是的,它依然存在FP和FN。FN主要存在于Native Code的调用,尤其是第三方Native Code的调用。对于这个问题TaintDroid有个坑爹的对策:不允许调用第三方的动态库。这就意味着所有调用第三方库的程序都不能在TaintDroid的Image上运行。坑爹吧,因为我们知道尤其在中国很多热门应用都要用到第三方库的。而FP的情况也并不乐观,FP出现问题的地方主要包括:自身设计问题和先天条件限制。我们在实际使用的过程中发现TaintDroid会吧所有的pipe操作误认为是文件操作,只要有隐私数据参与pipe操作,就会有FP发生。而TaintDroid对于Array的策略也是另外一个FP的来源,由于Array在Dalvik中只有一个引用,所以TaintDroid只有一个标记的位置,因而策略是宁可错杀一千,不可放过一个。即使未来Array里面的那个污染源已经被移走了,Array的标记依然不会被清除。

针对于这些问题,我们team已经做了很多改动和修补,也许在未来我们会公开我们的源码。

你可能感兴趣的:(DroidBox简介)