Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

FlowDroid:Precise Context,Flow,Field,Object-sensitive and Lifecycle-aware Taint Analysis for Android App

摘要

FlowDroid是个Android静态的污点分析工具。克服了以往静态污点分析工具粗粒度,高误报和漏报的缺点。他们提供了DroidBench测试套件来评估污点分析的准确性和效率。在使用了SecuriBench,Micro,DroidBench等测试工具结果显示FlowDroid有低误报和漏报,同时在DroidBench的测试中击败IBM AppScan Source和Fortify SCA等商业软件。并成功发现了500个app和1000个VirusShare项目里malware的信息泄漏。

介绍

静态污点分析的几个问题: 1. 组件生命周期,有start/pause/resume/shutdown等回调,还有系统事件的回调,比如GPS,以及UI交互的回调等。 2. 一些污点源像密码输入框的UI组件需要XML文件配合,但从代码很难识别。 3. Java的aliasing and virtual dispatch constructs很复杂。

之前的静态数据流分析工具都很粗糙,高误报高漏报,相较之下,FlowDroid针对code和configuration files寻找潜在的无意和被恶意程序利用的隐私泄露,是第一个对context,flow,field和object都敏感且建模了整个Android的生命周期包括处理回调和自定义UI组件的。并使用了on-demand alias分析算法,保证效率和准确性。另外还提供了给静态污点分析做测试的DroidBench。

生命周期建模

构建假的main为入口,并使用IFDS(一种之前的关于data flow的通过graph的可达性分析)可以减小开销,并假设app内所有组件会以任意方式调用。对于回调函数,分析XML和代码定义两种方式。new一个组件为入口,后面构建了由各个需复写的方法(onStart,onPause等等)组成的生命周期流图。

精确的数据流分析

主要是结合了前向的污点分析和按需的backward-alias分析结合的数据流分析。使用IFDS框架的标准污点分析算法,唯一差别是一旦taint到堆上变量,如对象成员或数组之类的时候,会触发backward-alias分析。这部分非常复杂,作者说出于篇幅无法细说,更加详细的见一个对flowdroid的技术报告。

大概就是首先是细化到object的field的,接着是taint的标准实现,遇到method call怎么样,遇到new instance怎么样等等。接着详细说了on-demand alias分析,就是一但一个堆上的变量被taint了,就要开始backward-alias了。向后的去taint。其中提到如何保证对context和flow的sensitivity。非常复杂看不太懂,主要是讲什么情况下该taint,什么情况下不taint。来避免false negative和positive。context sensitivity是用来表明对同一个函数,不同上下文(如参数传入)情况不同下,得分情况进行backward的taint,flow sensitivity就是source如果在sink之后,backward的时候就不要taint。类似的这种分active和inactive的情况来taint。

实现

用soot框架,基于Jimple的三地址中间语言,基于Spark的call-graph分析框架。使用Dexpler来把dex变成Jimple。并使用Heros是个多线程大规模的IFDS框架实现。解析manifest,dex,xml后构造假的main来构建call graph,实施taint。source和sink使用susi的结果。输出包括整个flow的路径和声明等等。另外还有定义taint的捷径规则。对如JNI之类的黑盒,仅从参数和返回值的污点来判断,和预先定义一些如system.arraycopy之类的常用函数的taint规则。flowdroid仅支持显式的组件通信,以收intent的回调为source,发intent的的方法为sink。而隐式的组件通信如设置一个被调用activity的result value会被操作系统默认的传递给调用activity,这种行为不支持,以后和EPICC(2013 USENIX的文章,也是他们研究单位的成果)结合。Limitation包括多数的静态工具,如反射调用只支持参数是string常量,以及一些没有实现的Android生命周期内的会调用函数和native方法。另外无视多线程,认为线程执行是任意但有序的。

实验评估

几个问题:

  1. 和商用的污点分析工具比较精确性。
  2. FlowDroid能不能检查到InsecureBank这个专门用来挑战漏洞性检测工具的APK里的所有隐私泄露,表现如何
  3. FlowDroid能不能检查现实生活中的app的泄露,效率如何。
  4. FlowDroid对Android以外的Java程序表现如何。

  • 自己设计了DroidBench测试套件,包括39个app,覆盖了生命周期,各种回调,UI等,用来测试动静态的taint工具。实验分为precision和recall。precision是正确的warning除以正确warning+错误的warning。recall是正确的warning除以正确warning+漏掉的。FlowDroid这两项指标是86%和93%,IBM AppScan Source是74%和50%,HP的Fortify SCA是81%和61%。结论是商用软件尽量提高precision而牺牲了recall.
  • 对InsecureBank的结果,检测出了所有7个data leaks,没有误报和漏报,用了31秒。
  • 500个Play上的软件,没有发现潜在的恶意行为,主要是把IMEI和位置放到log或者preference files里。大多数是1分钟以内的。1000个VirusShare项目的已知恶意程序,平均是16秒,平均1.85个leaks,主要是IMEI发到远程服务器或者以短信发送,有时是扣费号码。有的被发现是通过broadcast receiver收消息然后发送短信,这是一种类似合谋的攻击,让别的程序不要申请短信权限,就能间接的发短信。
  • 重新定义source和sink后用来测试普通的java程序,Stanford SecuriBench Micro,true positive:117/121,false positive有9个。
  • 他们相比较,问了TrustDroid,LeakMiner,和Batyuk的工具,产品下线且没人回复。用DroidBench测SCanDroid,不报任何结果,双方联系了下最终解决不了问题。AndroidLeaks的作者答应跑DroidBench但没回复。CHEX因为NEC的版权问题无法提供结果,Starostin拒绝测因为他说他没做aliasing,比较无意义。ScanDal因为三星版权问题无法提供结果,但他们说他们用DroidBench提高了他们的分析,测试结果和FlowDroid差不多。作者总结说科研界的静态taint工具产品没有一个能成功比较,比较遗憾。(真是世态炎凉)。