MathJax.Hub.Config({tex2jax: {inlineMath: [['$','$'], ['\\(','\\)']]}}); function MyAutoRun() {    var topp=$(window).height()/2; if($(window).height()>450){ jQuery(".outline_switch_td").css({ position : "fixed", top:topp+"px" }); }  }    window.onload=MyAutoRun; $(window).resize(function(){ var bodyw=$win.width(); var _leftPaneInner_width = jQuery(".rich_html_content #leftPaneInner").width(); var _main_article_body = jQuery(".rich_html_content #main_article_body").width(); var rightw=bodyw-_leftPaneInner_width-_main_article_body-25;   var topp=$(window).height()/2; if(rightw<0||$(window).height()<455){ $("#nav-article-page").hide(); $(".outline_switch_td").hide(); }else{ $("#nav-article-page").show(); $(".outline_switch_td").show(); var topp=$(window).height()/2; jQuery(".outline_switch_td").css({ position : "fixed", top:topp+"px" }); } }); Android安全研究进展
  软件学报  2016, Vol. 27 Issue (1): 45-71   PDF    
Android安全研究进展
卿斯汉1, 2, 3     
1. 中国科学院 软件研究所, 北京 100190;
2. 信息安全国家重点实验室(中国科学院 信息工程研究所), 北京 100093;
3. 北京大学 软件与微电子学院, 北京 102600
摘要:Android是目前最流行的智能手机软件平台,报告称,2014年,Android的销售量占到全球份额81%的绝对优势,首次达到10亿部.其余如苹果、微软、黑莓与火狐等则远远落在后面.与此同时,Android智能手机的日益流行也吸引了黑客,导致Android恶意软件应用的大量增加.从Android体系结构、设计原则、安全机制、主要威胁、恶意软件分类与检测、静态分析与动态分析、机器学习方法、安全扩展方案等多维角度,对Android安全的最新研究进展进行了总结与分析.
关键词Android    安全机制    恶意软件    静态分析与动态分析    安全扩展方案    
Research Progress on Android Security
QING Si-Han1, 2, 3     
1. Institute of Software, The Chinese Academy of Sciences, Beijing 100190, China;
2. State Key Laboratory of Information Security(Institute of Information Engineering, The Chinese Academy of Sciences), Beijing 100093, China;
3. School of Software and Microelectronics, Peking University, Beijing 102600, China
Abstract: Android is a modern and most popular software platform for smartphones. According to report, Android accounted for a huge 81% of all smartphones in 2014 and shipped over 1 billion units worldwide for the first time ever. Apple, Microsoft, Blackberry and Firefox trailed a long way behind. At the same time, increased popularity of the Android smartphones has attracted hackers, leading to massive increase of Android malware applications. This paper summarizes and analyzes the latest advances in Android security from multidimensional perspectives, covering Android architecture, design principles, security mechanisms, major security threats, classification and detection of malware, static and dynamic analyses, machine learning approaches, and security extension proposals.
Key words: Android    security mechanism    malware    static and dynamic analyses    security extension proposal    

在智能移动终端如火如荼发展的同时,其安全态势也日益严峻.Alcatel Lucent旗下的Motive Security Labs发布的恶意软件分析报告[1]指出,2014年,全球受恶意软件感染的移动设备为1 600万台,占全部移动设备的0.68%,同比增长了25%,高于2013年的20%.图 1说明,自2012年12月~2014年12月之间移动设备感染率增长的情况.

图 1 2012年12月以来移动设备感染率 Fig.1 Mobile infection rate since December 2012

Android是目前应用最广的智能手机操作系统,它的设计兼顾系统的性能、可用性、安全性与开发方便性,受到广大用户的欢迎.据权威分析机构Strategy Analytics的统计[2],2014年,全球智能手机的年销售增长率大于30%,达到超记录的13亿部,其中,Android的销售量占到全球份额81%的绝对优势,首次达到10亿部.其余如苹果、微软、黑莓与火狐等则远远落在后面.另一方面,Android系统的开放性也受到应用开发者的青睐,但同时也带来更多的安全问题.Android设备和Win dows PC已经成为恶意攻击的主要对象,遭恶意软件攻击的次数已经趋同.2014年,Android恶意软件样本的增长率为161%.图 2是自2012年6月以来的统计[1].

图 2 Android恶意软件样本量持续增加 Fig.2 Android malware samples continue growth

然而,Android应用的迅猛发展和安全问题的日益突出与反制措施极不协调.Zhou等人[3]的研究表明,4个有代表性的移动反病毒软件:AVG(AVG antivirus free v2.9),Lookout(lookout security & antivirus v6.9),Norton (norton mobile security lite v2.5.0.379)和TrendMicro(TrendMicro mobile security personal edition v2.0.0.1294)在最佳和最坏情形下只能分别检测出79.6%和20.2%的恶意软件.

在这种形势下,近年来,关于Android安全的研究大幅度增加.来自会议、期刊和网络的论文覆盖面很广:智能手机(Android,iOS,Windows Phone等)安全综述如文献[4, 5, 6]、Android安全综述如文献[7, 8, 9, 10, 11, 12, 13]、某类问题的综述——如针对Android恶意软件[14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31];Android的权限机制[32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50];机器学习在Android中的应用[51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61]等.更多的研究是关于某个具体方向的分析和讨论以及对某个具体问题的深入分析.例如:Felt等人[33]对Google官方文件没有仔细阐述的Android权限实现机制进行了剖析,给出了权限与API之间的映射关系.此外,还有厂商提供的应用工具与安全工具等,如Google提供的反编译工具Apktool[62]和FireEye公司提供的基于“多向量虚拟执行(multi-vector virtual execution,简称MVX)”引擎的移动威胁保护工具(FireEye mobile threat prevention,简称MTP)[63].

Android的安全问题并非都是其独有的,Android继承了许多发生过的类似安全问题,自然地也继承了其底层Linux中的安全问题.例如,“Setuid()-RLIMIT_NPROC交互”型漏洞经常发生在Linux(以及Unix)中各种root守护进程与setuid-root程序之中,该漏洞源于没有正确检查setuid()函数的返回值.setuid()执行成功或失败时,分别返回0和-1.当程序以root身份运行并正常执行setuid(UID)后,将降低权 限为普通用户.但因未检查setuid()的返回值,当setuid失败时,程序仍将继续以root身份运行,就会产生许多安全问题.Zimperlich[64]恶意软件(参看第3.1.2节)正是利用了上述漏洞,成功地攻击了Android系统.

下面,本文将从Android体系结构、设计原则、安全机制、主要威胁、恶意软件分类与检测、静态分析与动态分析、机器学习方法、安全扩展方案等多维角度,对Android安全的研究现状与进展进行全面的总结与分析.最后,对全文进行总结.

1 Android体系结构 1.1 Android 软件栈

Android的软件栈具有清晰的3层结构[65],由底向上是Linux内核、Android中间件和应用层,如图 3所示.

图 3 Android软件栈 Fig.3 Android software stack

Linux内核提供最基本的功能,包括内存管理、进程调度、设备驱动器和文件系统.所有的设备资源,例如照相与摄像功能、GPS数据、蓝牙功能、通话功能、网络连接等,都通过操作系统进行访问.

Android在内核层实现了基于Binder(OpenBinder[66]的精简版本)的轻量级进程间通信(inter-process communication,简称IPC),这是应用组件之间进行通信的主要IPC机制,在Android的术语中称为组件间通信(inter-component communication,简称ICC).Android为ICC设计了一种特定的接口定义语言(Android interface definition language,简称AIDL),定义用于远程调用的method和field.例如,可以通过ICC调用绑定远程服务.

Linux之上的中间件层由本地类库、Android运行环境和Android应用架构组成.本地类库提供诸如图形处理等基本功能.Android运行环境由核心Java类库与Dalvik虚拟机组成.Android应用架构是用C/C++或Java编写的系统应用,由System Content Provider和System Service构成.其中,System Content Provider是基本数据库;System Service包括联系人app、前贴板、系统设置、Notification Manager、Resource Manager、Location Manager等,System Service提供控制设备硬件和获取平台状态信息(如位置、网络状态)等功能.

最上面的应用层由两部分组成:一是内置的基本应用,包括桌面(home)、拨打电话(phone)、E-mail、日历(calendar)、Web浏览器(browser)和联系人(contacts)等;二是用户安装的用Java编写的第三方应用,但由于性能的原因,许多应用也包括本地代码(C/C++),可以通过Java本地接口(Java native interface,简称JNI)调用.

1.2 Android的组件

Android有4种类型的组件(component).

(1) Activity(用户界面)是应用程序与用户进行人机交互的可视化用户界面,包含很多与用户交互的构件,如按钮、文本输入框等.一个Android应用程序可以有多个Activity;

(2) Service(后台进程)是Android系统运行在后台的服务,不提供用户界面;

(3) Content Provider(内容提供器)是一种SQL-数据库,用于为应用程序提供数据,同时为应用程序中的数据共享提供支持;

(4) Broadcast Receivers(广播接收器)是接收广播消息的邮箱.

1.3 Intent与组件通信

Android系统中不同组件之间的通信主要是通过Intent实现的,Intent是一个包含目标组件地址和数据的消息对象.Android API定义了接收Intent和通过其中的信息启动Activity(startActivity(Intent))、启动Service (startService(Intent))和广播消息(sendBroadcast(Intent))的方法(method).调用这些方法相当于通知Android系统开始调用目标应用中的执行代码,在Android术语中,这种组件间通信的过程称为“动作(action)”.亦即,一个Intent对象定义执行一个“动作”的意图(intent),这就是“Intent”名称的缘由.

Android系统发送Intent对象的方式有两种类型:(1) 显式类型,发送时在Intent对象的字段中标注目标组件名称,即,该Intent对象会到达该指定组件;(2) 隐式类型,发送时只设置Intent对象中的“动作(action)”字段,发出后可能有多个程序通过intent-filter机制能够处理该动作.应用程序在组件中可以声明intent-filter,定义该组件可以接收的动作和处理的数据类型.这种使用“隐式类型”的Intent寻址机制的灵活性是Android系统最为强大的功能之一,但同时也会带来安全隐患.

Android组件的通信如图 4所示.

图 4 Android组件间通信示意图 Fig.4 Android inter-component communication

1.4 Android系统架构

Android的系统架构[67]图 5所示,除前面阐述的软件栈之外,还有硬件的支持.Android支持两种指令集架构:ARM和x86.

图 5 Android系统架构 Fig.5 Android system architecture

硬件抽象层(hardware abstraction layer,简称HAL)是Android系统调用设备驱动层的标准接口,避免涉及驱动器和硬件的底层实现.HAL通常以.so文件形式实现,.so文件是Linux操作系统的动态链接库文件格式,相当于Windows操作系统的.dll动态链接库文件格式.

1.5 Android的设计原则

笔者认为,Android的设计遵循了下面3个原则.

(1) 开放性:在与苹果手机等的激烈竞争中,为吸引用户、第三方开发商与应用程序开发者所做出的选择,从目前的市场销售量与发展趋势看,无疑取得了很好的效果;

(2) 资源有限性:由于手机应用的资源(内存、电池等)有限,必须进行相应的重新设计.此外,由于某些系统受到版权保护,也需要进行重新设计,例如Bionic(非POSIX libc);

(3) 简单性:为了方便用户,Android系统设计采取了“简单、快速与易用”的原则,在安全性方面作了折中.

值得注意的是:尽管Android的基础是Linux,但对Linux作了大幅度修改,因此,Android不是Linux.概括地说,Android对Linux的内核级增强包括alarm驱动器、ashmem(Android共享内存驱动器)、binder驱动器(Android特有的轻量级进程间通信机制)、电源管理、低内存管理器(low memory killer,简称LMK)和内核调试器(kernel debugger)等.其中,alarm驱动器通过定时器唤醒休眠设备;ashmem使Android应用可以高效地在内核级共享有限的内存;电源管理构建在标准Linux电源管理(PM)之上,采用更加有效的省电策略.Android对Linux的用户级增强包括Bionic(非POSIX C程序库)、预链接的系统库、Dalvik虚拟机和本地类库等.此外,Android使用在有限资源条件下优化的YAFFS(yet another flash file system) flash文件系统.

1.6 Dalvik虚拟机

Dalvik虚拟机是Android系统的核心组成部分之一,它与Java虚拟机(JVM)不同,是专门为资源有限的移动终端设计的,可使智能手机同时有效地运行多个虚拟机.每个应用程序都作为一个Dalvik虚拟机实例,在自己的进程中运行.Dalvik虚拟机的可执行文件格式是.dex(Dalvik executable),是专门为Dalvik设计的一种压缩格式.与基于栈的JVM不同,具有更高效率的Dalvik虚拟机是基于寄存器的.Java源代码编译成.class文件后,通过Android SDK中的“dx”工具转换为Dalvik虚拟机可执行的.dex文件.每个.class文件中只包含一个class,但一个dex文件可以包含多个class.

Dalvik虚拟机中有一个重要的虚拟机进程Zygote,称为虚拟机实例的孵化器.每当系统要求执行一个Android应用程序时,Zygote就会fork出一个子进程来执行该应用程序.Zygote是系统启动时产生的,它会完成虚拟机的初始化、库的加载等操作.如果系统需要创建一个新的虚拟机实例,Zygote就通过fork自身,以最快的速度提供给系统.对于一些只读的系统库,所有虚拟机实例都和Zygote共享一块内存区域,极大地节省了内存开销.Dalvik虚拟机有一套自身专用的指令集,并规定了这套指令集的指令格式与调用规范,称为smali语言.

2 Android的安全机制 2.1 Android 安全模型

Android的安全模型由3个部分组成:Linux安全机制、Android本地库及运行环境安全与Android特有的安全机制,见表 1.

表 1 Android安全模型 Table 1 Android security model

2.1.1 Linux安全机制

Android继承了Linux的安全机制,主要有:

(1) POSIX(portable operating system interface of unix)用户.

每个包(.apk)文件安装时,Android会赋予该文件唯一的Linux(POSIX)用户ID.因此,不同的包代码不可能运行于同一进程,相当于系统为每个应用建立了一个沙盒,不论调用应用程序的方式如何,一个应用程序始终运行在属于自己的进程中,拥有固定的权限.

为使两个应用程序共享权限,它们必须共享相同的ID,并通过sharedUserID功能实现.

(2) 文件访问控制.

Android系统文件与应用文件的访问控制继承了Linux 的权限机制.每个文件都绑定UID(用户ID)、GID (用户组ID)和rwx权限,用于进行自主访问控制(discretionary access control,简称DAC).一般地,Android系统文件的拥有者是“系统”用户或“根”用户.为了增强安全性,所有的用户和程序数据都存储在数据分区,与系统分区隔离.当Android系统处于“安全模式”时,数据分区的数据不会加载,便于系统进行有效的恢复管理.此外,系统镜像设置为只读.

2.1.2 Android本地库及运行环境安全

Android本地库及运行环境也提供了安全保障,主要有:

(1) 内存管理单元(memory management unit,简称MMU).

该硬件设备为进程分配不同的地址空间(虚拟内存),是一种隔离进程的有效方法.进程只能访问自己的内存页,而不能访问其他进程的内存空间.

(2) 强制类型安全.

类型安全(type safety)是编程语言的一种特性,它强制变量在赋值时必须符合其声明的类型,防止变量被错误或不恰当地使用.类型转化错误或缺少类型安全边界检查,是产生缓冲区溢出攻击的主要原因.Android使用强类型Java语言,通过编译时的类型检查、自动的存储管理和数组边界检查保证类型安全.此外,Binder也是类型安全的,经Binder传送的数据元类型由AIDL定义,保证类型在跨越进程边界时保持不变.

(3) 移动设备安全.

电话系统的基本属性集来自识别用户、监督使用和收费的需求.一个更为通用的术语是所谓的“AAA”,即,认证(authentication)、授权(authorization)和记账(accounting).Android借鉴智能手机设计的这些典型安全特征,认证和授权通过SIM卡及其协议完成,SIM卡中保存使用者的密钥.

2.1.3 Android特定安全机制

Android独有的安全机制包括:

(1) 权限机制.

这是Android中最重要的安全措施之一,将在第2.2节中详细阐述.

(2) 组件封装.

通过组件(activity,service,content provider和broadcast receiver)封装,可以保证应用程序的安全运行.若组件中的功能exported设置为false,则组件只能被应用程序本身或拥有同一UID的应用程序访问,此时,该组件称为私有组件;若exported设置为true,则组件可被其他应用程序调用或访问,此时,该组件称为公开组件.

(3) 签名机制.

为便于安装,Android将应用程序打包成.apk文件.一个.apk文件不仅包含应用的所有代码(.dex文件),也包含应用所有的非代码资源,如图片、声音等.Android要求所有的应用程序(代码和非代码资源)都进行数字签名,从而使应用程序的作者对该应用负责.只要证书有效,且公钥可以正确地验证签名,则签名后的.apk文件就是有效的.

(4) Dalvik虚拟机.

如第1.6节所述,每个应用程序都作为一个Dalvik虚拟机实例在自己的进程中运行.因此,Dalvik虚拟机与POSIX用户安全机制一起构成了Android沙盒机制.

2.2 Android权限机制

权限管理是Android系统中最重要的安全措施之一,经过了精心设计与考量.为达到方便、易用和简单、快速的目标,Android在安全性方面做出了一定程度的牺牲,即,决定采取粗粒度的权限管理机制[68].

Android的权限管理遵循“最小特权原则[69],即,所有的Android应用程序都被赋予了最小权限.一个Android应用程序如果没有声明任何权限,就没有任何特权.因此,应用程序如果想访问其他文件、数据和资源就必须在AndroidManifest.xml文件中进行声明,以所声明的权限去访问这些资源.否则,如果缺少必要的权限,由于沙箱的保护,这些应用程序将不能够正常提供所期望的功能与服务.

所有应用程序对权限的申请和声明都被强制标识于AndroidManifest.xml文件之中,通过<permission>, <permission-group>,<permission-tree>等标签指定.需要申请某个权限,可以通过<uses-permission>指定.应用程序申请的权限在安装时提示给用户,用户可以根据自身需求和隐私保护的考量决定是否允许对该应用程序授权.

由于基于Linux内核,Android系统中的权限分为以下3类.

(1) Android手机所有者权限;

(2) Android ROOT权限.类似于Linux,这是Android系统中的最高权限.如果拥有该权限,就可以对Android系统中的任何文件、数据、资源进行任意操作.所谓“越狱(JailBreak)”,就是令用户获得最高的ROOT权限;

(3) Android应用程序权限.该权限在AndroidManifest文件中由程序开发者声明,在程序安装时由用户授权.共有下述4类不同的权限保护级别(protection level).

(i) normal.风险较低的权限,只要申请即可使用,无需用户授权,例如“VIBRATE”权限(使设备震动);

(ii) dangerous.风险较高的权限,安装时需要用户确认才能使用,例如“PHONE CALLS”(打电话), “INTERNET”(访问Intent)和“SEND SMS”(发短信)权限;

(iii) signature.仅当申请该权限的应用程序与声明该权限的程序使用相同的签名时,才赋予该权限;

(iv) signatureOrSystem.仅当申请该权限的应用程序位于相同的Android系统镜像中,或申请该权限的应用程序与声明该权限的程序使用相同的签名时,才赋予该权限.

Android权限机制是通过其中间件层实现的,由其访问监控器(reference monitor)对ICC调用实施强制访问控制(mandatory access control,简称MAC).运行时,当组件请求ICC调用时,访问监控器核查该组件是否具有相应的权限.在图 6[11]所示的例子中,应用1中的组件A试图访问应用2中的组件BC,但比较BC的访问权限标签和赋予应用1的访问权限标签集后,访问监控器允许A访问B,但拒绝A访问C.

图 6 Android权限机制实现举例 Fig.6 An example of Android permission mechanism enforcement

图 7[70]描述了Android的通信信道与相应的访问控制机制:在中间件层,Android通过访问监控器对ICC调用进行强制访问控制;在内核层,Android继承了Linux的安全机制,对文件系统和默认Linux进程间通信实施自主访问控制.同时,对网络套接字(socket)实施强制访问控制.

图 7 Android通信信道与相应的访问控制机制 Fig.7 Android communication channel and its access control mechanism

2.3 Android 权限机制的安全缺陷

迄今,研究者对Android的权限机制提出了诸多批评,对其安全缺陷进行了深入分析.概括地说,Android权限机制的安全缺陷主要表现在以下几个方面.

(1) 粗粒度的授权机制

如前所述,Android的权限机制是粗粒度的,即:要么赋予权限,要么拒绝授权.当某个应用申请了不适当或过多权限时,多数情形下用户都会选择授权,而很多安全问题便由此而来.因此,研究者提出了各种较细粒度Android授权机制的改进方案[71, 72, 73].

(2) 粗粒度权限

值得指出的是:不仅Android的权限管理机制是粗粒度的,大多数Android权限也是粗粒度的[74, 75],如应用范围很广的INTERNET,READ_PHONE_STATE和WRITE_SETTINGS都是粗粒度权限,因为拥有这些权限的应用可以任意访问特定的资源.例如,超过60%的Android应用程序需要INTERNET权限[44],拥有该权限的应用可以向所有的域发送HTTP(S)请求,并连接任意目标地址和端口.

因此,恶意应用可以伪装成确实需要Internet访问的合法程序滥用Internet资源.

(3) 不充分的权限文档

Google提供给开发者的权限文档不充分、不准确,有时还包含错误,容易造成开发者的失误,也会成为安全威胁的源泉(例如,申请过多不必要的权限).Felt等人[33]发现:Android 2.2文档仅列出了78个method的权限需求,事实上,应当说明1 259个method的权限需求,是原文档的16倍.此外,他们还发现了Android权限文档中的6处错误.

(4) 溢权问题

Android权限机制难以发现和阻止应用程序申请过多的权限,产生所谓“溢权(overprivilege)”问题,突破了“最小特权原则”,是一种严重的安全隐患.研究表明[33]:多达三分之一的应用具有溢权问题,其中56%的溢权应用有1个多余的权限,94%的溢权应用有2~4个多余的权限.总起来说,溢权问题共分两类:即恶意溢权和非故意溢权.

(5) 未提供“权限-API”对应关系映射集

Google没有给出重要的“权限-API”对应关系映射集,Felt等人[33]的研究弥补了这一空白.如图 8所示,Android API[76]的架构由两部分组成:位于应用进程虚拟机中的API库和在系统进程中运行的API实现.API调用有3个步骤:(i) 应用调用API库中的公开API;(ii) 公开API调用API库中的私有接口(称为RPC stub);(iii) RPC stub初始化一个RPC请求,请求系统进程完成所需的操作.例如,某应用调用ClipboardManager.getText(),则该调用被中继到IClipboard$Stub$Proxy;然后,后者代理前者调用系统进程中的ClipboardService服务.Android系统通过权限验证机制检查给定的应用程序是否具有指定的权限.权限验证机制在可信的系统进程中运行,并对API调用进行权限检查.如果Android应用程序没有申请权限就进行了API调用,则权限检查时就会抛出安全异常.Felt等人[33]完成了“权限-API”对应关系映射集的构建,并在此基础上比较应用申请的权限和API调用,检查应用是否溢权.

图 8 Android中的API调用与权限检查 Fig.8 Android API calls and permission checks

2.4 Android的安全威胁

尽管Android系统精心设计了安全机制,但是由于Android的开放性以及在性能和安全性方面进行了折中,所以无法避免黑客的成功入侵.黑客通过利用系统漏洞,绕过系统安全机制、突破权限管理的“最小特权原则”等方法,对Android系统形成不同类型和不同程度的安全威胁.根据Android的安全架构,其安全威胁来自不同的层次,如图 9所示.

图 9 Android面临的安全威胁 Fig.9 Security threats to Android

例如,来自Linux内核的攻击就会严重威胁Android系统的安全.Linux每年都有近百个漏洞被CVE收录,通过内核漏洞利用获得系统最高权限,是黑客的首要攻击目标.

基于系统核心程序的攻击也是Android面临的主要威胁.例如,对Intent对象中目标组件的名称或动作进行修改,以劫持和伪造Intent等方式威胁Android安全.

基于应用程序的攻击更是五花八门.由于用户自行安装的应用程序来源多样,无法验证其安全性,使得针对应用程序的攻击成为Android系统最常见的安全威胁.

在实践中,安全威胁并不拘泥于单一的攻击形式,往往是多种攻击形式的相互配合,需从硬件到应用程序各个层次进行综合分析.

2.5 Google的应对措施

在日益增加的安全威胁下,Google通过版本升级不断改进Android系统的安全性.例如:

● 借鉴Windows操作系统行之有效的经验[77, 78],采取防止堆和栈缓冲区溢出攻击的措施,如:在Android 2.3版本之后增加了基于硬件的NX(no eXecute)支持,不允许在堆和栈中执行代码.在Android 4.0之后,增加了“地址空间布局随机化(address space layout randomization,简称ASLR)”功能,防止内存相关的

攻击;

● 为防止恶意软件在用户未知晓的情况下提供高付费短信服务,Android 4.2[79]引入了附加的用户通知功能;

● 为防止前文提到过的“Setuid()-RLIMIT_NPROC交互”型漏洞利用,Android 4.3[80]停止了对setuid()/ setgid()的支持;

● 为防止内核级提权攻击,Android 4.3[81]做出了一个重大变更,即,引入了具有强制访问控制机制的SELinux的支持.Android 4.4进一步扩大了SELinux的支持.

3 Android 恶意软件

针对Android的恶意软件层出不穷,除熟知的木马、病毒、蠕虫、DDoS、劫持、僵尸、后门之外,近来又出现了如间谍软件(spyware)、恐吓软件(scareware)、勒索软件(ransomware)、广告软件(adware)和跟踪软件(trackware)等恶意软件.特别地,如今越来越多的建议是将如影随形的广告软件列入恶意软件范畴.

3.1 Zimperlich

目前,一般将root exploit视为针对Android手机的专用术语(有时也称作root Android),系指用户可以获取Android操作系统的超级用户权限,类似于Apple iOS的“越狱”.某些用户通过root越过手机制造商的限制进行设备定制:卸载预装在手机中的某些应用程序,或运行一些需要超级用户权限的应用程序.恶意软件则通过Root提升权限,绕过Android系统的安全机制.最著名的三大Android root exploit恶意软件是Zimperlich[64], Exploid[82]和RATC(RageAgainstTheCage)[83].许多其他恶意软件都是在它们的基础上研发的,如DroidDream[84], Zhash[85],DroidKungFu[86]和Basebridge[87].其中,DroidKungFu以加密的方式同时包含RATC和Exploid.当DroidKungFu运行时,首先解密和发起root exploit攻击,如果成功获取根权限,随后就可以为所欲为.

Android Zygote是以root权限运行,并用于孵化所有Android应用的系统服务.Zygote收到孵化app的请求后,对每个app fork一个子进程.在执行app代码之前,子进程通过setuid()切换到分配给app的一个无特权的UID.Dalvik VM中的一段代码实现了上述过程.

在一般情形下,root进程调用setuid()不会失败,因此,Dalvik虚拟机不检查setuid()调用是否成功,导致setuid()调用失败时不终止进程运行.Zimperlich[64]利用这个漏洞进行攻击的过程如下:

(1) 重复fork自身,最终耗尽所有的PID,亦即达到用户进程数的上限RLIMIT_NPROC;

(2) 向Zygote发送在新进程中孵化它的一个组件的请求.当Zygote fork一个子进程并试图创建app UID时,由于达到系统资源的极限,setuid()调用失败.这时,Dalvik虚拟机并不异常终止,使Zimperlich代码得以与Zygote相同的UID运行,即,作为root进程运行;

(3) 重装可读写的系统分区,在其中创建setuid-root shell.这样,Zimperlich可在此后任何时刻均能获得具有root权限的访问.

Linux(以及Unix)中setuid()和RLIMIT_NPROC微妙的交互,是许多类似安全问题(统称为Setuid()-nproc极限型漏洞)的根源,例如,RATC恶意软件也是利用这种漏洞成功地攻陷了Android调试桥接守护进程(Android debug bridge daemon,简称ADBD),从而取得根权限.因此,对此问题如何改进Linux的内核,成为近期研究者讨论的热门问题[88].

3.2 Android恶意软件分类

Android恶意软件有不同的分类方法,按照传统的方法可以如下分类.

● 木马类.这是一类多发性恶意软件,较著名的有Zsone[89],FakeNetflix[90],Fakeplayer[91],Spitmo和Zitmo[92]等;

● 病毒类.例如,Obad[93]是一款有名的蓝牙蠕虫病毒;

● 后门类.这也是一类多发性的恶意软件,较著名的有Obad[93],RATC[83],Basebridge和KMin[3]等.注意, Obad既是病毒也是后门;

● 僵尸类.文献[3]中给出了一些僵尸的例子:Geinimi,Anserverbot和Beanbot.此外,NotCompatible[1]也是一款著名的僵尸类恶意软件;

● 间谍软件类.例如,GPSSpy[3]和Nickyspy[89];

● 恐吓软件类.例如,Koler[1];

● 勒索软件类.例如,FakeDefender.B[94].注意,勒索软件往往同时也是恐吓软件;

● 广告软件类.例如,Uapush.A[1]是一种著名的广告软件木马;

● 跟踪软件类.例如,SMSTracker[1]是一款著名的跟踪软件.

Zhou等人[3]根据Android恶意软件的特征进行如下分类.

(1) 恶意软件安装(malware installation)

● 重打包(repackaging);

● 更新攻击(update attack);

● 诱惑下载(drive-by download);

● 其他.

(2) 恶意软件运行(activation)

(3) 恶意载荷(malicious payloads)

● 提权攻击(privilege escalation);

● 远程控制(remote control);

● 付费(financial charge);

● 信息收集(information collection).

(4) 权限使用(permission uses)

他们的分析指出:在其1 260个恶意软件样本中,有1 083个属于重打包型恶意软件,占比为86%.

3.3 提权攻击

通过权限提升实现成功攻击,是黑客最常用的手段之一.有别于前面阐述过的root exploit型攻击,这里所说的提权攻击系指没有任何权限的恶意程序能够通过第三方程序获得所需的权限.Davi等人[95]关于这类提权攻击给出了下述定义:“一个拥有较低(较少)权限的应用程序访问拥有较高(较多)权限的组件而不受任何限制,称为Android系统的提权攻击”.有的文献也称此类提权攻击为“权限再次授权(permission re-delegation)”.

图 10所示,app3中的组件1受权限P1保护,app1中的组件1没有权限,app2中的组件1拥有权限P1.因此,app1中的组件1不能直接访问app3的组件1,而app2中的组件1可以访问.但app2中的组件1不受任何权限保护,故app1中的组件1可以访问它,然后,通过它获得访问app3中组件1的资格.这样,app1中的组件1就绕过了app3中组件1的保护机制完成了提权攻击.

图 10 Android提权攻击 Fig.10 Privilege escalation attack on Android

具体的提权攻击实现方法[96-99]各不相同,有的利用Intent盗窃/劫持[99],有的需要多个应用程序之间的相互配合等.

有些文献将提权攻击分为两大类[32, 98]:困惑代理(confused deputy)攻击与合谋攻击(collusion attack).1988年,Hardy[100]提出了所谓“困惑代理”的概念,问题源于操作系统编译程序的“一仆二主”,即,编译程序运行时同时具有分别来自两个调用的不同权限.对于智能手机,具有不同权限集的应用可以彼此通信,使恶意应用具有非法使用某些正常app权限的可能性.典型的攻击场景是:当一个有权限(但“困惑”)的app接口有漏洞时,恶意软件利用该 接口漏洞实施困惑代理攻击.

合谋攻击需要多个应用程序之间的相互配合,又可细分为直接攻击[101]与间接攻击[102]两个子类.顾名思义,前者依靠应用程序之间的直接通信;而后者依靠它们之间的间接通信.图 11是一种合谋攻击的例子,首先,攻击源A通过代理组件(C1,C2,…)到达泄露点P种下种子(植入恶意代码等);然后,通过攻击源B二次对泄露点P进行攻击,进行提权操作或数据窃取等.这样,即使检测器可以检测到攻击源B的攻击,攻击源A却依旧难以被发现.

图 11 合谋攻击举例 Fig.11 An example of collusion attack

3.4 中间人攻击MITM

中间人(man-in-the-middle,简称MITM)攻击是不同领域中随处可见的攻击方法,在Android中,主要针对通过SSL/TLS加密的API.众多学者[103, 104, 105]对此进行了深入的分析,有些文献[106, 107]给出了具体的对策.

Android应用程序通过SSL/TLS加密的API安全地传输敏感信息,但app开发人员通常自行实现标准的SSL/TLS证书验证程序.许多这类定制的实现故意接受所有自签名的证书,有的甚至不作任何校验便接受所有的证书,有的包含各类安全漏洞,使MITM攻击有了成功的机会.

Fahl等人[103]实现了一个名为Malldroid的工具,对13 500个包含SSL/TLS代码的app进行了静态分析,发现其中1 074个(占比为8.0%)app含有易受MITM攻击的安全漏洞.他们在这些含有漏洞的app中选择了100个热门应用进一步作了人工分析,发现其中41个应用程序的确不能对MITM攻击免疫.文献[105]对Android官方应用市场Google Play中的11 748 个app进行的自动分析表明,其中,10 327个(占比为88%)app使用了加密API并至少犯了一个错误.文献[104]的分析指出:在许多与安全相关的热门应用与库中,SSL证书认证已经完全失效,某些流行的第三方库(如ACRA)用有漏洞的实现覆盖了内置的SSL证书认证模块.

3.5 恶意软件变形技术

为规避恶意软件检测器和分类器的自动检测,恶意软件采用了一系列自保护的变形(transformation)技术.有的文献,如文献[102],也称其为隐身(stealth)技术,包括熟知的混淆、代码加密、密钥置换、动态加载、代码反射和本地代码执行等.从下一节的分析可以看出,这些措施对于反制商业反恶意软件的侦测还是十分有效的.

Rastogi等人[19]构建了一个包含各类恶意软件变形技术的系统框架DroidChameleon,对变形方法进行了分析.他们将变形分为以下3类:平凡的变形、通过静态分析可能发现的变形以及只有通过动态分析才能发现的变形.其中,平凡的变形不需要进行代码级的改变或AndroidManifest中存储的元数据的改变,例如重打包、反汇编与再汇编;通过静态分析可能发现的变形包括重命名包、重命名标识符、数据加密、代码重排序、无用码插入、组合变形技术等;只有通过动态分析才能发现的变形包括代码反射与字节码加密.

文献[108]指出:许多反恶意软件使用已知恶意软件的平凡特征,例如包名、类名和方法名作为检测特征,所以,一些平凡变形仍然可以逃避基于特征的反恶意软件检测.

3.6 商业反恶意软件健壮性评估

许多研究者对主流商业反恶意软件的健壮性进行了评估.

Zhou等人[3]通过一年多的积累,采集了从2010年8月~2011年10月的49个不同族中的1 260个Android恶意软件样本,经过对它们的安装与运行特征进行了系统分析之后得出以下结论:(1) 86.0%的恶意软件重打包合法的app,增加恶意载荷;(2) 36.7%的恶意软件通过平台级的漏洞利用进行提权攻击;(3) 93.0%的恶意软件具有使用户手机成为僵尸的能力.令人遗憾的是,他们选择了4个有代表性的移动反病毒软件:AVG(AVG antivirus free v2.9),Lookout(lookout security & antivirus v6.9),Norton(norton mobile security lite v2.5.0.379)和TrendMicro (TrendMicro mobile security personal edition v2.0.0.1294),它们 在最佳和最坏情形下只能分别检测出79.6%和20.2%的恶意软件.结论是:商业反恶意软件不够健壮,亟需下一代反移动恶意软件的解决方案.

Rastogi等人[19]通过他们构建的框架DroidChameleon对下面10个有代表性的Android反恶意软件(括弧外是公司名称,括弧内是软件名称)进行了系统的分析:AVG(antivirus free),Symantec(norton mobile security), Lookout(lookout mobile security),ESET(ESET mobile security),Dr. Web(Dr. Web anti-virus light),Kaspersky (Kaspersky mobile security),Trend micro(mobile security personal Ed.),ESTSoft(ALYac Android),Zoner(zoner antivirus free),Webroot(Webroot security & antivirus),也得出了相似的结论:商业反恶意软件亟待提高对抗恶意软件变形技术的能力.

Zheng等人[20]也研究了Android反恶意软件的健壮性,他们构造了一个自动和可扩展的平台ADAM,对商业反病毒系统进行了压力测试.但他们只实现了文献[19]中恶意软件变形的一个子集.

4 Android 安全分析

Android安全分析基本上可以分为静态分析和动态分析两类.也有研究者将Android安全分析分为基于特征与基于机器学习的分析两类.

4.1 静态分析

静态分析在安装前检测Android应用程序中的安全漏洞,通常的分析步骤是:下载Android系统的应用程序安装包(Android application package file,简称APK),通过如Ded[109]和Dex2Jar[110]之类的工具进行反编译,将APK文件反编译为Java源文件或JAR文件,然后对其进行源代码级的解析.静态分析的优点是无需运行代码,无需像动态分析那样改写Android系统源码、要求用户对Android系统进行重定制和安装定制版的ROM,因此,速度快,轻量级.静态分析的缺点是:因为无法真实模拟程序的动态运行,所以存在误报问题.

基于权限的检测工具Kirin[111]是早期有代表性的静态分析方法之一,它通过定义的一组规则识别危险的权限组合,其缺点是误报率较高.其他的静态分析解决方案还有SCanDroid[112],DroidChecker[113],Chex[114], AndroidLeaks[115],Epicc[116]等,但这些工具仍然有其局限性:有的未进行组件间通信分析,有的未考虑Android的事件驱动编程范式.CoChecker[117]对此进行了改进,提出基于Android API调用将泄露路径分为两类的方法:权能泄露路径和敏感数据泄露路径.CoChecker可以自动识别Android应用中的这两类泄露路径,因为两种泄露路径都可能跨越多个组件,因此,进行ICC分析是一项基本任务.

静态分析的方法多种多样,例如,ScanDal[118]以Dalvik虚拟机字节码为输入,检测Android应用程序的私密信息泄露.Chex[114]是基于组件的静态分析方法.SCanDroid[112]使用数据流分析方法进行静态分析,从应用的AndroidManifest.xml文件中提取权限,然后自动检测应用的数据流是否与这些权限一致.DroidChecker[113]使用控制流图搜索和脏数据分析方法自动分析可能的敏感数据泄露路径.

机器学习方法也可以用于静态分析,如文献[14, 53]等.

4.2 动态分析

相对于轻量级的静态分析,动态分析则是重量级的程序运行时的分析.一般情形下,需对Android系统进行重新定制与改写,包括改写安全机制;在原生Android系统中加入监视器,实时监视数据的流向;在危险函数调用时,检测所需权限等.动态分析的优点是检测精度较高,缺点是重量级:需要修改Android系统源码,形成用户全新定制的操作系统,同时需要通过更新ROM安装这种定制系统.早期有代表性的动态分析工具如Stowaway[33, 119],重新定制Android系统的工具如Quire[ 120].Felt等人[33]分析了940个Android应用程序,发现其中三分之一存在突破最小特权原则的安全威胁.

TaintDroid[121]提出了一种动态脏数据检测技术:对敏感数据进行污点标记,当这些数据通过程序变量、文件和进程间通信等途径扩散时进行跟踪审查.如果污点数据在一个泄露点(如网络接口)离开系统,TaintDroid就在日志中记录数据标记、传输数据的应用程序和数据流向目的地,实现对多种敏感数据泄露源点的追踪.但TaintDroid只考虑数据流,未对控制流(程序间交互、组件间交互、进程间交互)进行分析.TaintDroid,Asdroid[122]和Crowdroid[123]等都是一类基于行为的动态检测方法.

XManDroid[97]是一种基于系统策略的动态分析方法,它扩展了Android应用架构,由3个模块组成:运行监控器、应用安装器和系统策略安装器.运行监控器是XManDroid的核心,由访问监控器、决策器、系统视图、权限、系统策略和决策组件构成.其中,新增组件的功能如下:决策器判断是否建立新的组件间通信链接;系统视图组件维护运行系统的状态;系统策略组件是系统策略规则数据库;决策组件是存储决策的数据库.应用安装器包括Android标准组件Package Manager和Permissions以及新增的系统视图组件.由于安装新的应用程序会改变系统状态,故扩展了Package Manager的功能,使其可与系统视图进行通信.系统策略安装器是新增模块,由策略安装器、系统策略、决策和系统视图这4个新组件构成,提供在Android中间件层增加或更新系统策略的功能.XMandroid通过系统策略检查算法判断能否建立新的组件间通信链接,有效地防止了运行时的权限提升. XMandroid的局限性是:(i) 未考虑通过隐蔽通道实现的权限提升;(ii) 仅考虑了ICC,但应用程序间的通信还包括标准的Linux进程间通信机制等;(iii) 未考虑其他公开信道,如互联网Socket或文件系统通信等.

机器学习方法也可用于动态分析,如文献[51, 59]等.

4.3 机器学习分析方法

近年来,许多研究者尝试借助机器学习方法[41, 44, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 123, 124, 125, 126]进行恶意软件的分类与检测.用机器学习方法构成的分类器可以模拟Android应用的行为,区分良性与恶意软件.分类器通过分析应用的静态或动态行为特征做出判断,静态特征可以通过反编译Android Dalvik字节码获得的结果进行抽取;动态特征可以通过观察程序运行时的行为进行搜集.通过Android权限、代码或运行,可以抽取到各种不同类型的特征.

采用什么样的机器学习方法是Android分类器是否有效的关键.另外一些重要因素是,提取什么特征、如何提取特征以及提取多少特征等问题.目前,这些问题都还没有一个完美的答案.在Android中,常用的机器学习方法包括k-Means、逻辑回归(logistic regression)、K-最近邻(K-nearest-neighbor,简称KNN)、直方图(histogram)、决策树(decision tree)、贝叶斯网络(Bayesian network)、朴素贝叶斯(naïve Bayes)、随机树(random tree)、随机森林(random forest)、支持向量机(support vector machine,简称SVM)等.

如何度量Android分类器是否有效呢?4个基本指标是:真阳性(true positive,简称TP),表示正确分类为恶意软件的恶意样本个数;假阳性(false positive,简称FP),表示错误分类为恶意软件的良性样本个数;真阴性(true negative,简称TN),表示正确分类为良性软件的良性样本个数;假阴性(false negative,简称FN),表示错误分类为良性软件的恶意样本个数.由此可以构成下面的一些常用指标:

● 检测率(detection rate),亦即真阳性率TPR=TP/(TP+FN),有时也称为召回率(recall rate),表示所有恶意样本中正确分类为恶意软件的比例;

● 误报率(false alarm rate),亦即假阳性率FPR=FP/(FP+TN),表示所有正常样本中错误分类为恶意软件的比例;

● 漏报率(missed detection rate),亦即假阴性率FNR=FN/(TP+FN),表示所有恶意样本中错误分类为良性软件的比例;

● 分类精度(accuracy,简称ACC),是所有正确分类的样本与所有样本之比,即:

ACC=(TP+TN)/(TP+TN+FP+FN).

此外,经常与召回率一起讨论的指标有正确率(precision),系指真正的恶意软件在分类为恶意软件中的比例,即:正确率=TP/(TP+FP).

为权衡不同指标之间的关系,还有一些常用的综合指标,例如反映TPR和FPR之间关系的指标有基于ROC (receiver operating characteristic)曲线的AUC(area-under-curve).其他综合性指标还包括:F-measure或平衡F1-score,系指准确率和召回率的调和平均值,亦即(F-measure=2×(正确率×召回率)/(正确率+召回率));F2:类似于F1,但召回率权重是正确率权重的2倍;F1/2:类似于F1,但正确率权重是召回率权重的2倍.

Puma[53]应用机器学习方法进行静态分析,抽取基于权限使用的特征,并评估不同分类器的有效性,包括随机树、随机森林、朴素贝叶斯和贝叶斯网络等.实验结果是:

● 如果用分类精度ACC指标衡量,则通过50棵树训练的随机森林算法最优:ACC=86.41%;

● 如果用召回率TPR指标衡量,则通过10棵树训练的随机森林算法最优:TPR=92%;

● 如果用AUC指标衡量,则随机森林算法最优:AUC=0.92.

Puma方法的缺点是:假阳性率(误报率)偏高,即,所有算法的FPR都不低于11%.

Andromaly[51]应用机器学习方法进行动态分析,是一个轻量级的检测器(只考虑CPU、内存以及电池的消耗).作为一种动态分析方法,Andromaly进行了实时监控,搜集各种系统度量值,如CPU使用、数据通过网络的传输量、活动进程数以及电池使用等.Andromaly由以下4个主要模块构成.

(i) 特征提取模块:与Android内核和应用架构进行通信,提取所需特征;

(ii) 处理器模块:接收来自主服务模块的特征向量,由威胁评估单元(threat weighting unit,简称TWU)做出最终判断.处理器模块既可以是基于规则、基于知识的分类器,也可以是使用机器学习方法的异常检测器;

(iii) 主服务模块:负责协调特征提取、恶意软件检测和报警等各种功能的实现;

(iv) 图形用户接口:用于应用参数配置、启动和停止应用、报警等.

Andromaly通过40个良性软件样本和4个自制的恶意软件样本进行实验,评估不同分类器的有效性,包括k-Means、逻辑回归、直方图、决策树、朴素贝叶斯和贝叶斯网络等.Andromaly的不足之处是样本量太少,未采用真实的恶意软件样本,最好的算法具有较高的误报率,即,FPR大于10%.

5 Android 安全扩展方案

研究者针对Android的安全缺陷从不同角度提出了多种多样的安全扩展方案,分别针对的是Android的不同层级或者是它们的组合.目前,大多数Android的安全扩展方案是针对中间件层的.

Bugiel等人[98]总结了近年来较为著名的一些Android安全扩展方案,如图 12所示.

图 12 Android安全扩展方案 Fig.12 Android security extension proposals

其中,Porscha[127]提出了一种面向策略的安全内容处理方案.Apex[73]使用户能够在app安装时选择性地赋予或拒绝权限.CRePE[128]可以实现上下文相关的策略.Paranoid Android[129]可以检测病毒和运行时的攻击. Kirin[71, 111]是一种安全策略实现机制,通过基于特定危险权限的组合定义安全规则.如果应用程序不符合Kirin安全规则,用户可以选择不安装该app.静态分析工具[13, 99]可用于检测存在安全漏洞的应用接口;静态分析工

[33]可用于分析应用程序是否遵循最小特权原则.前文分析过的TaintDroid[121]则是一种动态脏数据检测技术.

Saint[72]提出了一种细粒度的访问控制模型,使应用程序开发者可以定义运行时相关的安全策略,从而保护app暴露的应用接口.安全决策基于签名、配置与上下文,可在安装时与运行时实现.应用程序开发者对每个接口赋予适当的安全策略,即:规定调用者访问接口时需要什么权限/配置/签名,从而防止“困惑代理”的攻击.但是,Saint仍然不能防止“合谋”攻击.其他问题还有:如果这些保护被调用者的安全策略与调用程序的性质发生冲突,则拒绝组件间通信,将会导致调用故障或崩溃等问题.此外,许多应用程序开发者并不是信息安全专业人员,由他们自行定义的安全策略未必考虑到所有的安全威胁.更糟糕的是,恶意app开发者会利用这些安全策略发起合谋攻击.

Quire[120]在Android中引入了两个新的安全机制:其一,Quire透明地追踪设备进程间通信(IPC)的调用链,使应用程序可以选择采用调用者的简约权限或全部权限;其二,Quire建立了一个轻量级的签名机制,使任何应用都可以创建签名语句,并可被相同手机上的任意应用验证.此外,Quire扩展了Linux内核中的网络模块,可以分析远程过程调用(remote procedure calls,简称RPC).因为IPC接收者知道调用者和完整的调用链,Quire可以防止来自不可信代理的IPC调用和欺骗性的请求.如果发起IPC调用的应用没有显式地获得相应的权限,Quire将拒绝IPC请求,因此能够防止“困惑代理”的攻击.尽管Quire可以防止提权攻击中重要的一类——“困惑代理”攻击,但因为Quire本质上是以应用为中心的,所以它仍然无法防止提权攻击中的另一类——“合谋攻击”.因为Quire是一个轻量级的解决方案,增加新的安全机制后对性能的影响很小.

“IPC检查”[96]是一种类似于Quire的防止“困惑代理”攻击的解决方案.当应用程序收到来自一个具有较低权限的消息时,“IPC检查”降低了该应用程序的权限级别.一个问题是:尽管接收者的权限降低为发送者的权限,但接收者的应用实例仍然驻留在某个沙盒之中,未进行有效隔离,并能不受限地进行通信.最后,该方案也无法阻止合谋攻击,并且增加了可观的额外开销.

迄今,大部分的安全扩展方案都是针对Android中间件层访问控制的,并未涉及Linux DAC机制的改进.但是任何通过中间件实现的访问控制模型都依赖于内核层的控制,从而保证访问控制的实现不可旁路.有鉴于此,研究者[130, 131]提出了将SELinux[132, 133]引入Android的建议,夯实了Android底层操作系统的安全程度.

SELinux是2001年3月美国国家安全局NSA发布的安全增强版Linux,它在Linux内核实现了灵活和细粒度的强制存取控制,并能够灵活地支持多种安全策略.SELinux的安全体系结构称为Flask(Flask security architecture),如图 13所示.安全策略和通用接口一起封装在与操作系统相对独立的组件中,通用接口是用于获得安全策略决策的.这个单独的组件称为安全服务器,它是一个内核子系统.Flask由两部分组成:策略(policy)和实施(enforcement),策略封装在安全服务器中,实施由对象管理器具体执行.

图 13 SELinux的安全体系结构 Fig.13 Security architecture of SELinux

但是,将SELinux引入Android需要解决许多问题,包括内核、用户空间和策略配置这3个方面的挑战.

● 例如内核方面,Android的文件系统是YAFFS,并非主流Linux内核的一部分;Android对Linux进行了若干内核级增强,如ashmem和Binder IPC机制等,但SELinux均不支持;

● 例如用户空间方面,在内核以上,Android均与传统的Linux不同,包括Bionic(非POSIX C程序库)和Dalvik虚拟机等,过去将SELinux集成到Linux的工作均无法借鉴.

类似的工作还包括文献[134],该文作者不仅建议应用安全操作系统SELinux,还建议将可信计算(trusted computinhg)技术[135, 136]引入智能手机.

基于L4Linux[137]的L4Android[138]和Cells[139]建议在一个手机上使用多个操作系统,实现更好的隔离与安全.其中,L4Android的目标是在微内核之上的虚拟机中运行Android.

ARM架构下的TrustZone可以实现一个额外的处理器模式,用于建立一个隔离与安全环境.有的文献[140]建议应用TrustZone构建Android平台安全机制.但也有学者认为:TrustZone安全环境适用于安全引导,并不适用于运行态.并且,通常智能手机生产商不允许客户软件在TrustZone环境中运行.

此外,TrustZone可以实现对内核的安全监测,保证内核在加载时和运行时的完整性.三星公司为它的某些高端手机,如GALAXY Note 3推出了称为Knox[141]的Android安全套件.Knox包含了底层的可定制安全引导和基于TrustZone的完整性测量(integrity measurement architecture,简称TIMA)、系统层的Android安全增强SE- Android以及应用层的Knox容器、加密文件系统和VPN.

动态检测除内核之外,还可以通过QEMU(quick emulator)[142]对Android系统进行全面监控.其中,QEMU是一款著名的模拟器,具有速度快和跨平台等特点.

文献[143, 144]从更广的角度深入分析了移动设备(不限于Android平台)的可信运行问题.Vasudevan等人认为,可信运行的移动设备应具有下述基本安全特征:(1) 隔离的运行(isolated execution);(2) 安全存储(secure storage); (3) 远程认证(remote attestation);(4) 安全供给(secure provisioning);(5) 可信路径(trusted path).其中,安全供给指的是一种机制,当发送数据到某个软件模块或运行某个设备时,能够保障数据的机密性与完整性.鉴于当前大多数移动设备是基于ARM体系结构的,文献详尽地分析了ARM平台的硬件与安全架构,讨论平台硬件组件能否有效地实现上述安全特征.例如,关于隔离运行,文献分析了TrustZone扩展如何实现安全域与一般域的隔离运行;如何通过将CPU状态分为两个不同的域,并与TrustZone-可感知内存管理单元(TrustZone-aware memory management units,简称MMU)等模块相结合实现内存隔离;如何通过安全域和一般域实现外部设备的隔离以及如何实现DMA保护、硬件中断隔离和基于虚拟化的隔离运行等.Vasudevan等人指出:尽管ARM平台与安全体系结构提供了一系列硬件安全特征,但由于该体系结构只是规范,因此生产厂商实现时仍然存在重大挑战,填平设计与实现之间的鸿沟绝非易事.最后,文献[143, 144]对各种相关方的角色——学术界、APP开发人员、平台集成商和硬件生产厂商提出了具体建议.

6 其他研究成果

近年来,关于Android安全的研究取得了丰硕的成果.除前文提及的以外,其他一些有意义的研究成果总结如下.

6.1 扩展Android安全功能的可编程接口

当前提出了多种扩展Android安全功能的方案,能否开发一个统一的接口,方便地接纳第三方提出的安全模型呢?如何设计和开发这种接口呢?

Watson[145]指出:历史证明,早期的可信操作系统单纯地通过类型实现(type enforcement),信息流控制或权能(capability)等不能满足当前应用的需要.类似于可信计算基(trusted computing base,简称TCB),访问监控器是操作系统中的一个重要概念.访问监控器是一个独立和自包含的、不可旁路的和紧致的(因而是可验证的)访问控制中枢,出现在最重要的操作系统构架之中,包括著名的通用访问控制框架(generalized framework for access control,简称GFAC)、基于规则集的访问控制(rule set-based access control,简称RSBAC)和Flask安全体系结构.在此基础上,强制访问控制框架先后在操作系统Linux和BSD 上分别通过应用LSM(linux security modules)[146]和TrustedBSD[147]实现.随后,Apple OS X和iOS也采用了这一技术路线,成功地扩展了操作系统(包括桌面和移动)的安全功能.

Watson认为:可扩展的操作系统安全接口必须是可编程的,并且可编程和二元接口的稳定性非常关键.当前提出的一些方案(包括各种固定和移动平台)往往忽视了应用编程接口(application programming interface,简称API)、应用二元接口(application binary interface,简称ABI)、内核编程接口(kernel programming interface,简称KPI)和内核二元接口(kernel binary interface,简称KBI)的可持续性(sustainability),即,所建立的原型系统只考虑了当前需求,因而往往是短命的.

Heuser等人[148]在Android平台上实现了操作系统安全功能的可扩展性,他们依据上述原则设计了一种扩展Android安全功能的可编程接口——Android安全模块(Android security module,简称ASM),通过一系列“授权钩子(authorization hook)”,可使安全app开发人员编程和定义新的Android安全模块.ASM的桥接器(ASM bridge)提供了一个访问监控器接口,使授权钩子可以在整个Android操作系统范围内进行部署.这些钩子共分为5类:生命周期钩子、操作系统服务钩子、操作系统内容提供器钩子、第三方应用钩子和LSM钩子.例如,生命周期钩子包括解析intent、开启activity和服务、绑定服务、广播接收器的动态注册和接收广播intent.

类似的工作还有文献[149],他们建立了一个通用的可扩展Android安全框架(Android security framework,简称ASF),可以开发和集成现有的基于代码的安全模型.他们的工作也是吸取了LSM和BSD MAC架构的成功经验.为证明其框架的有效性,他们实例化了一些知名的安全模型,如类型实现TE、上下文相关的访问控制、中国墙策略和内联访问控制(inlined access control).

6.2 Android的APP运行保护

Android的APP运行保护是Android安全的一个重要组成部分,文献[150]提出的Aurasium系统是一种Android APP策略实现的实际解决方案.Aurasium自动重新封装APP,并增加用户级沙箱和策略实现代码,拦截APP与操作系统之间的所有交互,实现对应用程序恶意行为的监控,如秘密发送短信给高收费账户、提取用户敏感信息、访问恶意IP地址、实施提权攻击等.一个APP与操作系统和其他APP的交互都是可见的,包括: Internet连接connect();IPC B inder通信ioctl();文件系统操作write(),read();资源访问Ioctl(),read,write()以及Linux系统调用fork(),execvp()等.

与其他解决方案不同,Aurasium的一个显著特点是无需修改Android操作系统且无需root手机就可以增强安全性与用户的隐私保护,并且具有良好的性能.实验结果表明,Aurasium具有很高的重封装成功率.从第三方应用商店抓取的3 491个APP中,Aurasium的重封装成功率为99.6%(3 476),而1 260个已知恶意应用的重封装成功率为99.8%(1 258).

6.3 自动补丁生成

Zhang等人[151]提出的AppSealer是一种自动生成补丁的工具,当发现一个具有组件劫持漏洞的Android应用程序时,APPSealer可以在无源码的条件下自动生成禁用该漏洞的补丁.他们通过16个真实的样本验证了该工具的有效性.经优化后,补丁代码只占整个程序的一小部分(平均为15.9%).APPSealer增加的平均运行开销约为2%.

6.4 Android生态系统中的权限演变研究

Wei等人[49]首次关注自2008年问世以来,Android生态系统(Android平台、第三方应用和预装应用)中权限的演变和使用情况.他们的研究表明:

● 从平台角度看:Android权限集不断扩展,但不是以提供更细粒度的权限为目标,而是为访问新的硬件功能提供安全保障.特别地,Dangerous权限集的数量也在不断增多;

● 从第三方应用和预装应用角度看:大量应用并未遵守最小特权原则,而是存在大量过多申请权限的情形.值得注意的是:许多预装应用使用大量高级别的权限,带来很大的安全隐患.因此,Wei等人认为, Android生态系统的演变并未朝着更加安全的方向发展.

随着Android系统的不断发展,新的权限不断被加入到权限系统之中.例如,Android 2.0有122个权限,而Android 4.0.3中的权限数量达到165个.同时,某些旧的权限也会舍弃不用,导致Android的权限系统越来越复杂.例如:Android API level 9中引入了新权限NFC,允许应用软件读取近场通信传感器中的数据;Android API level 14中引入了新权限READ_PROFILE,用于读取用户的个人资料;Android API level 8从权限系统中删除了READ_OWNER_DATA权限.于是,用户只有通过不断学习,充分理解新加入的权限说明,才能在安装软件时从Android权限警告中获取足够的信息,从而做出正确的决定.鉴于Android系统每隔数月就有较大的版权更新,并引入较多新的权限,这为用户提出了很高要求.

7 结束语

本文从Android体系结构、设计原则、安全机制和面临的主要威胁出发,从Android恶意软件分类与检测、静态分析与动态分析、机器学习方法、安全扩展方案等多维角度对Android安全的研究现状与进展进行了详尽的分析与总结.然而,什么是保护Android安全的最佳方案目前仍不明朗,比较一致的意见是:需要多种解决方案的组合,包括底层操作系统的安全加固、防恶意软件的应用、权限机制的细粒度化、加强API调用的监控等.

Android安全不是孤立的问题,在考虑Android安全改进与加固的方案时,必须同时兼顾性能、效率与易用性的问题.Android安全整体上弱于黑莓、苹果、微软等,但其销售量与认可度却远远超过了其竞争对手,有力地证明了这一点.这也是面对如此众多的安全改进建议时,Google的认可与采纳却十分缓慢与慎重的原因.

笔者认为:今后我们仍需在理论上继续研究Android安全问题,深入挖掘其内涵,探索新方法,开发新工具.与此同时,我们也必须从实际出发,针对不同的需求提出相应的解决方案,例如对特定的用户群提供隔离一般应用与安全应用的机制,对安全需求强烈的用户群提供底层操作系统加固方案等.总之,Android安全的有效增强需要理论研究者、app开发者、广大用户、智能手机运营商与Google的通力配合才能得到满意的解决方案.

致谢 作者感谢与课题组姜申坪、尚雪、陈昊、刘镇和徐钊等同志进行的有益讨论,也感谢对本文提出宝贵修改意见的评审专家.

参考文献
[1] Motive Security Labs. Malware report—H2. 2014. http://boletines.prisadigital.com/MKT2015019837EN_2H2014_Malware_Report.pdf
[2] Mawston N. Strategy Analytics. Android shipped 1 billion smartphones worldwide in 2014. 2014. http://www.strategyanalytics.com/ default.aspx?mod=reportabstractviewer&a0=10539
[3] Zhou Y, Jiang X. Dissecting android malware: Characterization and evolution. In: Proc. of the 2012 IEEE Symp. on Security and Privacy (SP). 2012. 95-109 .
[4] Felt AP, Finifter M, Chin E, Hanna S, Wagner D. A survey of mobile malware in the wild. In: Proc. of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM 2011). 2011. 3-14 .
[5] La Polla M, Martinelli F, Sgandurra D. A survey on security for mobile devices. IEEE Communications Surveys & Tutorials, 2013,15(1): 446-471 .
[6] Enck W. Defending users against smartphone apps: Techniques and future directions. In: Proc. of the 7th Int’l Conf. (ICISS 2011). LNCS 7093, Springer-Verlag, 2011.49-70 .
[7] Fledel Y, Shabtai A, Potashnik D, Elovici Y. Google Android: An updated security review. In: Proc. of the 2nd Int’l ICST Conf. (MobiCASE 2010). Springer-Verlag, 2010. 401-414 .
[8] Zhang YQ, Wang K, Yang H, Fang ZJ, Wang ZQ, Cao C. Survey of Android OS security. Journal of Computer Research and Development, 2014,51(7):1385-1396 (in Chinese with English abstract) .
[9] Shabtai A, Fledel Y, Kanonov U, Elovici1 Y, Dolev S. Google Android: A state-of-the-art review of security mechanisms. arXiv:0912. 5101 [cs.CR], 2009. http://arxiv.org/ftp/arxiv/papers/0912/0912.5101.pdf
[10] Burns J. Developing secure mobile applications for Android. 2008. https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/isec_securing_android_apps.pdf
[11] Enck W, Ongtang M, McDaniel P. Understanding Android security. IEEE Security & Privacy, 2009,7(1):50-57 .
[12] Jiang SL, Wang JS, Zhang T, Chen R. A summary on Android security. Computer Applications and Software, 2012,29(10): 205-210 (in Chinese with English abstract) .
[13] Enck W, Octeau D, McDaniel P, Chaudhuri S. A study of Android application security. In: Proc. of the 20th USENIX Security Symp. (USENIX 2011). 2011. 2-29. https://www.usenix.org/legacy/event/sec11/tech/slides/enck.pdf
[14] Huang CY, Tsai YT, Hsu CH. Performance evaluation on permission-based detection for Android malware. In: Proc. of the Int’l Computer Symp. (ICS 2012). Springer-Verlag, 2012. 111-120 .
[15] Wang W. The system based on the Android principle analysis of malicious program. Netinfo Security, 2012,10:71-76 (in Chinese with English abstract) .
[16] Aung Z, Zaw W. Permission-Based android malware detection. Int’l Journal of Scientific & Technology Research, 2013,2(3):228-234.
[17] Sanz B, Santos I, Laorden C, Ugarte-Pedrero X, Nieves J, Bringas PG. MAMA: Manifest analysis for malware detection in Android. Cybernetics and Systems, 2013,44(6-7):469-488 .
[18] Sato R, Chiba D, Goto S. Detecting Android malware by analyzing manifest files. In: Proc. of the Asia-Pacific Advanced Network, Vol.36. 2013. 23-31 .
[19] Rastogi V, Chen Y, Jiang X. Droidchameleon: Evaluating Android anti-malware against transformation attacks. In: Proc. of the 8th ACM SIGSAC Symp. on Information, Computer and Communications Security (ASIACCS 2013). 2013. 329-334 .
[20] Zheng M, Lee PPC, Lui JCS. ADAM: An automatic and extensible platform to stress test Android anti-virus systems. In: Proc. of the 9th Int’l Conf. (DIMVA 2013). LNCS 7591, Springer-Verlag, 2013. 82-101 .
[21] Su MY, Chang WC. Permission-Based malware detection mechanisms for smart phones. In: Proc. of the 2014 IEEE Int’l Conf. on Information Networking (ICOIN 2014). 2014. 449-452 .
[22] Yerima SY, Sezer S, McWilliams G, Muttik I. A new Android malware detection approach using bayesian classification. In: Proc. of the 2013 IEEE 27th Int’l Conf. on Advanced Information Networking and Applications (AINA2013). 2013. 121-128 .
[23] Grace M, Zhou Y, Zhang Q, Zou S, Jiang X. Riskranker: Scalable and accurate zero-day Android malware detection. In: Proc. of the 10th Int’l Conf. on Mobile Systems, Applications, and Services (MobiSys 2012). 2012. 281-294 .
[24] Li JH, Mu DJ, Yang MK, Hu W. Design on Android malware behavior analysis system. Journal of Beijing University of Posts and Telecom, 2014,37(S1):104-107 (in Chinese with English abstract).
[25] Elish KO, Shu X, Yao D, Ryder BG, Jiang X. Profiling user-trigger dependence for Android malware detection. Computers & Security, 2015,49(C):255-273 .
[26] Wen WP, Mei R, Ning G, Wang LL. Malware detection technology analysis and applied research of Android platform. Journal on Communications, 2014,8:78-85 (in Chinese with English abstract) .
[27] Protsenko M, Müller T. Android malware detection based on software complexity metrics. In: Proc. of the 11th Int’l Conf. (TrustBus 2014). LNCS 8647, Springer-Verlag, 2014. 24-35 .
[28] Zhang W, Yan HB, Wen WP. Implementation of a malware detect tool on Android. Netinfo Security, 2013,1:27-32 (in Chinese with English abstract) .
[29] Deshotels L, Notani V, LakhotiaL A. DroidLegacy: Automated familial classification of Android malware. In: Proc. of the ACM SIGPLAN on Program Protection and Reverse Engineering Workshop (PPREW 2014). 2014 .
[30] Li T, Dong H, Yuan CY, Du YJ, Xu GA. Description of Android malware feature based on Dalvik instructions. Journal of Computer Research and Development, 2014,51(7):1458-1466 (in Chinese with English abstract) .
[31] Faruki P, Laxmi V, Bharmal A, Gaur MS, Ganmoor V. AndroSimilar: Robust signature for detecting variants of Android malware. Journal of Information Security and Applications, 2014,22:66-80 .
[32] Fang Z, Han W, Li Y. Permission-Based Android security: Issues and countermeasures. Computers & Security, 2014,43:205-218 .
[33] Felt AP, Chin E, Hanna S, Song D, Wagner D. Android permissions demystified. In: Proc. of the 18th ACM Conf. on Computer and Communications Security (CCS 2011). 2011.627-638 .
[34] Frank M, Ben D, Felt AP, Song D. Mining permission request patterns from Android and facebook applications. In: Proc. of the 2012 IEEE 12th Int’l Conf. on Data Mining (ICDM 2012). 2012. 870-875 .
[35] Zhu J, Guan J, Yang Y, Yu L, Sun H, Chen Z. Permission-Based abnormal application detection for Android. In: Proc. of the 14th Int’l Conf. (ICICS 2012). LNCS 7618, Springer-Verlag, 2012. 228-239 .
[36] Felt AP, Ha E, Egelman S, Haney A, Chin E, Wagner D. Android permissions: User attention, comprehension, and behavior. In: Proc. of the Symp. on Usable Privacy and Security (SOUPS 2012). 2012 .
[37] Holavanalli S, Manuel D, Nanjundaswamy V, Rosenberg B. Flow permissions for Android. In: Proc. of the 2013 IEEE/ACM 28th Int’l Conf. on Automated Software Engineering (ASE 2013). 2013. 652-657 .
[38] Moonsamy V, Rong J, Liu S. Mining permission patterns for contrasting clean and malicious Android applications. Future Generation Computer Systems, 2014,36:122-132 .
[39] Zhang Y, Yang M, Xu B, Yang Z, Gu G, Ning P, Wang XS, Zang B. Vetting undesirable behaviors in Android apps with permission use analysis. In: Proc. of the 2013 ACM SIGSAC Conf. on Computer & Communications Security (CCS 2013). 2013. 611-622 .
[40] Struse E, Seifert J, Üllenbeck S, Rukzio E, Wolf C. Permissionwatcher: Creating user awareness of application permissions in mobile systems. In: Proc. of the 3rd Int’l Joint Conf. (Ambient Intelligence 2012). LNCS 7683, Springer-Verlag, 2012. 65-80 .
[41] Sarma BP, Li N, Gates C, Potharaju R, Nita-Rotaru C. Android permissions: A perspective combining risks and benefits. In: Proc. of the ACM Symp. on Access Control Models and Technologies (SACMAT 2012). 2012. 13-22 .
[42] Orthacker C, Teufl P, Kraxberger S, Lackner G, Gissing M, Marsalek A, Leibetseder J, Prevenhueber O. Android security permissions—Can we trust them. In: Proc. of the 3rd Int’l ICST Conf. (MobiSec 2011). Springer-Verlag, 2012. 40-51 .
[43] Felt AP, Egelman S, Finifter M, Akhawe D, Wagner D. How to ask for permission. In: Proc. of the 7th USENIX Workshop on Hot Topics in Security (HotSec 2012). 2012. https://www.usenix.org/system/files/conference/hotsec12/hotsec12-final19.pdf
[44] Barrera D, Kayacik HG, van Oorschot PC, Somayaji A. A methodology for empirical analysis of permission-based security models and its application to Android. In: Proc. of the 17th ACM Conf. on Computer and Communications Security (CCS 2010). 2010. 73-84 .
[45] Kelley PG, Consolvo S, Cranor LF, Jung J, Sadeh N, Wetherall D. A conundrum of permissions: Installing applications on an Android smartphone. In: Proc. of the Financial Cryptography and Data Security. LNCS 7398, Springer-Verlag, 2012. 68-79 .
[46] Rassameeroj I, Tanahashi Y. Various approaches in analyzing Android applications with its permission-based security models. In: Proc. of the 2011 IEEE Int’l Conf. on Electro/Information Technology (EIT 2011). 2011. 1-6 .
[47] Bugiel S, Davi L, Dmitrienko A, Fischer T, Sadeghi AR, Shastry B. Poster: The quest for security against privilege escalation attacks on Android. In: Proc. of the 18th ACM Conf. on Computer and Communications Security (CCS 2011). 2011. 741-744 .
[48] Egners A, Meyer U, Marschollek B. Messing with Android’s permission model. In: Proc. of the 2012 IEEE 11th Int’l Conf. on Trust, Security and Privacy in Computing and Communications (TrustCom 2012). 2012. 505-514 .
[49] Wei X, Gomez L, Neamtiu I, Faloutsos M. Permission evolution in the Android ecosystem. In: Proc. of the 28th Annual Computer Security Applications Conf. (ACSAC 2012). 2012. 31-40 .
[50] Felt AP, Greenwood K, Wagner D. The effectiveness of install-time permission systems for third-party applications. Technical Report, No. UCB/EECS-2010-143, 2010.
[51] Shabtai A, Kanonov U, Elovici Y, Glezer C, Weiss Y. Andromaly: A behavioral malware detection framework for Android devices. Journal of Intelligent Information Systems, 2012,38(1):161-190 .
[52] Liu X, Liu J. A two-layered permission-based Android malware detection scheme. In: Proc. of the 2014 2nd IEEE Int’l Conf. on Mobile Cloud Computing, Services, and Engineering (MobileCloud 2014). 2014. 142-148 .
[53] Sanz B, Santos I, Laorden C, Ugarte-Pedrero X, Bringas PG, Álvarez G. Puma: Permission usage to detect malware in Android. In: Proc. of the Int’l Joint Conf. CISIS 2012-ICEUTE 2012-SOCO 2012 Special Sessions. Springer-Verlag, 2013. 289-298 .
[54] Wolfe B, Elish K, Yao DF. High precision screening for Android malware with dimensionality reduction. In: Proc. of the IEEE 2014 13th Int’l Conf. on Machine Learning and Applications (ICMLA 2014). 2014. 21-28 .
[55] Shabtai A, Fledel Y, Elovici Y. Automated static code analysis for classifying Android applications using machine learning. In: Proc. of the IEEE 2010 Int’l Conf. on Computational Intelligence and Security (CIS 2010). 2010. 329-333 .
[56] Aafer Y, Du W, Yin H. DroidAPIMiner: Mining API-level features for robust malware detection in Android. In: Proc. of the 9th Int’l ICST Conf. (SecureComm 2013). Springer-Verlag, 2013. 86-103 .
[57] Wolfe B, Elish KO, Yao D. Comprehensive behavior profiling for proactive Android malware detection. In: Proc. of the 17th Int’l Conf. (ISC 2014). LNCS 8783, Springer-Verlag, 2014. 328-344 .
[58] Arp D, Spreitzenbarth M, Hubner M, Gascon H, Rieck K. DREBIN: Effective and explainable detection of Android malware in your pocket. In: Proc. of the 21st Network and Distributed System Security Symp. (NDSS 2014). 2014. https://www.researchgate.net/publication/264785935_DREBIN_Effective_and_Explainable_Detection_of_Android_Malware_in_Your_Pocket
[59] Amos B, Turner H, White J. Applying machine learning classifiers to dynamic Android malware detection at scale. In: Proc. of the 9th IEEE Int’l Wireless Communications and Mobile Computing Conf. (IWCMC 2013). 2013. 1666-1671 .
[60] Sahs J, Khan L. A machine learning approach to Android malware detection. In: Proc. of the IEEE 2012 European Intelligence and Security Informatics Conf. 2012. 141-147 .
[61] Peiravian N, Zhu X. Machine learning for Android: Malware detection using permission and API calls. In: Proc. of the 25th IEEE Int’l Conf. on Tools with Artificial Intelligence (ICTAI 2013). 2013. 300-305 .
[62] Google. ApkTool. https://code.google.com/android/apk-tool
[63] FireEye mobile threat prevention. https://www.fireeye.com/content/dam/fireeye-www/global/en/products/pdfs/fireeye-mobile-threat-prevention.pdf
[64] Zimperlich sources. 2011. http://c-skills.blogspot.com/2011/02/zimperlich-sources.html
[65] Android software stack. http://source.android.com/devices/tech/security/index.html
[66] OpenBinder: And open-source system component framework. http://www.open-binder.org
[67] Android system framework. http://source.android.com/devices/index.html
[68] Android permissions.http://developer.android.com/reference/android/Manifest.permission.html
[69] Saltzer JH. Protection and the control of information sharing in Multics. Communications of the ACM, 1974,17(7):388-402 .
[70] Bugiel S, Davi L, Dmitrienko A, Heuser S, Sadeghi AR, Shastry B. Practical and lightweight domain isolation on Android. In: Proc. of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM 2011). 2011. 51-62 .
[71] Enck W, Ongtang M, Mcdaniel P. Mitigating Android software misuse before it happens. Technical Report, NAS-TR-0094-2008, 2008.
[72] Ongtang M, McLaughlin S, Enck W, McDaniel P. Semantically rich application-centric security in Android. In: Proc. of the IEEE Annual Computer Security Applications Conf. (ACSAC 2009). 2009. 340-349 .
[73] Nauman M, Khan S, Zhang X. Apex: Extending Android permission model and enforcement with user-defined runtime constraints. In: Proc. of the 5th ACM Asia Conf. on Computer and Communications Security (ASIACCS 2010). 2010. 328-332 .
[74] Pearce P, Felt AP, Nunez G, Wagner D. Addroid: Privilege separation for applications and advertisers in Android. In: Proc. of the 7th ACM Asia Conf. on Computer and Communications Security (ASIACCS 2012). 2012. 71-72 .
[75] Jeon J, Micinski KK, Vaughan JA, Fogel A, Reddy N, Foster JS, Millstein T. Dr. Android and Mr. Hide: Fine-Grained security policies on unmodified Android. In: Proc. of the 2nd ACM Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM 2012). 2012.3-14 .
[76] Google API. http://www.android-doc.com/guide/components/index.html
[77] Stanek W. Windows Server 2012 Inside Out. Redmond: Microsoft Press, 2013.
[78] Qing SH, Cheng W, Du C. Analysis of security risk controllability for windows OS. Netinfo Security, 2015,4:5-12 (in Chinese with English abstract) .
[79] Security enhancements in Android 4.2. http://source.android.com/devices/tech/security/enhancements42.html
[80] Security enhancements in Android 4.3. http://source.android.com/devices/tech/security/enhancements43.html
[81] Validating security-enhanced Linux in Android. http://source.android.com/devices/tech/security/se-linux.html
[82] Exploid. 2010. http://c-skills.blogspot.com/2010/07/exploid-works-on-droid-x.html
[83] RageAgainstTheCage. 2011. https://thesnkchrmr.wordpress.com/2011/03/24/rageagainstthecage/
[84] Mahaffey K. Security alert: DroidDream. 2011. http://blog.mylookout.com/2011/03/securityalert-malware-found-in-official-
[85] Strazzere T. Security alert: Zhash. 2011. http://blog.mylookout.com/2011/03/security-alertzhash-a-binary-that-can-root-android-phones-found-inchinese-app-markets-and-android-market/
[86] Jiang X. Security alert: New DroidKungFu variant—AGAIN!—Found in alternative Android markets. http://www.csc.ncsu.edu/faculty/jiang/DroidKungFu3/
[87] Doherty S, Krysiuk P. Android.Basebridge technical details. 2011. http://www.symantec.com/securityresponse/writeup.jsp?docid=2011-060915-4938-99&tabid=2
[88] Edge J. RLIMIT NPROC and setuid(). Linux Weekly News, 2011. http://lwn.net/Articles/451985
[89] Castillo CA. Android malware past, present, and future. Technical Report, McAfee Mobile Working Security Group, 2012.
[90] Fake netxflix Android trojan info stealer. 2011. http://contagiominidump.blogspot.in/2011/10/fake-netxflix-adtroidtrojan-info.html
[91] Andre G, Ramos P. Boxer SMS trojan. Technical Report, ESET Latin American Lab, 2013.
[92] Spitmo vs Zitmo: Banking trojans target Android. https://blogs.mcafee.com/mcafee-labs/spitmo-vs-zitmo-bankingtrojans-target-android
[93] Backdoor. AndroidOS.Obad.a. 2013. http://contagiominidump.blogspot.in/2013/06/backdoorandroidosobada.html
[94] Fakedefender B. Android fake antivirus. 2013. http://contagiominidump.blogspot.in/2013/11/fakedefenderb-androidfake-antivirus.html
[95] Davi L, Dmitrienko A, Sadeghi AR, Winandy M. Privilege escalation attacks on Android. In: Proc. of the 13th Int’l Conf. (ISC 2010). LNCS 6531, Springer-Verlag, 2011. 346-360 .
[96] Felt AP, Wang HJ, Moshchuk A, Hanna S, Chin E. Permission re-delegation: Attacks and defenses. In: Proc. of the 20th USENIX Security Symp. (USENIX 2011). 2011. https://www.usenix.org/legacy/event/sec11/tech/full_papers/Felt.pdf
[97] Bugiel S, Davi L, Dmitrienko A, Fischer T, Sadeghi AR. Xmandroid: A new Android evolution to mitigate privilege escalation attacks. Technical Report, TR-2011-04, 2011.
[98] Bugiel S, Davi, Dmitrienko A, Fischer T, Sadeghi1 AR, Shastry B. Towards taming privilege-escalation attacks on Android. In: Proc. of the 19th Network and Distributed System Security Symp. (NDSS 2012). 2012. http://core.ac.uk/download/pdf/18286747. pdf
[99] Chin E, Felt AP, Greenwood K, Wagner D. Analyzing inter-application communication in Android. In: Proc. of the ACM 9th Int’l Conf. on Mobile Systems, Applications, and Services (MobiSys 2011). 2011. 239-252 .
[100] Hardy N. The confused deputy. ACM Operating Systems Review, 1988,22(4):36-38.
[101] Marforio C, Application collusion attack on the permission-based security model and its implications for modern smartphone systems. Technical Report, 724, ETH, 2011 .
[102] Schlegel R, Zhang K, Zhou X, Intwala M, Kapadia A, Wang X. Soundcomber: A stealthy and context-aware sound trojan for smartphones. In: Proc. of the 18th Network and Distributed System Security Symp. (NDSS 2011). 2011. 17-33. http://dev.www.isocdev.org/sites/default/files/schlegel.pdf
[103] Fahl S, Harbach M, Muders T, Baumgärtner L, Freisleben B, Smith M. Why eve and mallory love Android: An analysis of Android SSL (in) security. In: Proc. of the 19th ACM Conf. on Computer and Communications Security (CCS 2012). 2012. 50-61 .
[104] Georgiev M, Iyengar S, Jana S. Anubhai R, Boneh D, Shmatikov V. The most dangerous code in the world: Validating SSL certificates in non-browser software. In: Proc. of the 19th ACM Conf. on Computer and Communications Security (CCS 2012). 2012. 38-49 .
[105] Egele M, Brumley D, Fratantonio Y, Kruegel C. An empirical study of cryptographic misuse in Android applications. In: Proc. of the 20th ACM Conf. on Computer and Communications Security (CCS 2013). 2013. 73-84 .
[106] Sounthiraraj D, Sahs J, Greenwood G, Lin Z, Khan L. SMV-HUNTER: Large scale, automated detection of SSL/TLS man-in-the- middle vulnerabilities in Android apps. In: Proc. of the 21st Network and Distributed System Security Symp. (NDSS 2014). 2014. http://www.internetsociety.org/sites/default/files/10_3_1.pdf
[107] Rastogi V, Chen Y, Enck W. Appsplayground: Automatic security analysis of smartphone applications. In: Proc. of the 3rd ACM Conf. on Data and Application Security and Privacy (CODASP 2013). 2013. 209-220 .
[108] BlackHat, reverse engineering with androguard. https://code.google.com/androguard
[109] Octeau D, Daniel P, Enck W. Ded: Decompiling Android applications. http://siis.cse.psu.edu/ded/
[110] Dex2Jar, Android decompiling with Dex2jar. 2015. http://code.google.com/p/dex2jar/
[111] Enck W, Ongtang M, McDaniel P. On lightweight mobile phone application certification. In: Proc. of the 16th ACM Conf. on Computer and Communications Security (CCS 2009). 2009. 235-245 .
[112] Fuchs AP, Chaudhuri A, Foster JS. SCanDroid: Automated security certification of Android applications. University of Maryland, 2009. http://www.cs.umd.edu/~avik/papers/scandroidascaa.pdf
[113] Chan PPF, Hui LCK, Yiu SM. Droidchecker: Analyzing Android applications for capability leak. In: Proc. of the 15th ACM Conf. on Security and Privacy in Wireless and Mobile Networks (WiSec 2012). 2012. 125-136 .
[114] Lu L, Li Z, Wu Z, Lee W, Jiang G. Chex: Statically vetting Android apps for component hijacking vulnerabilities. In: Proc. of the 19th ACM Conf. on Computer and Communications Security (CCS 2012). 2012. 229-240 .
[115] Gibler C, Crussell J, Erickson J, Chen H. AndroidLeaks: Automatically detecting potential privacy leaks in Android applications on a large scale. In: Proc. of the 5th Int’l Conf. (TRUST 2012). LNCS 7344, Springer-Verlag, 2012. 291-307 .
[116] Octeau D, McDaniel P, Jha S, Bartel A, Bodden E, Klein J, Traon YL. Effective inter-component communication mapping in Android with EPICC: An essential step towards holistic security analysis. In: Proc. of the 22nd USENIX Security Symp. (USENIX 2013). 2013. http://orbilu.uni.lu/handle/10993/12576
[117] Cui XM, Yu D, Chan P, Hui Lucas CK, Yiu SM, Qing SH. CoChecker: Detecting capability and sensitive data leaks from component chains in Android. In: Proc. of the 19th Australasian Conf. (ACISP 2014). LNCS 8544, Springer-Verlag, 2014. 446-453 .
[118] Kim J, Yoon Y, Yi K, Shin J. ScanDal: Static analyzer for detecting privacy leaks in Android applications. In: Proc. of the IEEE Workshop on Mobile Security Technologies (MoST 2012). 2012. http://www.mostconf.org/2012/papers/26.pdf
[119] Stowaway. http://www.android-permissions.org/
[120] Dietz M, Shekhar S, Pisetsky Y, Shu A, Wallach DS. Quire: Lightweight provenance for smart phone operating systems. In: Proc. of the 20th USENIX Security Symp. (USENIX 2011). 2011. 24. http://static.usenix.org/event/sec11/tech/full_papers/Dietz.pdf
[121] Enck W, Gilbert P, Chun BG, Cox LP, Jung J, McDaniel P, Sheth AN. TaintDroid: An information flow tracking system for real- time privacy monitoring on smartphones. Communications of the ACM, 2014,57(3):99-106 .
[122] Huang J, Zhang X, Tan L, Wang P, Liang B. Asdroid: Detecting stealthy behaviors in Android applications by user interface and program behavior contradiction. In: Proc. of the 36th Int’l Conf. on Software Engineering (ICSE 2014). 2014. 1036-1046 .
[123] Burguera I, Zurutuza U, Nadjm-Tehrani S. Crowdroid: Behavior-Based malware detection system for Android. In: Proc. of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM 2011). 2011. 15-26 .
[124] Amos B, Turner H, White J. Applying machine learning classifiers to dynamic Android malware detection at scale. In: Proc. of the 2013 9th Int’l Wireless Communications and Mobile Computing Conf. (IWCMC). 2013. 1666-1671 .
[125] Peng H, Gates C, Sarma B, Li N, Qi Y, Potharaju R, Nita-Rotaru C, Molloy I. Using probabilistic generative models for ranking risks of Android apps. In: Proc. of the 19th ACM Conf. on Computer and Communications Security (CCS 2012). 2012. 241-252 .
[126] Wu DJ, Mao CH, Wei TE, Lee HM. Droidmat: Android malware detection through manifest and API calls tracing. In: Proc. of the 7th Asia Joint Conf. on Information Security (Asia JCIS). 2012. 62-69 .
[127] Ongtang M, Butler K, McDaniel P. Porscha: Policy oriented secure content handling in Android. In: Proc. of the 26th Annual Computer Security Applications Conf. (ACSAC 2010). 2010. 221-230 .
[128] Conti M, Nguyen VTN, Crispo B. CRePE: Contextrelated policy enforcement for Android. In: Proc. of the 13th Int’l Conf. (ISC 2010). LNCS 6531, Springer-Verlag, 2010. 331-345 .
[129] Portokalidis G, Homburg P, Anagnostakis K, Bos H. Paranoid Android: Versatile protection for smartphones. In: Proc. of the 26th Annual Computer Security Applications Conf. (ACSAC 2010). 2010. 347-356 .
[130] Shabtai A, Fledel Y, Elovici Y. Securing Android—Powered mobile devices using SELinux. IEEE Security and Privacy, 2010,8(3): 36-44 .
[131] Smalley S, Craig R. Security enhanced (SE) Android: Bringing flexible MAC to Android. In: Proc. of the 20th Network and Distributed System Security Symp. (NDSS 2013). 2013. 20-38. http://www.cs.columbia.edu/~lierranli/coms6998-7Spring2014/papers/SEAndroid-NDSS2013.pdf
[132] Qing SH, Shen QN, Liu WQ. OS Security. 2nd ed., Beijing: Tsinghua University Press, 2011. 226-229 (in Chinese).
[133] National Security Agency. Security-Enhanced linux. http://www.nsa.gov/research/selinux
[134] Zhang X, Acıiçmez O, Seifert JP. A trusted mobile phone reference architecture via secure kernel. In: Proc. of the 2007 ACM Workshop on Scalable Trusted Computing (STC 2007). 2007. 7-14 .
[135] Trusted Computing Group. Mobile Trusted Module Specification. Version 1.0 Revision 6, 26, 2008.
[136] Trusted Computing Group (TCG). TNC Architecture for Interoperability. Version 1.4, Revision 4, 2009.
[137] L4Linux. http://l4linux.org/
[138] Lange M, Liebergeld S, Lackorzynski A, Warg A, Peter M. L4Android: A generic operating system framework for secure smartphones. In: Proc. of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM 2011). 2011. 39-50 .
[139] Andrus J, Dall C, Hof AV, Laadan O, Nieh J. Cells: A virtual mobile smartphone architecture. In: Proc. of the 23rd ACM Symp. on Operating Systems Principles (SOSP 2011). 2011. 173-187 .
[140] Bae H, Kim SW, Yoo C. Building the Android platform security mechanism using TrustZone. In: Proc. of the 8th Int’l Symp. on Embedded Technology (ISET 2013). 2013. http://os.korea.ac.kr/publication_papers/inter_confer/ISET2013%20HeeJae%20Bae%20with%20ACK.pdf
[141] Samsungknox. https://www.samsungknox.com/zh-hans
[142] QEMU. http://wiki.qemu.org/Index.html
[143] Vasudevan A, Owusu E, Zhou Z, Newsome J, McCune JM. Trustworthy execution on mobile devices: What security properties can my mobile platform give me. 2012. http://users.ece.cmu.edu/~jmmccune/papers/VaOwZhNeMc2012.pdf
[144] Vasudevan A, McCune JM, Newsome J. Trustworthy Execution on Mobile Devices. New York: Springer-Verlag, 2014 .
[145] Watson R. A decade of OS access-control extensibility. ACM Queue, 2013,11(1) .
[146] Write C, Cowan C, Smalley S, Morris J, Kroah-Hartman G. Linux security modules: General security support for the Linux kernel. In: Proc. of the 11th USENIX Security Symp. (USENIX 2002). 2002 .
[147] Watson R. TrustedBSD: Adding trusted operating system features to FreeBSD. In: Proc. of the USENIX 2001. 2001. http://www.trustedbsd.net/trustedbsd-freenix-2001.pdf
[148] Heuser S, Nadkarni A, Enck W, Sadeghi AR. ASM: A programmable interface for extending Android security. In: Proc. of the 23nd USENIX Security Symp. (USENIX 2014). 2014. https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-heuser.pdf
[149] Backes M, Bugiel S, Gerling S, von Styp-Rekowsky P. Android security framework: Enabling generic and extensible access control on Android. Technical Report, A/01/2014, Saarland University, 2014.
[150] Xu R, Saidi H, Anderson R. Aurasium: Practical policy enforcement for Android applications. In: Proc. of the 21st USENIX Security Symp. (USENIX 2012). 2012.
[151] Zhang M, Yin H. AppSealer: Automatic generation of vulnerability-specific patches for preventing component hijacking attacks in Android applications. In: Proc. of the 21st Network and Distributed System Security Symp. (NDSS 2014). 2014 .
[8] 张玉清,王凯,杨欢,方喆君,王志强,曹琛.Android安全综述.计算机研究与发展,2014,51(7):1385-1396 .
[12] 蒋绍林,王金双,张涛,陈融.Android安全研究综述.计算机应用与软件,2012,29(10):205-210 .
[15] 王玮.基于Android系统的恶意程序原理分析.信息网络安全,2012,10:71-76 .
[24] 李静华,慕德俊,杨鸣坤,胡伟.Android恶意程序行为分析系统设计.北京邮电大学学报,2014,37(s1):104-107.
[26] 文伟平,梅瑞,宁戈,汪亮亮.Android恶意软件检测技术分析和应用研究.通信学报,2014,8:78-85 .
[28] 张文,严寒冰,文伟平.一种Android恶意程序检测工具的实现.信息网络安全,2013,1:27-32 .
[30] 李挺,董航,袁春阳,杜跃进,徐国爱.基于Dalvik指令的Android恶意代码特征描述及验证.计算机研究与发展,2014,51(7): 1458-1466 .
[78] 卿斯汉,程伟,杜超.Windows操作系统的安全风险可控性分析.信息网络安全,2015,4:5-12 .
[132] 卿斯汉,沈晴霓,刘文清.操作系统安全.第2版,北京:清华大学出版社,2011.226-229.