Android應(yīng)用程序第三方庫(kù)的惡意行為隔離技術(shù)綜述

湛家偉 左奇?zhèn)??，撴?王躍武

1(中國(guó)科學(xué)院數(shù)據(jù)與通信保護(hù)研究教育中心 北京 100093)

2(中國(guó)科學(xué)院信息工程研究所 北京 100093)

3(中國(guó)科學(xué)院大學(xué) 北京 100049)

4(工業(yè)和信息化部產(chǎn)業(yè)發(fā)展促進(jìn)中心 北京 100846)

Android應(yīng)用程序第三方庫(kù)的惡意行為隔離技術(shù)綜述

湛家偉1,2,3左奇?zhèn)?牛瑩姣1,2王躍武1,2

1(中國(guó)科學(xué)院數(shù)據(jù)與通信保護(hù)研究教育中心 北京 100093)

2(中國(guó)科學(xué)院信息工程研究所 北京 100093)

3(中國(guó)科學(xué)院大學(xué) 北京 100049)

4(工業(yè)和信息化部產(chǎn)業(yè)發(fā)展促進(jìn)中心 北京 100846)

Android應(yīng)用程序第三方庫(kù)的大量使用，提高了移動(dòng)軟件的開發(fā)效率，同時(shí)也帶來了新的安全問題。目前的Android系統(tǒng)只提供一種粗粒度的權(quán)限控制機(jī)制，第三方庫(kù)會(huì)與其所在主應(yīng)用具有相同的權(quán)限，導(dǎo)致第三方庫(kù)權(quán)限過大，對(duì)用戶隱私造成嚴(yán)重威脅。目前，越來越多的學(xué)者開始對(duì)第三方庫(kù)的惡意行為進(jìn)行研究，取得了一定的成果。通過對(duì)惡意第三方庫(kù)隔離技術(shù)的相關(guān)背景和已有方案進(jìn)行綜述，分析出現(xiàn)有研究工作中存在的問題，并對(duì)未來研究方向進(jìn)行展望。

Android 第三方庫(kù) 隔離 惡意行為

0 引 言

Android作為目前市場(chǎng)占有率最高的移動(dòng)終端操作系統(tǒng)，其開放性策略吸引了大量的用戶和研究人員，但同時(shí)也帶來了許多安全問題。據(jù)TrendForce公司發(fā)布的2015年全球智能手機(jī)市場(chǎng)情況報(bào)告顯示，2015年全球智能手機(jī)銷量高達(dá)12.92億部[1]，同比增長(zhǎng)10.3%，其中使用Android系統(tǒng)的手機(jī)占比高達(dá)80%以上。Google Play商店應(yīng)用程序數(shù)量在2014年就超過了Apple store，達(dá)到143萬(wàn)，2015年Google Play應(yīng)用程序下載量破500億，是Apple store下載量的兩倍。

Android應(yīng)用開發(fā)者通過使用不同功能特性的第三方庫(kù)，能顯著節(jié)省開發(fā)成本，因此，開發(fā)者越來越多地依賴于第三方庫(kù)的使用。Android系統(tǒng)只提供了一種粗粒度的權(quán)限控制機(jī)制，第三方庫(kù)與其所在的主應(yīng)用程序具有相同的權(quán)限。每個(gè)第三方庫(kù)通常只需要一小部分權(quán)限即可完成相應(yīng)的功能，而開發(fā)者往往會(huì)申請(qǐng)大量權(quán)限，導(dǎo)致第三方庫(kù)權(quán)限過大，對(duì)用戶隱私造成嚴(yán)重威脅。目前，越來越多的學(xué)者開始研究第三方庫(kù)相關(guān)的惡意行為，并提出了很多解決方案。本文將介紹Android應(yīng)用程序第三方庫(kù)相關(guān)背景，對(duì)已有的隔離技術(shù)進(jìn)行總結(jié)，最后對(duì)未來的研究工作進(jìn)行展望。

1 背 景

本節(jié)將對(duì)Android平臺(tái)相關(guān)安全機(jī)制進(jìn)行介紹，包括：隔離沙箱、Permission機(jī)制、常見隔離技術(shù)。

1.1 Android隔離沙箱

Android為了保障每個(gè)應(yīng)用的運(yùn)行過程不受其他應(yīng)用的影響，為每個(gè)應(yīng)用提供了一個(gè)隔離沙箱，如圖1所示。應(yīng)用程序在安裝時(shí)會(huì)被分配了唯一的UID，借助Linux平臺(tái)基于UID的自主訪問控制機(jī)制(DAC)，可以對(duì)應(yīng)用的資源進(jìn)行有效保護(hù)。每個(gè)應(yīng)用程序都運(yùn)行在獨(dú)立的進(jìn)程空間，不能直接訪問其他應(yīng)用的資源，應(yīng)用間的交互需要借助進(jìn)程間通信技術(shù)(IPC)。

圖1 Android隔離沙箱示意圖

1.2 Permission機(jī)制

在Android平臺(tái)上，受保護(hù)的系統(tǒng)資源一般分為兩類：用戶空間資源和內(nèi)核空間資源。用戶空間資源主要包括：四大組件(Activity、Service、Broadcast Receiver、ContentProvider)，短信、聯(lián)系人、地理位置等，一般由Framework層的系統(tǒng)服務(wù)提供權(quán)限控制。內(nèi)核空間資源主要包括：網(wǎng)絡(luò)、NFC、藍(lán)牙等，一般由Linux內(nèi)核通過UGO(U代表用戶，G代表組，O代表其他)來提供權(quán)限控制。

圖2為Permission機(jī)制的整體框架圖，主要包括三個(gè)步驟：開發(fā)者進(jìn)行權(quán)限申請(qǐng)，安裝時(shí)用戶授權(quán)以及運(yùn)行時(shí)系統(tǒng)檢查。無論應(yīng)用程序想訪問哪種類型的資源，都需要在AndroidManifest.xml文件里申請(qǐng)相應(yīng)的權(quán)限。在應(yīng)用安裝時(shí)，由用戶手動(dòng)選擇是否授予其所申請(qǐng)的權(quán)限。PackageManagerService(PMS)是Android系統(tǒng)的一個(gè)核心服務(wù)，位于system_server進(jìn)程，負(fù)責(zé)系統(tǒng)中Package的管理，應(yīng)用程序的安裝、卸載、信息查詢等。在上述安裝過程中，PMS會(huì)對(duì)AndroidManifest.xml文件進(jìn)行解析，同時(shí)將每個(gè)應(yīng)用的權(quán)限信息進(jìn)行存儲(chǔ)。

圖2 Permission機(jī)制架構(gòu)圖

運(yùn)行時(shí)的權(quán)限檢查針對(duì)不同類型的資源也分為用戶空間和內(nèi)核空間兩類。當(dāng)應(yīng)用訪問用戶空間資源時(shí)，會(huì)首先與ServiceManager進(jìn)程進(jìn)行通信，找到提供相應(yīng)資源的系統(tǒng)服務(wù)并向其發(fā)出請(qǐng)求。隨后，該服務(wù)向system_server進(jìn)程發(fā)起檢查，查詢應(yīng)用是否被授予了相應(yīng)的權(quán)限。當(dāng)應(yīng)用啟動(dòng)時(shí)，由system_server進(jìn)程負(fù)責(zé)將權(quán)限轉(zhuǎn)換為L(zhǎng)inux組發(fā)送給zygote進(jìn)程用于進(jìn)程創(chuàng)建。zygote在收到請(qǐng)求后創(chuàng)建一個(gè)新的子進(jìn)程并將其設(shè)置到相應(yīng)的組。此后，該進(jìn)程訪問內(nèi)核資源時(shí)，就會(huì)由Linux UGO負(fù)責(zé)權(quán)限控制。

Permission機(jī)制是一種粗粒度的權(quán)限控制機(jī)制，使得第三方庫(kù)權(quán)限過大，引發(fā)用戶隱私竊取等安全問題。由于Permission機(jī)制在權(quán)限申請(qǐng)和檢查時(shí)都是以UID(一個(gè)應(yīng)用程序?qū)?yīng)一個(gè)唯一UID)作為最小控制單元，因此使得第三方庫(kù)具有和整個(gè)應(yīng)用一樣的權(quán)限。另外，由于權(quán)限不會(huì)在運(yùn)行時(shí)被更改，一旦被授予，第三方庫(kù)會(huì)一直擁有相應(yīng)的權(quán)限，直到應(yīng)用程序被卸載。即使第三方庫(kù)原本是善意的，但攻擊者依然可以對(duì)其進(jìn)行篡改，重新編譯后偽裝成原先的庫(kù)，導(dǎo)致開發(fā)者誤用惡意的第三方庫(kù)。

1.3 應(yīng)用程序隔離技術(shù)

利用應(yīng)用程序隔離技術(shù)，可以有效地保護(hù)用戶隱私，提高數(shù)據(jù)安全性。文獻(xiàn)[14]對(duì)Android平臺(tái)上常用的應(yīng)用隔離技術(shù)進(jìn)行了分類，如圖3所示，主要分為：應(yīng)用層隔離[14]、系統(tǒng)層隔離[15]、虛擬機(jī)隔離[16-17]，下面將對(duì)這三種技術(shù)分別進(jìn)行介紹：

(1) 應(yīng)用層隔離

應(yīng)用層的隔離主要通過擴(kuò)充中間件和內(nèi)核，對(duì)應(yīng)用間的通信方式進(jìn)行強(qiáng)制訪問控制(MAC)，以達(dá)到隔離的目的。例如，TrustDroid[14]提供了一種實(shí)用的輕量級(jí)的Android隔離框架，通過對(duì)中間件層和內(nèi)核進(jìn)行擴(kuò)展，實(shí)現(xiàn)不同信任等級(jí)間應(yīng)用和數(shù)據(jù)的隔離。此類方案對(duì)系統(tǒng)性能影響小，但可信計(jì)算基礎(chǔ)(TCB)較大，隔離性較差。

(2) 系統(tǒng)層的隔離

系統(tǒng)層的隔離主要通過構(gòu)建一個(gè)特殊的中間件層來達(dá)到隔離的目的。例如，AirBag[15]構(gòu)建了一個(gè)額外的中間層運(yùn)行環(huán)境，能有效地隔離惡意應(yīng)用。

(3) 虛擬機(jī)隔離

虛擬機(jī)層的隔離通常表現(xiàn)為在一個(gè)設(shè)備上運(yùn)行兩個(gè)操作系統(tǒng)。例如，L4Android[16]和Cells[17]提出了類似的解決方案，能在一個(gè)物理設(shè)備上運(yùn)行多個(gè)虛擬設(shè)備。此類方案TCB最小，隔離性最好，但對(duì)手機(jī)性能影響最大。

圖3 Android平臺(tái)上常用的隔離技術(shù)分類

2 Android應(yīng)用程序第三方庫(kù)

2.1 第三方庫(kù)的分類

按照運(yùn)行環(huán)境，第三方庫(kù)可以分發(fā)Java庫(kù)和Native庫(kù)[7]。Android應(yīng)用程序運(yùn)行時(shí)結(jié)構(gòu)如圖4所示。由圖可知，Native庫(kù)直接運(yùn)行在Linux內(nèi)核上，Java庫(kù)運(yùn)行在虛擬機(jī)上，都可以被應(yīng)用程序使用。

圖4 Android應(yīng)用程序運(yùn)行時(shí)結(jié)構(gòu)圖

Java庫(kù)存在的形式多種多樣，最終都以字節(jié)碼的形式被虛擬機(jī)加載運(yùn)行，訪問內(nèi)存空間時(shí)需要受到虛擬機(jī)的管控。Native庫(kù)通常采用C/C++編寫，以so庫(kù)的形式存在，不能單獨(dú)執(zhí)行，需要先加載到內(nèi)存再通過JNI(Java Native Interface)供上層調(diào)用，訪問內(nèi)存空間時(shí)不受虛擬機(jī)的限制。相比于Java庫(kù)，Native庫(kù)運(yùn)行速度快，逆向難度大，能有效地與操作系統(tǒng)底層進(jìn)行交互，也被應(yīng)用開發(fā)者廣泛使用。

2.2 第三方庫(kù)的惡意行為

隨著Android應(yīng)用程序第三方庫(kù)的大量使用，其權(quán)限濫用現(xiàn)象也越來越嚴(yán)重，帶來許多安全問題。廣告庫(kù)是最常見的第三方庫(kù)，文獻(xiàn)[3]的研究表明，幾乎50%的免費(fèi)應(yīng)用內(nèi)嵌有第三方公司提供的廣告庫(kù)。許多學(xué)者對(duì)廣告庫(kù)的潛在安全風(fēng)險(xiǎn)進(jìn)行了研究[2-3]，發(fā)現(xiàn)很多廣告庫(kù)訪問用戶敏感信息時(shí)，并沒有對(duì)用戶進(jìn)行提示，同時(shí)也沒有在開發(fā)者文檔里進(jìn)行注明。除廣告庫(kù)外，開發(fā)者還會(huì)大量使用一些具有其他功能特征的第三方庫(kù)，例如，用戶界面、游戲引擎、網(wǎng)絡(luò)通信、數(shù)據(jù)分析等，也會(huì)對(duì)用戶隱私造成嚴(yán)重威脅。文獻(xiàn)[2]對(duì)100 000個(gè)應(yīng)用程序進(jìn)行了分析，發(fā)現(xiàn)所有類型的第三方庫(kù)，在開發(fā)者指南里沒有明確指出的情況下，大多都會(huì)秘密地使用系統(tǒng)API來訪問用戶的隱私信息，包括：賬戶信息、電話狀態(tài)、地理位置等。

3 Android惡意第三方庫(kù)隔離技術(shù)

根據(jù)第三方庫(kù)與主應(yīng)用的運(yùn)行環(huán)境的不同，可以將第三方庫(kù)相關(guān)的隔離技術(shù)分為兩類：進(jìn)程間隔離和組件間隔離，下面分別對(duì)其進(jìn)行介紹。

3.1 進(jìn)程間隔離技術(shù)

進(jìn)程間隔離技術(shù)的一般架構(gòu)如圖5所示，通過將第三方庫(kù)遷移到單獨(dú)進(jìn)程里，實(shí)現(xiàn)對(duì)第三方庫(kù)的權(quán)限隔離。

圖5 進(jìn)程間隔離技術(shù)架構(gòu)圖

AdSplit[8]和AFrame[9]將廣告庫(kù)作為一個(gè)單獨(dú)的應(yīng)用程序來運(yùn)行，使得應(yīng)用開發(fā)者不需要為廣告庫(kù)申請(qǐng)任何權(quán)限，能有效地限制廣告庫(kù)的惡意行為。NativeGuard[10]采用了類似的方法，但主要是針對(duì)Native庫(kù)。AdDroid[11]構(gòu)建了一個(gè)新的Android系統(tǒng)服務(wù)，將應(yīng)用的廣告功能進(jìn)行統(tǒng)一管理，實(shí)現(xiàn)兩者間的進(jìn)程間隔離。LayerCake[12]將用戶界面相關(guān)的庫(kù)與主應(yīng)用分離，為Android應(yīng)用提供安全的第三方可嵌入用戶界面庫(kù)。上述方案中，第三方庫(kù)與主應(yīng)用運(yùn)行在不同進(jìn)程，因此所有交互都需要使用進(jìn)程間通信。

3.2 組件間隔離技術(shù)

組件間隔離技術(shù)在不遷移第三方庫(kù)的前提下，也能實(shí)現(xiàn)應(yīng)用內(nèi)的權(quán)限隔離。FLEXDROID[2]和Compac[13]主要針對(duì)Permission機(jī)制的粗粒度控制缺陷進(jìn)行改進(jìn)，從而提供組件間的權(quán)限隔離。相比于Compac，F(xiàn)LEXDROID針對(duì)某些依賴JNI和動(dòng)態(tài)代碼執(zhí)行的第三方庫(kù)進(jìn)行了處理。圖6為組件間隔離技術(shù)的一般架構(gòu)圖，實(shí)線框表示已有模塊，虛線框表示新添加的模塊。

圖6 組件間隔離技術(shù)架構(gòu)圖

下面針對(duì)這些模塊進(jìn)行介紹：

(1) 策略配置模塊

策略接口模塊主要負(fù)責(zé)為開發(fā)者提供針對(duì)第三方庫(kù)進(jìn)行細(xì)粒度權(quán)限控制的接口。開發(fā)者對(duì)第三方庫(kù)的功能有著清晰的認(rèn)識(shí)，因此，由開發(fā)者制定第三方庫(kù)的權(quán)限策略能準(zhǔn)確的對(duì)其行為進(jìn)行管控。每個(gè)運(yùn)行在Android平臺(tái)上的應(yīng)用程序，其權(quán)限信息由開發(fā)者在AndroidManifest.xml文件里面去配置申請(qǐng)。為了更好地與Android原生Permission機(jī)制兼容，多數(shù)方案選擇通過在該文件里加入特殊的標(biāo)簽，來給開發(fā)者提供第三方庫(kù)的權(quán)限控制接口。

(2) 信息提取模塊

信息提取模塊主要負(fù)責(zé)在應(yīng)用訪問敏感資源時(shí)，實(shí)時(shí)獲取相關(guān)信息。Android原有的Permission機(jī)制僅僅需要UID來作為權(quán)限檢查的依據(jù)，為了能夠?qū)崿F(xiàn)細(xì)粒度的權(quán)限控制，組件權(quán)限檢查模塊需要得到更多的應(yīng)用程序運(yùn)行時(shí)信息。要針對(duì)第三方庫(kù)進(jìn)行權(quán)限控制，權(quán)限檢查模塊首先需要識(shí)別出當(dāng)前請(qǐng)求來至于哪個(gè)第三方庫(kù)。另外，由于庫(kù)與庫(kù)之間經(jīng)常會(huì)存在相互調(diào)用，因此函數(shù)庫(kù)的調(diào)用序列對(duì)于組件權(quán)限檢查模塊是必不可少的信息。信息提取模塊通過HOOK虛擬機(jī)，修改進(jìn)程間通信等方式，可以實(shí)時(shí)獲取目標(biāo)線程的運(yùn)行時(shí)信息，為組件權(quán)限檢查提供判斷依據(jù)。

(3) 權(quán)限檢查模塊

權(quán)限控制模塊負(fù)責(zé)接收并處理運(yùn)行時(shí)信息，同時(shí)根據(jù)開發(fā)者配置的策略進(jìn)行細(xì)粒度檢查。該模塊同時(shí)還負(fù)責(zé)安裝應(yīng)用時(shí)對(duì)第三方庫(kù)的權(quán)限信息進(jìn)行存儲(chǔ)，主要針對(duì)用戶空間的資源，一般通過擴(kuò)展已有的Android系統(tǒng)服務(wù)實(shí)現(xiàn)。

(4) ACL檢查模塊

針對(duì)內(nèi)核空間的資源，需要ACL[5](訪問控制列表)來進(jìn)行細(xì)粒度控制。ACL是一個(gè)文件/目錄的訪問控制列表，可以針對(duì)任意指定的用戶/組分配RWX權(quán)限。通過移植并修改ACL，使其支持組件級(jí)的權(quán)限控制，可以在運(yùn)行時(shí)保護(hù)內(nèi)核空間資源不被惡意第三方庫(kù)的非法使用。

3.3 其他相關(guān)技術(shù)

(1) 隱私泄露檢測(cè)技術(shù)

此類方案主要目的是保護(hù)用戶隱私數(shù)據(jù)，防止數(shù)據(jù)被非法訪問。例如，TainDroid[18]通過在Dalvik虛擬機(jī)中的數(shù)據(jù)加入污點(diǎn)傳播機(jī)制，能對(duì)敏感數(shù)據(jù)流進(jìn)行實(shí)時(shí)監(jiān)控，有效防止敏感數(shù)據(jù)的泄露，但此方案對(duì)系統(tǒng)性能影響較大。Brahmastra[31]提供了針對(duì)一種自動(dòng)化測(cè)試工具，用于檢測(cè)第三方庫(kù)的潛在威脅。MAdFraud[32]采用了動(dòng)態(tài)分析技術(shù)來檢測(cè)主應(yīng)用程序惡意點(diǎn)擊廣告庫(kù)的行為。

(2) 細(xì)粒度權(quán)限控制技術(shù)

此類方案主要針對(duì)Permission機(jī)制存在的問題，采用細(xì)粒度權(quán)限控制方案，來對(duì)應(yīng)用程序進(jìn)行管控。Apex[19]和Kirin[20]允許用戶只授予應(yīng)用部分權(quán)限，并在安裝時(shí)執(zhí)行用戶選擇的策略，Saint[21]在此基礎(chǔ)上，為用戶提供了運(yùn)行時(shí)的細(xì)粒度權(quán)限控制接口。文獻(xiàn)[22-23]采用自適應(yīng)的方式，根據(jù)上下文環(huán)境來動(dòng)態(tài)的配置應(yīng)用的權(quán)限。AppCage[33]采用軟隔離技術(shù)來限制JNI的內(nèi)存訪問區(qū)域，增強(qiáng)虛擬機(jī)的安全性。

(3) 強(qiáng)制訪問控制技術(shù)

此類方案主要通過將強(qiáng)制訪問控制引入Android平臺(tái)，來加強(qiáng)系統(tǒng)的安全性。文獻(xiàn)[24-26]利用強(qiáng)制訪問控制機(jī)制，對(duì)應(yīng)用程序間的權(quán)限提升問題進(jìn)行處理。SEAndroid[27]將SELinux擴(kuò)展到Android系統(tǒng)，對(duì)內(nèi)核層和框架層實(shí)施強(qiáng)制訪問控制，在Android 4.3版本中被引進(jìn)。FlaskDroid[28-29]和SEDalvik[30]分別針對(duì)Android組件和Dalvik虛擬機(jī)實(shí)現(xiàn)了強(qiáng)制訪問控制。

4 現(xiàn)有工作中存在的問題

4.1 進(jìn)程間隔離技術(shù)存在的問題

進(jìn)程間隔離技術(shù)能有效地將第三方庫(kù)與主應(yīng)用進(jìn)行隔離，實(shí)現(xiàn)細(xì)粒度的權(quán)限訪問控制，但也存在著一些不足。

(1) 對(duì)系統(tǒng)性能影響大

廣告庫(kù)與主應(yīng)用交互較少，不需要太頻繁的進(jìn)程間通信，因此采用進(jìn)程間隔離的方案對(duì)系統(tǒng)性能影響較小。當(dāng)該類方案擴(kuò)展到其他第三方庫(kù)時(shí)，由于存在像網(wǎng)絡(luò)通信、游戲引擎這類需要與主應(yīng)用大量交互的第三方庫(kù)，此時(shí)會(huì)導(dǎo)致大量額外的進(jìn)程間通信，嚴(yán)重影響系統(tǒng)性能。

(2) Java庫(kù)的處理不完善

Java庫(kù)具有大量動(dòng)態(tài)特性，包括：類繼承、多線程、反射、JNI調(diào)用、動(dòng)態(tài)代碼加載等，使得第三方庫(kù)與主應(yīng)用的交互方式變得復(fù)雜，進(jìn)程間隔離相關(guān)的方案難以對(duì)其界限進(jìn)行區(qū)分。

4.2 組件間隔離技術(shù)存在的問題

組件間隔離技術(shù)能有效彌補(bǔ)Permission機(jī)制的不足，實(shí)現(xiàn)組件間的權(quán)限訪問控制，但也在著一些限制。

(1) 無法應(yīng)對(duì)混淆技術(shù)

目前的應(yīng)用程序都會(huì)采用混淆技術(shù)對(duì)自身的代碼進(jìn)行壓縮、優(yōu)化和混淆，增加逆向攻擊難度，保護(hù)應(yīng)用安全。由于策略信息由開發(fā)者提供，混淆技術(shù)會(huì)使得隔離系統(tǒng)不能有效地識(shí)別出第三方庫(kù)，無法提供預(yù)先的功能。此種情況下，只能依靠開發(fā)者將需要隔離的第三庫(kù)進(jìn)特殊處理。

(2) Native庫(kù)的處理不完善

Java庫(kù)在運(yùn)行時(shí)有著非常清晰的棧信息，可以有效地識(shí)別出第三方庫(kù)的調(diào)用序列，在權(quán)限檢查時(shí)利用最小權(quán)限原則對(duì)調(diào)用者的權(quán)限進(jìn)行檢查，而Native庫(kù)的棧信息可讀性相對(duì)較差，需要額外的處理。另外，使用ACL來限制內(nèi)核空間資源時(shí)，會(huì)使得每次文件訪問時(shí)，都需要對(duì)請(qǐng)求者的棧信息進(jìn)行提取，分析出相應(yīng)的第三方庫(kù)信息，并進(jìn)行權(quán)限檢查，如此會(huì)導(dǎo)致系統(tǒng)效率低下。

(3) 存在潛在威脅

由于組件間隔離技術(shù)并沒有對(duì)第三方庫(kù)的內(nèi)存空間進(jìn)行隔離，使得惡意第三方庫(kù)有機(jī)會(huì)利用Native代碼對(duì)主應(yīng)用的內(nèi)存空間進(jìn)行篡改，影響其他庫(kù)的運(yùn)行。

5 惡意第三方庫(kù)隔離技術(shù)的展望

隨著第三方庫(kù)在Android平臺(tái)的大量使用，其惡意行為導(dǎo)致的隱私安全問題受到了廣泛關(guān)注，許多學(xué)者都提出了各自的解決方案，能在一定程序上隔離第三方庫(kù)的惡意行為，但也存在一些不足，本節(jié)將對(duì)第三方庫(kù)隔離技術(shù)的未來方向進(jìn)行展望。

(1) 將第三方庫(kù)進(jìn)行分類處理

由于每種技術(shù)方案都有其優(yōu)劣，可以針對(duì)不同特性的第三方庫(kù)采取不同的隔離方案。例如，針對(duì)Java庫(kù)可以采用組件間隔離技術(shù)，對(duì)其動(dòng)態(tài)特性采取相應(yīng)的措施，就能對(duì)其權(quán)限進(jìn)行有效的控制。針對(duì)與主應(yīng)用交互較少的第三方庫(kù)，可以采用進(jìn)程隔離技術(shù)，實(shí)現(xiàn)內(nèi)存空間的隔離，更大限度地對(duì)惡意行為進(jìn)行限制。

(2) 引入針對(duì)惡意應(yīng)用的隔離技術(shù)

目前攻擊者的手段層出不窮，已有的方案大多只是針對(duì)第三方庫(kù)的權(quán)限進(jìn)行隔離，通過引入惡意應(yīng)用隔離技術(shù)，可以進(jìn)一步防止數(shù)據(jù)免于惡意第三方庫(kù)的危害。例如，Cgroup[7]技術(shù)可以有效地限制并隔離進(jìn)程組所使用的CPU、內(nèi)存、IO等物理資源；利用創(chuàng)建和掛載文件系統(tǒng)，可以實(shí)現(xiàn)第三方庫(kù)的文件級(jí)隔離；利用設(shè)備虛擬化技術(shù)，將驅(qū)動(dòng)等底層系統(tǒng)資源進(jìn)行隔離。上述方案都可以借鑒參考，引入到針對(duì)第三方庫(kù)的惡意行為隔離方案中。

6 結(jié) 語(yǔ)

本文對(duì)Android應(yīng)用程序第三方惡意行為的隔離技術(shù)進(jìn)行了綜述。首先介紹第三方庫(kù)的相關(guān)背景知識(shí)，Permission機(jī)制的原理及其存在的缺陷。然后對(duì)目前Android惡意應(yīng)用的隔離技術(shù)進(jìn)行了描述，接著詳細(xì)介紹了惡意第三方庫(kù)的隔離技術(shù)，并對(duì)其優(yōu)缺點(diǎn)進(jìn)行分析。最后根據(jù)現(xiàn)有研究工作中存在的問題，對(duì)未來的研究工作進(jìn)行展望。

[1] TrendForce Reports Steady Smartphone Shipments Resulted in Just 1% Drop in Global Mobile DRAM Revenue for 4Q15 [EB/OL].2016.http://press.trendforce.com/node/view/2336.html.

[2] Jaebaek Seo, Daehyeok Kim, Donghyun Cho, et al. FLEXDROID:Enforcing In-App Privilege Separation in Android[C]//Proceedings of the Network and Distributed System Security Symposium (NDSS), 2016.

[3] Grace M C, Zhou W, Jiang X, et al. Unsafe exposure analysis of mobile in-app advertisements[C]//ACM Conference on Security and Privacy in Wireless and Mobile Networks. ACM, 2012:101-112.

[4] Stevens R, Gibler C, Crussell J, et al. Investigating user privacy in android ad libraries[C]//Workshop on Mobile Security Technologies (MoST), 2012.

[5] acl[EB/OL]. Linux man page. http://linux.die.net/man/5/acl.

[6] CGROUPS[EB/OL].http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt.

[7] Android ndk[EB/OL]. http://developer.android.com/tools/ sdk/ ndk /index.html.

[8] Shekhar S, Dietz M, Wallach D S. AdSplit: separating smartphone advertising from applications[J]. Dissertations & Theses-Gradworks, 2012, 54(1):99.

[9] Zhang X, Ahlawat A, Du W. AFrame: isolating advertisements from mobile applications in Android[C]//Computer Security Applications Conference. ACM, 2013:9-18.

[10] Sun M, Tan G. NativeGuard:protecting android applications from third-party native libraries[C]//Proceedings of the 2014 ACM conference on Security and privacy in wireless & mobile networks. ACM, 2014:165-176.

[11] Pearce P, Felt A P, Nunez G, et al. Addroid: Privilege separation for applications and advertisers in android[C]//Proceedings of the 7th ACM Symposium on Information, Computer and Communications Security, 2012.

[12] Roesner F, Kohno T. Securing embedded user interfaces: Android and beyond[C]//Presented as part of the 22nd USENIX Security Symposium, 2013.

[13] Wang Y, Hariharan S, Zhao C, et al. Compac: enforce component-level access control in android[C]//ACM Conference on Data and Application Security and Privacy. ACM, 2014:25-36.

[14] Bugiel S, Davi L, Dmitrienko A, et al. Practical and lightweight domain isolation on Android[C]//ACM Workshop on Security and Privacy in Smartphones and Mobile Devices. ACM, 2011:51-62.

[15] Wu C, Zhou Y, Patel K, et al. AirBag: Boosting Smartphone Resistance to Malware Infection[C]//Proceedings of the Network and Distributed System Security Symposium (NDSS), 2014.

[16] Lange M, Liebergeld S, Lackorzynski A, et al. L4Android: a generic operating system framework for secure smartphones[C]//ACM Workshop on Security and Privacy in Smartphones and Mobile Devices. ACM, 2011:39-50.

[17] Andrus J, Dall C, Hof A V, et al. Cells: A Virtual Mobile Smartphone Architecture[C]//Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles, 2011.

[18] Enck W, Gilbert P, Chun B-G, et al. Taintdroid: An information-flow tracking system for realtime privacy monitoring on smartphones[C]//Proceedings of the 9th USENIX Conference on Operating Systems Design and Implementation, 2010.

[19] Nauman M, Khan S, Zhang X. Apex:extending android permission model and enforcement with user-defined runtime constraints[C]//Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security(AsiaCCS), 2010.

[20] Enck W, Ongtang M, McDaniel P. On lightweight mobile phone application certification[C]//Proceedings of the 16th ACM Conference on Computer and Communications Security(CCS), 2009.

[21] Ongtang M, McLaughlin S, Enck W, et al. Semantically rich application-centric security in android[C]//Proceedings of the 2009 Annual Computer Security Applications Conference(ACSA), 2009.

[22] Roesner F, Kohno T, Moshchuk A, et al. User-driven access control: Rethinking permission granting in modern operating systems[C]//Proceedings of the 2012 IEEE Symposium on Security and Privacy(SP) , 2012.

[23] Conti M, Nguyen V T N, Crispo B. CRePE: Context-Related Policy Enforcement for Android[C]//Information Security-, International Conference, ISC 2010, Boca Raton, Fl, Usa, October 25-28, 2010, Revised Selected Papers. DBLP, 2011:331-345.

[24] Bugiel S, Davi L, Dmitrienko A, et al. XManDroid: A New Android Evolution to Mitigate Privilege Escalation Attacks[R]. Technische Universit?t Darmstadt, Technical Report,2011:1-18.

[25] Bugiel S, Davi L, Dmitrienko A, et al. Towards Taming Privilege-Escalation Attacks on Android[J].Proceedings of Annual Network & Distributed System Security Symposium, 2012, 130(130):346-360.

[26] Dietz M, Shekhar S, Pisetsky Y, et al. Quire: lightweight provenance for smart phone operating systems[C]//Proceedings of the 20th USENIX Conference on Security Symposium, 2011.

[27] Smalley S, Craig R. Security enhanced (SE) android: Bringing flexible mac to android[C]//Proceedings of 20th Annual Network & Distributed System Security Symposium (NDSS), 2013.

[28] Bugiel S, Heuser S, Sadeghi A. Towards a framework for android security modules: Extending se android type enforcement to android middleware. Tech. Rep. TUD-CS-2012-0231[R]. Center for Advanced Security Research Darmstadt, Nov. 2012.

[29] Bugiel S, Heuser S, Sadeghi A. Flexible and fine-grained mandatory access control on Android for diverse security and privacy policies[C]//Proceedings of the 22nd USENIX conference on Security symposium, 2013.

[30] Bousquet A, Briffaut J, Clévy L, et al. Mandatory Access Control for the Android Dalvik Virtual Machine[C]//The Workshop on Usenix Federated Conferences. 2013.

[31] Bhoraskar R, Han S, Jeon J, et al. Brahmastra: Driving Apps to Test the Security of Third-Party Components[C]//The 23rdUsenix Security Symposium,2014:1021-1036.

[32] Crussell J, Stevens R, Chen H. MAdFraud: investigating ad fraud in android applications[C]//Proceedings of the 12th Annual International Conference on Mobile Systems, Applications, and Services, 2014.

[33] Zhou Y, Patel K, Wu L, et al. Hybrid User-level Sandboxing of Third-party Android Apps[C]//ACM Symposium on Information, Computer and Communications Security. ACM, 2015:19-30.

ASURVEYONISOLATIONTECHNOLOGYAGAINSTMALICIOUSBEHAVIOROFTHIRDPARTYLIBRARIESOFANDROIDAPPLICATION

Zhan Jiawei1,2,3Zuo Qiwei4Niu Yingjiao1,2Wang Yuewu1,2

1(DataAssuranceandCommunicationSecurityResearchCenter,ChineseAcademyofSciences,Beijing100093,China)2(InstituteofInformationEngineering,ChineseAcademyofSciences,Beijing100093,China)3(UniversityofChineseAcademyofSciences,Beijing100049,China)4(IndustryDevelopmentandPromotionCenter,MinistryofIndustryandInformationTechnologyofthePeople’sRepublicofChina,Beijing100846,China)

The extensive use of third party libraries in Android applications improves the efficiency of mobile software development and brings new security issues. The current Android system only provides a coarse grained permission control mechanism. The third party libraries with its host application have the same permissions, resulting in third party libraries permissions are too large, serious threats to user privacy. At present, more and more scholars began to study the malicious behavior of the third party libraries, and achieved some results. We reviewed the background and existing schemes of malicious third party libraries isolation technology, analyzed the existing problems in the research work, and looked forward to the future research direction.

Android Third party library Isolation Malicious behavior

TP3

A

10.3969/j.issn.1000-386x.2017.10.054

2016-12-16。十三五網(wǎng)絡(luò)空間安全專項(xiàng)項(xiàng)目(2016YFB0800102)。湛家偉，碩士生，主研領(lǐng)域：系統(tǒng)安全。左奇?zhèn)?，高工。?，撴硌芯繂T。王躍武，副研究員。