Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Hybrid User-level Sandboxing of Third-party Android Apps

论文下载

本文提出了一个Android平台上的安全系统——AppCage。该系统在不修改系统framework以及不需要root权限的前提下,提供两个user级别的sandbox—dexbox和nativebox来限制APP对敏感API的访问。其中dexbox主要来限制Java代码,通过hook Dalvik VM 来重定向framework中的敏感API到一个预先制定的代理模块中,在这个代理中先应用用户定制的策略,再决定是否进行敏感API的调用。而在nativebox中来限制native code,阻止APP使用native code来访问敏感API或破坏dexbox。

整个系统的部署很简单,只需预先安装两个系统级别的APP,第一个是策略管理APP,会有个只有自己可写的存储策略的数据库,并提供接口让其他APP来读取策略。另一个APP是功能APP,会在系统中添加一系列底层库。当监听到手机安装APP时,会拦截这次安装,将原APP与定制的stubs,libhook.so,native code等一起打包为新的APP再安装,并会将APP入口改为初始化sandbox的代码。

Dexbox的原理就是通过hook系统敏感API,拦截对其访问,根据策略来决定是否允许调用,这部分工作并没什么新意,之前已经有很多人实现了这个功能。但即使没有ROOT的前提下,恶意APP还是可以利用native code来实现对敏感API的调用或破坏dexbox这个沙盒。因此,AppCage添加了native box,来专门限制native code。通过binary rewrite的方法来应用software fault isolation(故障隔离),使native code 不能写沙盒外的内存,使native code不能逃离沙盒,限制危险的指令(system call)。 binary rewrite的策略采用Native Client相同的策略,在APP安装时及动态运行时都会进行重写操作。整个重写分如下几个过程:

  1. Disassembling Native Code:以暴露接口为起点,将原代码递归分解为一条条的指令。
  2. Native Code Instrumentation,将native code分为几个模块分别处理:
    • Memory write instructions(不允许写沙盒外的内存)
    • Branch instructions (jump or call)(不允许跳到沙盒外的代码)
    • Instructions using pc as a general register(可以重定向指令的地址)
    • System call instruction(不允许直接调用敏感的system call,如果有APP依赖某些调用,提供了部分必要的systemlib的copy,如果调用了其他的函数,就直接退出APP)。
  3. System Libraries Instrumentation,处理native code依赖的系统库。由于native code可能需要依赖某些system lib,因此会对这些库也实行以上的策略。
  4. JNI Interface,处理JNI接口。由于Dalvik VM and native sandbox have different contexts under AppCage,因此需要切换context,通过hook JNI的interface来实现。

文章最后对AppCage进行了一系列评估,包括有效性,安全性,适应性,及性能损耗。通过几个恶意APP家族,来测试有效性,AppCage可以有效的阻拦恶意APP的敏感性为。通过多种安全性攻击来测试系统安全性,包括JAVA代码混淆,动态加载,不通过API而是直接调用系统服务,攻击Dalvik VM,攻击 native box,混合攻击等等,AppCage都能有效抵御。用Google Play上的APP测试适应性,发现都能正常运行,最后,在效率上,APP安装时耗时长一些,native code代码多的APP可能耗时会长一些,整体上来看可以接受。