一種跨APP組件間隱私泄露自動(dòng)檢測(cè)方法

李 振 湯戰(zhàn)勇 李政橋 王 海 龔曉慶 陳 峰 陳曉江 房鼎益

1(西北大學(xué)信息科學(xué)與技術(shù)學(xué)院 西安 710075)2(陜西省無(wú)源物聯(lián)網(wǎng)國(guó)際聯(lián)合研究中心 西安 710075)

隨著Android移動(dòng)市場(chǎng)份額的不斷擴(kuò)大，越來(lái)越多的惡意攻擊者將目標(biāo)瞄向Android設(shè)備.騰訊社會(huì)研究中心最新一期發(fā)布的互聯(lián)網(wǎng)安全報(bào)告[1]顯示：在所選取的852個(gè)Android APP(Android application)中，約有98.5%的APP都需要獲取用戶隱私權(quán)限.Felt等人[2]研究發(fā)現(xiàn)，以獲取并泄露用戶隱私信息為目標(biāo)的惡意軟件占據(jù)很大的比例，這一結(jié)果很好地解釋了近年來(lái)國(guó)內(nèi)外個(gè)人信息泄露事件頻發(fā)的問(wèn)題.

學(xué)術(shù)界和工業(yè)界一般將隱私權(quán)限等級(jí)劃分為高危隱私權(quán)限、核心隱私權(quán)限、重要隱私權(quán)限和普通隱私權(quán)限[3-4].不同層面的權(quán)限濫用會(huì)對(duì)用戶造成不同程度的影響，如何在權(quán)限安全控制和用戶的體驗(yàn)之間抉擇是一個(gè)相互制約的話題，使用權(quán)限定義復(fù)雜的控制手段能夠在一定程度上保護(hù)用戶隱私數(shù)據(jù)，但卻以犧牲用戶體驗(yàn)為代價(jià).為了娛樂(lè)性和實(shí)用性，目前移動(dòng)設(shè)備僅使用粗粒度的訪問(wèn)權(quán)限控制手段.Android系統(tǒng)自身實(shí)現(xiàn)了一套用于保護(hù)敏感信息資源安全性的應(yīng)用程序編程接口(application programming interface, API)訪問(wèn)權(quán)限控制機(jī)制，用于保護(hù)敏感信息資源的安全性.其要求在程序安裝時(shí)向用戶顯式地申請(qǐng)使用權(quán)限.然而中國(guó)互聯(lián)網(wǎng)數(shù)據(jù)中心[4](Data Center of China Internet, DCCI)調(diào)研發(fā)現(xiàn)，有72%的用戶不清楚APP獲取隱私權(quán)限的用途.所以大多數(shù)用戶為了追求良好的用戶體驗(yàn)，不惜將該程序自身功能不必需的隱私權(quán)限授權(quán)給該APP，因此這種API權(quán)限控制機(jī)制并不能有效控制第三方應(yīng)用程序?qū)﹄[私數(shù)據(jù)的訪問(wèn)和使用.

軟件泄露隱私的主要途徑分為組件內(nèi)隱私泄露、組件間隱私泄露和跨APP組件間隱私泄露.組件內(nèi)隱私泄露是指在Android APP內(nèi)部，某組件能夠獨(dú)立完成隱私的獲取和泄露[5]；而組件間隱私泄露是指Android APP內(nèi)部的2個(gè)組件通過(guò)合作完成獲取和泄露隱私[6]；跨APP組件間隱私泄露是指某個(gè)惡意軟件利用存在組件間通信(inter-component communication, ICC)漏洞[7-8]通過(guò)第三方APP來(lái)泄露隱私；據(jù)ComDroid[8]研究表明，60%的應(yīng)用程序至少存在1個(gè)以上的ICC漏洞.因此，跨APP組件間隱私泄露普遍存在并且不容忽視.

雖然目前存在很多隱私檢測(cè)的研究[9-16]，但是針對(duì)跨APP組件間隱私泄露問(wèn)題的研究涉及較少.FlowDroid[5]提出一種新型按需算法的靜態(tài)污點(diǎn)分析技術(shù)檢測(cè)隱私泄露問(wèn)題；LeakMiner[17]結(jié)合Android自身特有的安全機(jī)制以及編程模型，基于函數(shù)調(diào)用關(guān)系實(shí)現(xiàn)了對(duì)程序中隱私信息的識(shí)別、跟蹤和泄露檢測(cè).上述隱私泄露檢測(cè)方法的精確度很高，但僅限于組件內(nèi)隱私泄露問(wèn)題；IccTA[6]和Amandroid[18]等方法針對(duì)組件間隱私泄露檢測(cè).其中，IccTA結(jié)合Epicc[7]與FlowDroid方法，通過(guò)跟蹤組件間的隱私信息傳播達(dá)到檢測(cè)的目的.

跨APP組件間隱私泄露檢測(cè)的實(shí)現(xiàn)存在很大的挑戰(zhàn).原因在于APP中組件數(shù)量龐大、依賴關(guān)系復(fù)雜，存在很多與跨APP組件間隱私泄露無(wú)關(guān)的組件序列路徑.因此，直接利用現(xiàn)有的隱私泄露檢測(cè)技術(shù)，會(huì)在構(gòu)建控制流圖(control flow graph, CFG)時(shí)引發(fā)空間爆炸，嚴(yán)重影響檢測(cè)效率.而且，由于跨APP組件間隱私泄露往往涉及到多個(gè)應(yīng)用程序的集合，APP間代碼不連續(xù)將導(dǎo)致在分析隱私泄露路徑時(shí)無(wú)法建立一個(gè)連續(xù)的CFG，而現(xiàn)有工作不能解決此問(wèn)題.

因此，本文提出了一種檢測(cè)跨APP組件間隱私泄露的方法PLDetect.PLDetect提出生成潛在泄露隱私的組件序列，精簡(jiǎn)與跨APP組件間隱私泄露無(wú)關(guān)的組件序列的方法，有效地解決了在生成CFG時(shí)路徑爆炸問(wèn)題；進(jìn)一步地，PLDetect通過(guò)將生成虛擬主函數(shù)和插樁技術(shù)有效結(jié)合，解決跨APP組件間隱私泄露中的多種代碼不連續(xù)性問(wèn)題；最后，生成基于精簡(jiǎn)組件的控制流圖，并執(zhí)行應(yīng)用程序間靜態(tài)污點(diǎn)分析，輸出跨APP組件間隱私泄露的路徑.

本文的主要貢獻(xiàn)有3個(gè)方面:

1) 設(shè)計(jì)并實(shí)現(xiàn)1個(gè)采用靜態(tài)污點(diǎn)分析方法檢測(cè)跨APP組件間隱私泄露的系統(tǒng)PLDetect；

2) 在保證PLDetect覆蓋泄露隱私信息路徑的情況下，提出生成潛在泄露隱私的組件序列的方法，用以提高檢測(cè)效率；

3) 針對(duì)APP間代碼不連續(xù)造成無(wú)法構(gòu)建完整的CFG，從而導(dǎo)致不能執(zhí)行數(shù)據(jù)流分析的問(wèn)題，通過(guò)移植改進(jìn)IccTA中的插樁方法對(duì)此問(wèn)題進(jìn)行了有效解決.

1 跨APP組件間隱私泄露的攻擊模型

為了準(zhǔn)確描述跨APP組件間隱私泄露攻擊模型，首先給出跨APP組件間隱私泄露的相關(guān)定義.

假定Appi為Android Market中應(yīng)用程序，SandBoxi為其對(duì)應(yīng)的運(yùn)行沙箱環(huán)境，則表示為AppiinSandBoxi.假定fp為隱私信息獲取通道表征函數(shù)，Privacyi為App1能獲取的隱私信息，則表示為Privacyi=fp(Appi).假定lp為隱私信息泄露通道表征函數(shù)，若Appi不能泄露隱私信息，則表示為lp(App1)=false，否則，lp(App1)=true.

在App1inSandBox1&App2inSandBox2且SandBox1∩SandBox2=?的條件下，如果App1滿足Privacy1=fp(App1)≠?且lp(App1)=false,App2滿足Privacy2=fp(App2)≠?且lp(App1)=true,并且存在一種關(guān)聯(lián)關(guān)系函數(shù)R，使得Privacy2=fp(R(App2,App1))≠?且Privacy2∈Privacy1，那么App1和App2可能存在跨APP組件間隱私泄露的路徑.

根據(jù)定義，對(duì)跨APP組件間隱私泄露的攻擊模型進(jìn)行實(shí)例化描述.

在圖1中，App1是獲取隱私信息的良性Android應(yīng)用程序，App2是泄露隱私信息的惡意Android應(yīng)用程序.App1中的組件A通過(guò)授權(quán)的API權(quán)限得到設(shè)備ID值(getDeviceId)，并通過(guò)ICC方法(startActivity)將ID值傳遞給App2中的組件B，并由B將ID值泄露.圖1右側(cè)的代碼分別是App1中組件A與App2中組件B的關(guān)鍵代碼簡(jiǎn)略描述.另外，在實(shí)際用戶使用環(huán)境中，不排除2個(gè)惡意程序通過(guò)合作互通的形式更復(fù)雜更隱蔽地達(dá)到泄露隱私的目的.在上述實(shí)例中，App1可以利用惡意攻擊者所規(guī)定的某種數(shù)據(jù)拆分格式,如圖像格式或自定義文件等形式，將設(shè)備ID發(fā)送至App2，隨后由App2將接收到的信息經(jīng)過(guò)一系列數(shù)據(jù)重組以及信息轉(zhuǎn)換手段寫出，最終以非授權(quán)分發(fā)方式發(fā)送至攻擊者.

上述中不論隱私信息以哪種形式組織，App1滿足Privacy1=fp(App1)≠?且lp(App1)=false，App2滿足Privacy2=fp(App2)≠?且lp(App2)=true.而且App1與App2存在關(guān)聯(lián)關(guān)系R函數(shù)(startActivity)，使得Privacy2=fp(R(App2,App1))≠?,因此，App1和App2間可能存在跨APP組件間隱私泄露的路徑.

2 PLDetect系統(tǒng)實(shí)現(xiàn)

PLDetect由5個(gè)執(zhí)行步驟組成，如圖2所示，在Step1中，利用Epicc提取輸入中每個(gè)APP的組件屬性；在Step2中，利用Step1的組件屬性對(duì)待分析的多個(gè)APP進(jìn)行分類；在Step3中，利用分類結(jié)果精簡(jiǎn)與跨APP組件間隱私泄露無(wú)關(guān)的組件，生成潛在泄露隱私的組件序列，從而解決由于組件間依賴關(guān)系復(fù)雜而造成的路徑爆炸問(wèn)題；在Step4中，在潛在泄露隱私組件的基礎(chǔ)上，利用虛擬主函數(shù)和插樁技術(shù)解決由于Android代碼不連續(xù)性造成無(wú)法進(jìn)行靜態(tài)污點(diǎn)分析的問(wèn)題，并構(gòu)建基于精簡(jiǎn)組件的CFG；在Step5中，PLDetect利用SuSi[19](一種采用機(jī)器學(xué)習(xí)方法收集Android 敏感API的工具)收集到的敏感源和泄露點(diǎn)，在CFG上執(zhí)行應(yīng)用程序間的靜態(tài)污點(diǎn)分析，最終輸出檢測(cè)到的跨APP組件間隱私泄露的路徑.

Fig. 2 Overall framework of PLDetect圖2 PLDetect系統(tǒng)整體框架

2.1 組件屬性提取

在圖2的Step1，PLDetect利用Epicc提取Dex和AndroidManifest文件中的相關(guān)信息.Epicc是一個(gè)基于Soot編譯框架[20]和Heros數(shù)據(jù)流分析工具[21]的ICC拓?fù)涔ぞ?，能夠提取組件屬性、ICC方法和參數(shù).

PLDetect提取組件屬性為:

1) 聲明的組件列表；

2) 每個(gè)組件的intent_filter標(biāo)簽；

3) 每個(gè)組件的exported屬性值；

4) 每個(gè)組件的intent參數(shù)值.

算法1.計(jì)算組件的exported值.

輸入：Android應(yīng)用程序的組件;

輸出：true或false.

ifexplicitExported(component)=true then

returngetTheValue(“exported”)；

end if

ifcomponentType(component)=ContentProvider

then

ifSDKversion≤16 then

return true;

else

return false;

end if

end if

ifComContainIntentFilter(component)=true

then

return true;

else

return false;

end if

通過(guò)屬性1得到應(yīng)用程序中聲明的組件列表.當(dāng)組件exported屬性值為true時(shí)，則表示允許第三方APP訪問(wèn)當(dāng)前組件；反之則拒絕任何來(lái)自第三方APP訪問(wèn).因此，PLDetect采用算法1計(jì)算組件的exported屬性值，并通過(guò)屬性2和屬性4得到組件的intent參數(shù)值和intent_filter屬性值，用于組件間的匹配.

2.2 APP分類

跨APP組件間隱私泄露是由2個(gè)APP組合完成的，但是，任意2個(gè)APP組合不一定能夠達(dá)到泄露隱私的目的.因此，針對(duì)所有的APP進(jìn)行分類及相應(yīng)的篩選處理是非常必要的.

1) 根據(jù)跨APP組件間隱私泄露的條件，PLDetect認(rèn)為2種APP是良性的:

① 如果當(dāng)前APP擁有獲取隱私信息的權(quán)限，并能夠獲取隱私信息，則不能將隱私信息傳遞給第三方應(yīng)用程序.

② 如果當(dāng)前APP擁有泄露隱私信息的權(quán)限，并能夠泄露隱私信息，則不能被第三方應(yīng)用程序調(diào)用.

上述2種APP不能作為跨APP組件間隱私泄露集合中的APP.所以PLDetect對(duì)具有以上條件的APP進(jìn)行剪枝，從而避免不必要的分析時(shí)間.

2) Android組件中是否擁有隱式intent決定該APP是否能夠調(diào)用第三方APP，因此，假設(shè)當(dāng)前APP擁有隱式intent的組件，則將該APP歸類為SourceApp.Android組件的exported屬性值決定組件能否被第三方應(yīng)用程序調(diào)用，假設(shè)當(dāng)前APP擁有exported的值為true，則將該APP分為SinkApp類.假設(shè)應(yīng)用程序同時(shí)滿足上述SourceApp和SinkApp的條件，則將該APP分為SourceOrSink類.

3) 根據(jù)2)中分類結(jié)果，本文得到可能實(shí)現(xiàn)跨APP組件間泄露隱私信息的APP組合有4種形式：(SourceApp,SinkApp),(SourceApp,SourceOrSink),(SourceOrSink,SinkApp),(SourceOrSink,Source-OrSink).

2.3 生成潛在泄露隱私的組件序列

為了能夠有效精簡(jiǎn)組件間的依賴關(guān)系，構(gòu)造真實(shí)存在的并能引發(fā)隱私泄露的組件序列，PLDetect根據(jù)2.2節(jié)中得到的潛在泄露隱私的APP組合，提出一種生成潛在泄露隱私的組件序列的方法，從而解決路徑爆炸的問(wèn)題.PLDetect生成潛在泄露隱私的組件序列的方法步驟為

Step1. 根據(jù)潛在泄露隱私的APP組合中的2個(gè)應(yīng)用程序，分別生成潛在泄露隱私的組件子序列SeqA，SeqB.

Step2. 利用潛在泄露隱私的組件子序列SeqA，SeqB，構(gòu)建完整的潛在泄露隱私的組件序列.

生成潛在泄露隱私的組件子序列的具體方法是：首先，根據(jù)2.1節(jié)中得到的intent參數(shù)與intent_filter標(biāo)簽，并利用組件間匹配規(guī)則生成圖3和圖4中的組件調(diào)用關(guān)系；然后，根據(jù)組件調(diào)用關(guān)系，生成應(yīng)用程序運(yùn)行時(shí)可能出現(xiàn)的組件執(zhí)行序列；最后，PLDetect判斷組件執(zhí)行序列中是否存在能夠構(gòu)建完整的潛在泄露隱私的組件序列的組件子序列.

Fig. 3 Generation process of leakage sequence for element 1 in an APP combination圖3 APP組合中元素1泄露序列生成過(guò)程

Fig. 4 Generation process of leakage sequence for element 2 in an APP combination圖4 APP組合中元素2泄露序列生成過(guò)程

圖3表示的是2.2節(jié)中APP組合中第1個(gè)元素生成潛在泄露隱私的組件子序列的過(guò)程描述，PLDetect根據(jù)組件調(diào)用關(guān)系生成了2種組件執(zhí)行序列：1)A→B1→C；2)A→B2.然后，PLDetect采用算法2判斷1), 2)中是否存在潛在泄露隱私的組件子序列.類似地，圖4表示的是2.2節(jié)中APP組合中第2個(gè)元素生成潛在泄露隱私的組件子序列的全過(guò)程.

因此，假定經(jīng)過(guò)算法2處理之后生成的潛在泄露隱私的組件子序列分別為B1→C，E→F1.那么，最終由PLDetect生成的潛在泄露隱私的組件序列為B1→C→E→F1.其中，本序列中各個(gè)元素是與跨APP組件間隱私泄露問(wèn)題的相關(guān)組件，同時(shí)也是需要構(gòu)建CFG的組件.

算法2.判斷APP組合序列中第i個(gè)元素的執(zhí)行序列是否存在潛在泄露隱私的組件子序列.

輸入：應(yīng)用程序的執(zhí)行序列;

輸出：潛在泄露隱私的組件子序列.

iffindLefttoRight(component_sequence)=false then*findLefttoRight方法在執(zhí)行序列中尋找獲取隱私信息的組件*

return false;

else

component_first←findLefttoRight

(component_sequence);

end if

iffindRighttoLeft(component_sequence)=false then*findRighttoLeft方法在執(zhí)行序列中尋找能夠調(diào)用第三方APP的組件*

return false;

else

component_second←findRighttoLeft

(component_sequence);

end if

m←component_sequence.indexOf(component_first);

n←component_sequence.indexOf(component_second);

ifm>nthen

return false;

else

returncomponent_sequence.substring(m,n+1);

end if

2.4 生成精確的控制流圖

Android的代碼不連續(xù)性將導(dǎo)致不能把多個(gè)獨(dú)立的APP構(gòu)建成一個(gè)完整的CFG，因此，本節(jié)將詳細(xì)介紹如何解決由Android中生命周期、回調(diào)函數(shù)以及ICC方法而引入的代碼不連續(xù)性問(wèn)題.

2.4.1 生命周期

Android應(yīng)用程序沒(méi)有主函數(shù)，而是由組件生命周期函數(shù)組成的多個(gè)入口，即Android應(yīng)用程序可以根據(jù)用戶事件或系統(tǒng)事件，調(diào)用組件的每個(gè)生命周期函數(shù).如當(dāng)Activity組件處于onPause狀態(tài)時(shí)，如果該Activity被重新啟動(dòng)，則該Activity直接進(jìn)入onResume狀態(tài)，而非onCreate狀態(tài)；如果該Activity由于內(nèi)存不足被殺死而后重新啟動(dòng)時(shí)，則該Activity進(jìn)入onCreate狀態(tài).因此，由于Android框架為每個(gè)組件定義了完整的生命周期，從而造成Android應(yīng)用程序多入口的問(wèn)題，只有通過(guò)精確的模擬生命周期的變化，才能保證下一步靜態(tài)分析時(shí)得到的隱私泄露路徑的精確性.

為了解決由于生命周期引入而帶來(lái)的的不連續(xù)性問(wèn)題，根據(jù)2.3節(jié)中生成的潛在泄露隱私的組件序列，PLDetect為序列中的每個(gè)組件生成dummy-Main(虛擬主函數(shù)).按照Android開發(fā)文檔中生命周期的調(diào)用順序，PLDetect在dummyMain中精確地模擬生命周期的執(zhí)行順序，即在dummyMain中插入調(diào)用生命周期函數(shù)的語(yǔ)句.

2.4.2 回調(diào)函數(shù)

Android操作系統(tǒng)允許注冊(cè)回調(diào)函數(shù).如Button的監(jiān)聽器，用戶觸發(fā)該按鈕的點(diǎn)擊事件后，由Android框架來(lái)自動(dòng)調(diào)用onClick后的具體內(nèi)容.PLDetect使用 FlowDroid處理回調(diào)函數(shù)的方法，在dummyMain中模擬回調(diào)函數(shù)的調(diào)用.然而，回調(diào)函數(shù)被調(diào)用的順序無(wú)法預(yù)測(cè)，只有當(dāng)回調(diào)函數(shù)所在的組件運(yùn)行時(shí)，回調(diào)函數(shù)才可能被調(diào)用執(zhí)行.因此，為了考慮模擬的精確性，PLDetect建立了回調(diào)函數(shù)與組件間的對(duì)應(yīng)關(guān)系，并利用FlowDroid收集的回調(diào)函數(shù)集合，判斷潛在泄露隱私組件序列中的每個(gè)組件是否存在回調(diào)函數(shù)，如若存在回調(diào)函數(shù)，則在dummyMain中模擬回調(diào)函數(shù).即：在組件的dummyMain函數(shù)中的onResume與onPause調(diào)用語(yǔ)句之間，生成調(diào)用回調(diào)函數(shù)的語(yǔ)句，使得回調(diào)函數(shù)在dummyMain中可達(dá)，從而解決代碼不連續(xù)性問(wèn)題.

2.4.3 ICC方法

Android應(yīng)用程序中組件交互數(shù)據(jù)是通過(guò)Bundle對(duì)象和intent對(duì)象傳遞的，即ICC模型.但是，通過(guò)intent對(duì)象實(shí)現(xiàn)的代碼并沒(méi)有直接調(diào)用對(duì)應(yīng)組件，在代碼層，2個(gè)組件是獨(dú)立的、不連續(xù)的.它是由Android框架通過(guò)匹配intent與intent_filter的參數(shù)，從而實(shí)現(xiàn)組件間的匹配以及數(shù)據(jù)傳遞.

因此，本文利用Soot[13]生成Jimple中間語(yǔ)言，并結(jié)合插樁技術(shù)修改潛在泄露隱私的組件序列中組件間的ICC方法，從而解決ICC帶來(lái)的組件間代碼的不連續(xù)性問(wèn)題.

PLDetect的具體思路是：基于Jimple中間語(yǔ)言利用插樁技術(shù)修改ICC代碼，從潛在泄露隱私的組件序列的左側(cè)第1個(gè)組件開始，分別在前一個(gè)組件中實(shí)例化下一個(gè)組件，并調(diào)用helperIpc和dummyMain方法.如圖5所示:

Fig. 5 The modification method of startActivity圖5 startActivity的修改方法

在圖5中，以startActivity的修改方法為例對(duì)利用插樁技術(shù)解決ICC帶來(lái)的代碼不連續(xù)性問(wèn)題進(jìn)行說(shuō)明.其中，圖5(a)表示App1中的Activity1組件，圖5(b)表示App2中的Activity2組件.而Activity1和Activity2組件符合組件匹配規(guī)則并能傳遞數(shù)據(jù).PLDetect通過(guò)修改圖5中的代碼，使得Activity1和Activity2在代碼層上可達(dá).

在圖5(b)中，PLDetect生成helperIpc(intent)和getIntent()方法.helperIpc方法將攜帶的intent對(duì)象賦值給_intent_ipc；getIntent的返回值為_intent_ipc.helperIpc和getIntent實(shí)現(xiàn)intent對(duì)象的傳遞過(guò)程，從而替換由Android框架完成的工作.其中，圖5(b)中dummyMain方法實(shí)現(xiàn)了2.4.1節(jié)和2.4.2節(jié)的思想.

在圖5(a)中，刪除了startActivity方法，并實(shí)例化Activity2對(duì)象，然后調(diào)用helperIpc方法傳遞intent對(duì)象，將intent對(duì)象的信息傳遞到Activity2對(duì)象，并且通過(guò)調(diào)用Activity2中dummyMain方法，使得Activity1和Activity2在代碼層徹底鏈接起來(lái).

因此，在潛在泄露隱私的組件序列中，任意2個(gè)相鄰的組件都會(huì)采用上述相同的方法.

在Android系統(tǒng)中，Implicit Intent沒(méi)有以一個(gè)指定的組件命名，而是聲明需要執(zhí)行的操作，該操作允許第三方應(yīng)用程序的組件去處理它.例如：如果在地圖上展示用戶的位置，可以使用1個(gè)Implicit Intent去請(qǐng)求第三方應(yīng)用程序在地圖上展示指定的位置.因此，基于跨APP組件間隱私泄露的問(wèn)題，應(yīng)用程序間的數(shù)據(jù)傳遞本質(zhì)上是使用intent對(duì)象攜帶、ICC方法(如startActivity等)傳遞實(shí)現(xiàn)的，所以，針對(duì)APP間代碼的不連續(xù)性，本文采用上述方法處理.基于潛在泄露隱私組件序列的插樁技術(shù)，一方面有效解決了IccTA等方法存在的路徑爆炸、工作量龐大、分析效率低的問(wèn)題，另一方面克服了現(xiàn)有方法作用域?yàn)閱为?dú)應(yīng)用程序內(nèi)部組件的局限性.

最后，在解決代碼不連續(xù)性問(wèn)題后，PLDetect將這些APP之間與隱私泄露相關(guān)的組件構(gòu)建成1個(gè)完整的CFG.并且利用SuSi收集Android API中的敏感源和泄露點(diǎn)方法集合，在構(gòu)建的CFG上執(zhí)行應(yīng)用程序間的靜態(tài)污點(diǎn)分析，跟蹤隱私信息的數(shù)據(jù)流流向，得到并輸出檢測(cè)到的跨APP組件間隱私泄露的路徑.

PLDetect以非侵?jǐn)_的方式工作在后臺(tái)，并將上述步驟中得到的隱私信息泄露路徑作為輸入，使用插樁技術(shù)來(lái)修改路徑中組件所在的Android應(yīng)用程序.以此來(lái)保證隱私信息在被惡意應(yīng)用泄露前被加密或替換為無(wú)效的數(shù)據(jù)，從而在不影響APP正常執(zhí)行的情況下緩解隱私信息泄露造成的風(fēng)險(xiǎn)和危害.具體來(lái)講，因?yàn)镾oot支持閱讀和重寫Davilk字節(jié)碼，因此PLDetect在上述Soot生成Jimple的基礎(chǔ)上，通過(guò)插樁修改相關(guān)Android程序來(lái)達(dá)到數(shù)據(jù)加密或替換的目的.假設(shè)APP1的Activity1與APP2的Activity2經(jīng)檢測(cè)是2個(gè)符合跨APP間隱私泄露的組件并通過(guò)intent傳遞隱私信息.那么，PLDetect將在Activity1中插入1個(gè)字段，且該字段的作用是唯一標(biāo)識(shí)Activity2所在的APK的包名.同時(shí)，在Activity2組件中，PLDetect會(huì)以Jimple形式插入一段功能代碼.這段代碼的主要作用是判斷從intent中獲取到的字段值是否與自身包名一致，若一致則加密或替換隱私信息的值,若不一致則不修改.因此，PLDetect采取了簡(jiǎn)單有效的方法，在保證用戶良好體驗(yàn)的前提下解決了隱私被泄露的隱患.

3 系統(tǒng)評(píng)測(cè)實(shí)驗(yàn)與分析

為了驗(yàn)證跨APP組件間隱私泄露的檢測(cè)模塊的檢測(cè)效果，本文主要從觸發(fā)程序和商業(yè)應(yīng)用2方面進(jìn)行驗(yàn)證.其中，觸發(fā)程序是指實(shí)現(xiàn)跨APP組件間隱私泄露的6組APP集合，此類應(yīng)用程序沒(méi)有多余干擾路徑，主要是為了驗(yàn)證PLDetect功能而開發(fā)的應(yīng)用程序.這些應(yīng)用程序包含Activity, Service, Broadcast Receiver等不同的Android組件.如表1所示.商業(yè)應(yīng)用是指在360 Market中隨機(jī)選擇的81個(gè)真實(shí)應(yīng)用，部分應(yīng)用程序信息如表2所示.

Table 1 The Sets of Triggered Program表1 觸發(fā)程序測(cè)試集

Table 2 The Sets of Business Application表2 商業(yè)應(yīng)用測(cè)試集

3.1 觸發(fā)應(yīng)用

如表1所示，為了驗(yàn)證PLDetect系統(tǒng)功能的有效性，本文共構(gòu)造了6組實(shí)現(xiàn)跨APP組件間隱私泄露的觸發(fā)程序，這些觸發(fā)程序中沒(méi)有設(shè)置多余干擾檢測(cè)的組件與路徑.我們通過(guò)人工對(duì)比PLDetect的檢測(cè)結(jié)果與預(yù)設(shè)的泄露隱私路徑，從而驗(yàn)證PLDetect對(duì)跨APP組件間隱私泄露的檢測(cè)效果.

經(jīng)過(guò)PLDetect分析，表1中6組(共8個(gè))觸發(fā)程序的分類結(jié)果為：SourceApp類別的Android APP有G1和G2；SinkApp類別的Android APP有L1，L2，…，L6；SourceOrSink類別中沒(méi)有Android APP.在分類結(jié)果的基礎(chǔ)上，我們可以得到的潛在泄露隱私的APP組合序列共計(jì)12組，如圖6所示.

Fig. 6 The comparison of test results圖6 檢測(cè)結(jié)果對(duì)比

PLDetect分析得到，12組潛在泄露隱私的APP組合序列中存在6組Android APP能夠泄露隱私信息，并輸出泄露隱私的路徑.經(jīng)過(guò)人工比較PLDetect的檢測(cè)結(jié)果與預(yù)設(shè)的泄露隱私的路徑，兩者完全一致，正確率達(dá)100%.

3.2 商業(yè)應(yīng)用

在我們選取的實(shí)際商用Android APP中，平均每個(gè)應(yīng)用程序包含組件高達(dá)134個(gè)，面對(duì)平均134個(gè)組件間錯(cuò)綜復(fù)雜的關(guān)系，很容易影響PLDetect的檢測(cè)結(jié)果.因此，為了進(jìn)一步驗(yàn)證PLDetect的檢測(cè)效果，選取了81個(gè)真實(shí)應(yīng)用作為實(shí)驗(yàn)對(duì)象.

Fig. 7 The results of classification圖7 分類結(jié)果

根據(jù)2.2節(jié)的分類規(guī)則，PLDetect得到的分類數(shù)據(jù)如圖7所示，組件exported屬性值為true的數(shù)目為2 301個(gè)，占組件總數(shù)10 815的21.28%.其中，29個(gè)應(yīng)用程序包含exported屬性值為true的組件，即此29個(gè)Android APP能夠被第三方應(yīng)用程序調(diào)用；10個(gè)應(yīng)用程序包含有隱式intent或顯式調(diào)用第三方應(yīng)用程序的組件，即此10個(gè)Android APP能夠調(diào)用第三方應(yīng)用程序；42個(gè)應(yīng)用程序既包含exported屬性為true的組件，同時(shí)能夠調(diào)用第三方應(yīng)用程序.實(shí)驗(yàn)結(jié)果說(shuō)明52%的應(yīng)用程序同時(shí)具備SourceApp與SinkApp的特點(diǎn)，將成為泄露隱私信息的重要組成部分.

進(jìn)一步地，PLDetect對(duì)獲取隱私和泄露隱私的API進(jìn)行了統(tǒng)計(jì).結(jié)果顯示，在獲取隱私的API中，getLongitude和getLatitude被使用的次數(shù)最多，達(dá)到了1 834次，如表3所示；在泄露隱私的API中，Log被使用的次數(shù)最多，高達(dá)66 711次，如表4所示.根據(jù)上述數(shù)據(jù)推測(cè)，隨著位置探測(cè)設(shè)備和地理位置信息系統(tǒng)的開發(fā)、應(yīng)用及推廣，使得基于位置信息服務(wù)(location-based service， LBS)的Android應(yīng)用程序越來(lái)越多，百度地圖、微信、滴滴打車等常用Android應(yīng)用程序都需要位置的支持.因此，Android應(yīng)用程序中使用getLongitude和getLatitude次數(shù)非常多，同時(shí)導(dǎo)致位置信息泄露的威脅增大.Log能夠輸出程序的中間結(jié)果，是調(diào)試Android APP的一種常用手段，但是，上述數(shù)據(jù)顯示Log的使用次數(shù)過(guò)多，可能是由于程序員在調(diào)試后沒(méi)有刪除Log代碼，導(dǎo)致Log遺留在Andorid APP中，從而造成隱私信息泄露的威脅增大.

Table 3 The Sets of API to Get Privacy Information表3 獲取隱私的API

Table 4 The Sets of API to Leak Privacy Information表4 泄露隱私的API

其次，以PLDetect發(fā)現(xiàn)的1個(gè)具體實(shí)例來(lái)描述跨APP組件間隱私泄露的細(xì)節(jié).PLDetect檢測(cè)發(fā)現(xiàn)com.pdswp.su.smartcalendar和com.xkfop.xhuioa能夠合作實(shí)現(xiàn)跨APP組件間隱私泄露.其中com.pdswp.su.smartcalendar中用戶輸入的備忘錄內(nèi)容被com.xkfop.xhuioa劫持，導(dǎo)致備忘錄內(nèi)容被com.xkfop.xhuioa泄露.具體分析為：1)通過(guò)com.pdswp.su.smartcalendar.bean.NoteItemBean類中的方法getNote得到備忘錄內(nèi)容，并將備忘錄內(nèi)容賦給putExtra方法的參數(shù)；2)通過(guò)startActivity傳遞出去，被com.xkfop.xhuioa中的類com.xkfop.sendService的getIntent方法得到參數(shù)android.intent.extra.TEXT的值，并通過(guò)sendTextMessage將備忘錄內(nèi)容泄露.

PLDetect在這81個(gè)真實(shí)應(yīng)用中共識(shí)別和檢測(cè)到5組跨APP組件間隱私泄露程序.通過(guò)統(tǒng)計(jì)PLDetect發(fā)現(xiàn)的這5組存在跨APP組件間隱私泄露情況的程序包發(fā)現(xiàn)其中通過(guò)Activity泄露隱私信息的為2個(gè)，通過(guò)Service泄露隱私信息的為3個(gè)，通過(guò)Broadcast Receiver泄露隱私信息的為0個(gè).理論上Service組件隱藏在后臺(tái)運(yùn)行，不會(huì)與用戶進(jìn)行交互，相對(duì)來(lái)說(shuō)難以引起用戶的注意.實(shí)驗(yàn)數(shù)據(jù)顯示，Service組件更容易被惡意軟件利用而引發(fā)隱私泄露，與理論分析一致.

PLDetect檢測(cè)到僅有少量的APP組合存在跨APP組件間隱私泄露問(wèn)題，主要原因在于：360 Market中的APP基本都屬于良性應(yīng)用程序，即使在一般條件下存在ICC漏洞的良性應(yīng)用程序較多，但是通過(guò)2個(gè)良性APP配合達(dá)到泄露隱私信息的可能性非常低.更多的情況是，APP組合中一個(gè)為惡意軟件，另外一個(gè)則是存在ICC漏洞的良性APP，而據(jù)ComDroid研究證明，60%的應(yīng)用程序至少存在1個(gè)以上的ICC漏洞.因此，在真實(shí)的用戶使用環(huán)境中將存在更多的跨APP組件間隱私泄露攻擊情況.

4 結(jié)論與工作展望

本文設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)檢測(cè)跨APP組件間隱私泄露的自動(dòng)化工具PLDetect.PLDetect有效地去除了與跨組件間隱私泄露無(wú)關(guān)的組件，并將虛擬主函數(shù)和插樁技術(shù)進(jìn)行了有效結(jié)合，解決了在構(gòu)建CFG時(shí)出現(xiàn)的路徑爆炸以及代碼不連續(xù)性問(wèn)題.最終PLDetect實(shí)現(xiàn)了通過(guò)靜態(tài)污點(diǎn)分析技術(shù)檢測(cè)和識(shí)別與跨APP組件間隱私泄露相關(guān)的路徑.實(shí)驗(yàn)表明該系統(tǒng)能夠有效發(fā)現(xiàn)和阻止跨APP組件間隱私泄露問(wèn)題.

本文重點(diǎn)研究了跨APP組件間隱私泄露的檢測(cè)和防護(hù)方法，實(shí)驗(yàn)評(píng)估體現(xiàn)了該系統(tǒng)的有效性.其他相關(guān)問(wèn)題，例如對(duì)復(fù)雜且較少用到的ICC方法的分析、用戶體驗(yàn)與隱私泄露之間的權(quán)衡等，將在今后的工作中進(jìn)一步探索.