張志威,甘 剛

(成都信息工程大學網(wǎng)絡空間安全學院，四川 成都 610225)

0 引 言

Android系統(tǒng)因其智能化的操作和應用廣受各大廠商推崇與二次開發(fā)，手機市場占有率逐年攀升。智能移動終端承載著億萬移動用戶的生產生活，良好的便攜性及系統(tǒng)生態(tài)獲得了廣大用戶的喜愛。但與此同時，暴露出的Android漏洞數(shù)目也隨之增長。因此，Android系統(tǒng)的安全性也一直是安全研究人員關注的重點。

據(jù)CNVD(China Nation Vulnerability Database)及其他知名漏洞提交平臺查詢發(fā)現(xiàn)，以往提交的Android漏洞集中于應用層，大多為組件暴露[1]、信息泄露、二次重打包[2]、權限提升等類型，但對系統(tǒng)服務層面的研究探索較少。而Android系統(tǒng)服務作為運行在系統(tǒng)底層的核心進程，一旦被惡意程序獲取到相關權限，則可能會導致隱私泄露。此外如果服務在運行過程中接收使用了傳入的非法參數(shù)，則可能會致使系統(tǒng)重啟、拒絕服務甚至內存損壞等不可知結果。文獻[3]在對Android系統(tǒng)服務漏洞挖掘的過程中使用了模糊測試的方法，但測試數(shù)據(jù)類型單一，未對通信過程中復雜的參數(shù)類型進行構造，某種程度上導致了參數(shù)用例覆蓋的不全面。文獻[4]同樣利用模糊測試的方法對系統(tǒng)服務進行漏洞挖掘，但對系統(tǒng)服務中多維參數(shù)的變異[5]沒有進行合理的控制處理，可能會導致組合爆炸等問題。如何解決模糊測試過程中用例覆蓋率低及多維參數(shù)變異的問題也一直是漏洞挖掘人員的研究重點。

因此，本文將遺傳算法與模糊測試技術結合起來，通過適應度函數(shù)對參數(shù)進行變異指導，保證了參數(shù)的多樣性，并且根據(jù)數(shù)據(jù)類型變異優(yōu)先級表對不同參數(shù)也進行相應的組合變異操作。該方法在一定程度上減小了組合爆炸對參數(shù)遺傳變異的影響，提高了測試用例的覆蓋率。

1 背景知識介紹

1.1 Android系統(tǒng)服務

Android終端的流暢運行離不開系統(tǒng)服務的支持，如短信的接收與發(fā)送需要短信管理服務SmsManager,窗口的打開與關閉需要窗口管理服務WindowManager等，各種服務Manager提供對底層的訪問接口，方便了上層應用的調用。Android系統(tǒng)服務主要分為守護進程服務、本地系統(tǒng)服務和Java系統(tǒng)服務。守護進程是為處理系統(tǒng)多任務請求而在后臺運行的Server程序。此類進程在系統(tǒng)啟動初始化中生成，常駐系統(tǒng)后臺，直至系統(tǒng)運行結束。其中典型的有用于圖像合成顯示的SurfaceFlinger服務、管理Binder對象的ServiceManager等。第二類本地系統(tǒng)服務數(shù)量較少，一般使用C/C++編寫，運行在LIBRARIES層中[6]，包括AudioFlinger音頻服務、CameraService相機服務等其他重要服務。最后就是Java系統(tǒng)服務，該類服務由SystemServer系統(tǒng)進程啟動，并以線程的形態(tài)運行在SystemServer進程中。Java系統(tǒng)服務又分為核心平臺服務和硬件系統(tǒng)服務。核心系統(tǒng)服務提供了系統(tǒng)正常運行基本的功能，與應用程序交互較少，但卻是Android Framework運行所必需依賴的。而硬件服務則為上層應用提供接口，用于控制底層硬件提供服務。常用的Android系統(tǒng)服務如表1所示。

表1 常用系統(tǒng)服務

SystemServer進程中運行著諸多Java系統(tǒng)服務，應用如果想調用系統(tǒng)服務，就要以跨進程的方式與系統(tǒng)服務進行通信。Android系統(tǒng)不同進程間的信息交互要使用Binder通信機制，例如當上層應用要調用發(fā)送短信的API,其底層實現(xiàn)就是通過Binder對象調用短信的系統(tǒng)服務。每個系統(tǒng)服務中封裝定義了實現(xiàn)相應功能的方法，而這些接口方法則是本文進行模糊測試漏洞挖掘的研究對象。

1.2 Binder通信機制

Android為保證進程安全采用了沙箱隔離的機制[7]，但不同進程間往往需要信息數(shù)據(jù)交換。傳統(tǒng)的通信方式如管道、消息隊列等是通過讀寫內核緩沖區(qū)的方式獲取數(shù)據(jù)，2次復制過程存在效率問題，而套接字資源開銷較大，多用于網(wǎng)絡相關傳輸。此外，這些通信方式無法確認雙方的身份，容易被攻擊。而Binder通信機制使用內存映射的方式只對內容拷貝一次，發(fā)送過程中會添加身份識別ID，并且采用C-S架構，是一種安全高效的進程通信方式[8]。系統(tǒng)服務想要被調用，要先通過Binder通信機制跨進程在ServiceManager中注冊，這樣上層就可以通過Binder對象直接從用戶空間到底層訪問服務。

Binder通信架構主要由客戶端進程、服務端進程、ServiceManager、Binder驅動4個部分組成。前3者運行在用戶空間，服務端進程在ServiceManager中注冊后，由客戶端進程發(fā)出服務請求，進而才能使用服務[9]。ServiceManager主要提供輔助管理的功能，而Binder驅動運行在內核空間以負責各個進程間通信。當跨進程通信發(fā)生時，Server進程擁有Binder對象，而Client進程會調用其關聯(lián)BinderProxy對象實例的transact方法發(fā)起請求[10]，通過IPC的方式傳遞到Server端。Server接收到參數(shù)后調用服務端的transact方法，最終由onTransact執(zhí)行相應的邏輯并將結果返回給Client端。Binder通信模型如圖1所示。

圖1 Binder通信模型

2 系統(tǒng)服務模糊測試技術分析

模糊測試是基于黑盒的安全測試技術[11]，通過向程序輸入隨機數(shù)據(jù)導致程序崩潰或產生異常，進而發(fā)現(xiàn)應用中的潛在漏洞。對于Android系統(tǒng)服務的模糊測試，首先要確定用例參數(shù)的數(shù)據(jù)入口。經(jīng)過分析，上層應用對系統(tǒng)服務的調用是通過Binder實現(xiàn)的，請求服務都會調用到transact方法?？梢钥紤]將底層transact方法作為測試入口，但該方法存在于系統(tǒng)底層，用例參數(shù)無法直接傳入，不適合作為入口的選擇。通過分析底層transact函數(shù)的上下文調用關系，發(fā)現(xiàn)Java上層Binder類實際是對底層功能實現(xiàn)的封裝，上層使用Binder調用服務會使用Binder代理類的transact方法，層層傳遞最終仍會調用到底層的transact函數(shù)，且參數(shù)是原樣傳入底層。該方法符合測試接口低權限、參數(shù)透傳性好的要求，且代碼容易實現(xiàn)，因此可以選擇上層Binder類的transact方法作為模糊測試的數(shù)據(jù)入口。

transact函數(shù)原型為bool transact(int code,Parcel data,Parcel reply,int flags)[4]，方法返回值為布爾型。其中code是int類型，對應的是Aidl文件中定義接口的方法號，從1開始，依次遞增。data是Parcel類型，用來保存接口的各個參數(shù)數(shù)據(jù)。reply也是Parcel數(shù)據(jù)類型，用來保存服務端返回的數(shù)據(jù)。而flag為通信類型標志位，0表示請求發(fā)起后需要等待返回的普通RPC(Remote Procedure Call)類型，1則表示為單向的RPC通信，即不需要接收返回信息。其中data中所存放的參數(shù)則是要進行構造填充Fuzz的數(shù)據(jù)。如在某服務中定義了接口號為10的方法：test(int a,String b，double c)。則transact方法的構造如圖2所示。

圖2 transact方法構造示例

測試模塊獲取到接口參數(shù)類型后構造初始測試用例，并通過trancact函數(shù)調用系統(tǒng)服務，然后監(jiān)控手機是否發(fā)生異常，這樣就完成一次基本的模糊測試。

3 ASFuzzer系統(tǒng)設計與實現(xiàn)

3.1 設計思想與架構

遺傳算法[12]是模擬生物自然進化的一種求解復雜問題的通用計算模型，通過適應度函數(shù)對個體差異進行評價，從而對其進行個體優(yōu)選、基因交叉、數(shù)據(jù)變異操作。遺傳過程中逐漸將劣質個體淘汰，優(yōu)秀個體遺傳給下一代，使個體最終趨于最優(yōu)。本文根據(jù)系統(tǒng)服務漏洞挖掘實際場景，將遺傳算法思想巧妙運用到測試用例的生成過程中，設計實現(xiàn)了Android系統(tǒng)服務漏洞挖掘工具ASFuzzer。該工具將單次測試結果作為適應度函數(shù)的評判標準[13]，指導參數(shù)進行變異，保證了新一輪測試參數(shù)用例的有效遺傳，而對于無效的參數(shù)則拋棄并重新生成有效數(shù)據(jù)；并且在單個數(shù)據(jù)變異有效的前提下，通過排列組合的方式，對不同參數(shù)也進行相應的變異，有效提升測試用例覆蓋率。

ASFuzzer是一款針對Android系統(tǒng)服務安全測試的半自動化工具，可以安裝到不同Android版本系統(tǒng)進行測試，包括谷歌原廠鏡像及第三方定制系統(tǒng)。該工具分為模糊測試和遺傳變異2個模塊。模糊測試模塊主要是對服務接口進行測試并進行結果反饋。該模塊首先使用反射機制獲取到系統(tǒng)服務信息，同時將服務接口、參數(shù)等信息保存在數(shù)據(jù)庫以供調用。而后，根據(jù)接口參數(shù)類型構造生成初始測試用例，通過Binder調用transact方法對服務進行測試，而測試結果則會輸出到日志中，最終反饋給遺傳變異模塊。遺傳變異模塊則主要對參數(shù)用例進行優(yōu)化、變異。在獲取到前次的結果反饋后，根據(jù)相應的策略，對單個參數(shù)或者多個參數(shù)進行變異，然后再次循環(huán)測試，直至發(fā)現(xiàn)漏洞或到達變異次數(shù)。其整體設計框架如圖3所示。

圖3 ASFuzzer整體設計框架

3.2 模糊測試模塊

該模塊功能主要對服務接口進行測試，并將結果進行反饋。

1)服務接口信息獲取。

系統(tǒng)服務相關信息主要是通過對ServiceManager反射來獲取的。ServiceManager是系統(tǒng)服務的管理者，其內部維護了已注冊系統(tǒng)服務的Binder對象列表，這樣可以通過反射android.os.ServiceManager的方式獲取其對象實例，再反射[14]調用listservices方法就可以得到系統(tǒng)中運行的服務信息。而調用getService則會得到相應服務的Binder句柄。

對于測試用例的構造，需要獲得測試服務的接口號及對應參數(shù)。當獲取到服務的Binder句柄后,可以通過反射“接口描述符+＄Stub”的方法獲取服務中的各種方法屬性。其中會有以“TRANSACTION_”開頭的方法及屬性描述，而屬性中int型就是該方法對應的接口號[4]。最后通過將接口描述符傳入Class.forname進而反射調用getDeclaredMethods和getParameterTypes的方式獲取服務所定義的接口方法及參數(shù)類型。

2)測試用例的構造與發(fā)送。

測試用例的構造直接關乎數(shù)據(jù)能否順利通過目標的參數(shù)校驗[15]。通過對數(shù)據(jù)庫中參數(shù)類型分析統(tǒng)計可得，除了常規(guī)類型外，還有一些Binder、Component Name、Intent等系統(tǒng)類類型。對于可以構造的參數(shù)類型，通過常識去進行構造或者對其進行反射構造函數(shù)獲取，而對于無法直接或間接構造的類型，使用null值對其填充。為了大概率構造異常數(shù)據(jù)，初始值的選擇一般選擇邊界值或者0值附近的值，樣本初始數(shù)據(jù)構造如表2所示。

表2 初始數(shù)據(jù)構造表

測試用例的構造即transact需要發(fā)送的內容。第一個填充的是方法接口號，第二個data則要填充各種類型的參數(shù)數(shù)據(jù)。但data要先填充該服務的接口描述符，以保證數(shù)據(jù)順利通過底層校驗，然后再根據(jù)參數(shù)類型選擇初始數(shù)據(jù)填充。replay默認為空，而flag參數(shù)一般填充0。最后獲取到待測服務的Binder句柄，調用transact方法即可對接口號對應的方法發(fā)起測試。

3)日志異常監(jiān)控。

日志異常反饋對測試用例的遺傳變異具有重要的指導作用[16]。ASFuzzer在測試過程中可能會出現(xiàn)各種異常，如參數(shù)不合法、Binder失活、系統(tǒng)進程崩潰、手機重啟等其他不可知后果，因此需要對ASFuzzer及系統(tǒng)狀態(tài)進行監(jiān)控記錄。主要記錄有2部分內容：

①ASFuzzer模糊測試過程中所發(fā)送的測試用例，transact的返回值，replay接收服務端的返回信息，以及其他異常。該部分異常信息，需要反饋給遺傳變異模塊，作為前次測試用例的適應度評判。

②系統(tǒng)相關日志，用來記錄系統(tǒng)崩潰或重啟以及其他未知異常。

ASFuzzer實現(xiàn)了日志記錄的功能，將測試結果等信息導出到文件中。這樣有利于事后快速定位異常發(fā)生的服務接口及其當次所發(fā)送的參數(shù)等，提高了確認漏洞的效率。

3.3 遺傳變異模塊

遺傳算法不斷優(yōu)化個體的思想，可以應用到系統(tǒng)服務測試數(shù)據(jù)生成中。整體過程可分為初始化樣本，適應度函數(shù)評價、變異、交叉、選擇等。其流程如圖4所示。

圖4 遺傳變異模塊流程

1)編碼方案與適應度函數(shù)的確定。

編碼是將問題空間的解轉化為遺傳過程中所能識別的基因個體，是對問題解的一種表現(xiàn)形式[17]。作為遺傳算法中個體進化變異的基礎，編碼形式往往會根據(jù)實際問題情況而采取不同的方案。對于系統(tǒng)服務的漏洞挖掘，測試用例中的參數(shù)沒有固定的數(shù)據(jù)類型。為了更好地被底層接口識別，可以將參數(shù)類型作為編碼方案的選取，直接采用對應數(shù)據(jù)類型的實數(shù)作為編碼個體的選擇[18]。每個參數(shù)即為編碼個體，不用對其解碼，簡化了算法過程。

適應度函數(shù)是對個體進行優(yōu)良判斷的定量準則，以個體適應度的大小來確定該個體在選擇階段被選中的概率[19]。適應度值越大，被選為優(yōu)秀個體進行遺傳的概率也越大，進而引導程序向最優(yōu)解方向發(fā)展。常規(guī)適應度函數(shù)的選取會直接采用待求函數(shù)，通過待求函數(shù)對當前用例的直接反應來判斷個體的好壞。這種用待求解問題的標準來對個體適應性進行評估的方法，可以充分表達求解問題的需求。

系統(tǒng)服務模糊測試的目的是通過不斷發(fā)送異常參數(shù)來挖掘漏洞。觸發(fā)漏洞是最終目標，而觸發(fā)漏洞的異常參數(shù)就是待求的解。遺傳算法的選擇變異過程可以生成各種正?；蚍钦?shù)，測試參數(shù)取值的多樣化往往能夠大概率發(fā)現(xiàn)漏洞。結合系統(tǒng)服務實際情況，可以將適應度函數(shù)定義如下:

(1)

其中，n為測試樣例中參數(shù)個數(shù)，該模型適用于單參數(shù)和多參數(shù)的場景。當只有一個參數(shù)時，適應度函數(shù)就是一個二項分布函數(shù)。測試用例中有多個參數(shù)時，每種類型參數(shù)的適應度都為參數(shù)數(shù)目分之一，原因是每個類型的參數(shù)有可能是優(yōu)異個體或者是劣質個體。在未觸發(fā)到異常之前，無法片面去評判某種類型參數(shù)的優(yōu)劣，所以在后續(xù)過程中要使用合適的選擇算子對個體做出挑選。如果測試用例觸發(fā)異常，遺傳概率則為0，即不對其進行變異，此時需要對參數(shù)變進行觀察，判斷參數(shù)應該選擇拋棄還是觸發(fā)了漏洞，選擇拋棄則需要重新生成初始數(shù)據(jù)，而觸發(fā)漏洞則說明已經(jīng)達到了測試效果，獲取到問題的最優(yōu)解。未觸發(fā)異常時，測試用例適用度為1/n，則需要對測試用例進行選擇交叉變異等操作，再次進行測試。

2)選擇算子的選取。

選擇操作是使用選擇算子從前次測試群體中選擇優(yōu)秀個體，進行交叉變異后遺傳給下一代的一種選擇機制，是遺傳變異過程中保優(yōu)去劣的重要一環(huán)。常用的選擇模式有輪盤賭選擇[20]、最佳個體保存、排序模型、聯(lián)賽選擇模型等[21]。每種模式都有其優(yōu)缺點，對于單個參數(shù)的測試用例，在初始樣本未觸發(fā)到系統(tǒng)異?；蚵┒吹那闆r下，根據(jù)適應度函數(shù)計算，其值為1。選擇算子模式為確定性選擇，即當前測試用例個體U為優(yōu)異個體，將會遺傳給下一代進行交叉變異。后續(xù)單個參數(shù)的用例同樣采取該選擇模式。

實際測試中，單個參數(shù)的測試用例較少，多為2個及以上參數(shù)。用例Group(U1,U2,U3，…，UN)初始群體經(jīng)過首輪測試，代入適應度函數(shù)得出每個個體Ui的適應度值均為1/n。在個體適應度相等的情況下，如何選擇優(yōu)異個體對于后續(xù)用例的遺傳尤為重要。為了減小多維參數(shù)同時變異對遺傳選擇過程的干擾，在結合類型概率排序的前提下，提出一種基于組合的遺傳算子挑選模型。該模型首先對測試用例中的參數(shù)類型進行一個變異優(yōu)先級排序，再根據(jù)組合公式挑選每次測試需要變異的個體。參數(shù)類型排序是根據(jù)其在服務接口中出現(xiàn)頻數(shù)及參數(shù)個體的可變異空間分配優(yōu)先級。參數(shù)個體有所屬的數(shù)據(jù)類型，每種參數(shù)類型有其特定的數(shù)據(jù)范圍。如布爾型只有false和true，字節(jié)型取值范圍為(-128,127),而整型、浮點型等類型的取值范圍就很大。為更快收斂到最優(yōu)解，挖掘到漏洞，將出現(xiàn)頻數(shù)高且變異空間取值范圍小的數(shù)據(jù)類型分配高優(yōu)先級，而將需要構造的參數(shù)類型的默認為低優(yōu)先級。因此定義了類型變異選擇優(yōu)先級如表3所示，其中數(shù)值越小代表其被優(yōu)先挑選的概率越大。

表3 類型變異選擇優(yōu)先級表

測試用例中的參數(shù)首先根據(jù)類型變異選擇優(yōu)先級表對參數(shù)類型進行一個排序，然后再根據(jù)選擇算子挑選算法選出該次需要變異的個體。挑選算法過程具體如下。

定義：

PriorityMap//根據(jù)表3定義

Group(ParaType_U1,ParaType_U2,…,ParaType_Un)

PriorityList=[] //用來保存參數(shù)對應的優(yōu)先級

ParaTypePriorityMap

M=Group.length //參數(shù)群體個數(shù)

算法：

輸入：當前測試參數(shù)群體Group(ParaType…)

for(i=0;i

{

Priority=PriorityMap.get(Group[i])

if(PriorityList.exist(Priority))//判斷同類型

Priority=Priority+"-"+i; //同優(yōu)先級添加標志

ParaTypePriorityMap.put(Group[i]:Priority)

PriorityList.add(Priority)

}

PriorityList=Sort(PriorityList) //從小到大排序

for(j=1;j<=M;j++)

{Combination_select(PriorityList,M,j)}

Combination_select函數(shù)以組合公式為原型：

輸出：被挑選的優(yōu)先級數(shù)字序列[x]。

下面以輸入group(int,byte,long)為例：

①根據(jù)類型選擇優(yōu)先級映射表得到：

ParaTypePriorityMap(int:6,byte:2,long:8)

PriorityList[6,2,8]

②排序：

PriorityList[2,6,8]

代入組合公式(1<=j<=3)：

Combination_select([2,6,8],3,j)

③當j=1,輸出:[2],[6],[8]

當j=2,輸出:[2,6],[2,8],[6,8]

當j=3,輸出:[2,6,8]

④根據(jù)ParaTypePriorityMap可得：

第一次被選擇類型為byte

第二次被選擇類型為int

…

第四次被選擇類型為int，byte

…

第七次被選擇類型為int,byte,long

初始群體根據(jù)對應的參數(shù)類型生成優(yōu)先級序列，在對應過程中要注意種群中可能存在相同參數(shù)類型，可添加相應標志進行區(qū)分。然后序列排序后代入組合公式函數(shù)進行挑選。最后被挑選的優(yōu)先級序列再對照找到其對應的數(shù)據(jù)類型。要注意的是該算法選擇的是多個參數(shù)中哪些類型的參數(shù)需要改變，并不影響測試模塊中數(shù)據(jù)的填充順序。在一組測試用例遺傳變異過程中，被選擇到的個體默認是被選中的優(yōu)秀個體，即將對其進行交叉變異操作，而用例中沒有被選中的個體則保持原值傳遞，直至次數(shù)達到或者觸發(fā)漏洞。此種遺傳算子挑選模型在一定程度上避免了組合爆炸帶來的混亂問題，也保證了優(yōu)秀個體的有效傳遞。

3)交叉變異操作。

參數(shù)用例的多樣性越好，觸發(fā)漏洞的幾率就越大。而交叉變異就是使不同個體向較為優(yōu)化的局部疊加，生成新個體的主要過程。作為被挑選的優(yōu)秀個體，需要對其進行相應的交叉變異操作。結合遺傳算法編碼方案的選取，為簡化算法和保留個體有效性，對個體不采取交叉操作，只對其進行變異操作。常用的變異策略有隨機變異、邊界變異、多項式變異等[22]。結合模糊測試實際情況，參數(shù)個體都有不同的數(shù)據(jù)類型，所以根據(jù)參數(shù)所屬類型的差別也采取相應的變異策略。對于int、float、long、double等常規(guī)類型參數(shù)，變異算子如圖5所示。

圖5 變異算子選擇模型

數(shù)值根據(jù)[1,2,3,4,5]元素排列組合生成的序列執(zhí)行不同的操作，其中為保證生成的數(shù)據(jù)能發(fā)散到各個數(shù)據(jù)段，constant值也根據(jù)類型相應變化賦值。該次變異后的數(shù)據(jù)會被保存作為下次的初始值輸入，保證數(shù)據(jù)有效性地傳遞。而對于int[]、float[]等數(shù)組類型的數(shù)據(jù)，其中變異的不只是數(shù)據(jù)，還有數(shù)組的長度。對于數(shù)據(jù)的填充，仍可以采用以上的常規(guī)類型的遺傳算子進行生成。長度的控制則每次動態(tài)生成，可以通過該測試次數(shù)對自定義的最大長度取余加1確定。

對于Binder、ComponentName等非常規(guī)數(shù)據(jù)類型，變異方式采用隨機變異。Binder是各種服務的句柄，可以通過反射得到。ComponentName類型的參數(shù)，可以根據(jù)系統(tǒng)內置的一些固定用法進行構造。而對于存在多個構造函數(shù)的參數(shù)類，構造函數(shù)的選取可以使用隨機變異，但構造函數(shù)中常規(guī)類型參數(shù)的構造仍采用圖5所示的變異算子進行構造填充。

4)終止條件。

ASFuzzer框架默認下一代用例更優(yōu)，即要對用例進行遺傳變異操作。當測試用例中的異常參數(shù)觸發(fā)漏洞，則可終止測試[23]。但大多數(shù)測試用例可以順利通過接口測試，對于這種情況，就需要對變異次數(shù)進行一定的限制。對于單個參數(shù)的變異，次數(shù)區(qū)間建議設置在[300,500]，而對于多個參數(shù)的變異，則主要是根據(jù)接口參數(shù)類型的不同組合進行次數(shù)限制。每種不同的參數(shù)類型變異組合測試可設置為300次。而對于那些接口有權限檢測或者參數(shù)校驗的情況，當用例測試到一定次數(shù)即可停止測試，判定此接口安全。

4 實驗結果與驗證分析

4.1 實驗環(huán)境

ASFuzzer測試框架采用Java語言開發(fā)，并將其安裝在不同系統(tǒng)的手機上進行測試，包括谷歌原生Android系統(tǒng)及第三方定制系統(tǒng)。實驗均采用真機測試，以保證結果的真實可靠。其中Nexus5x手機搭載谷歌原生系統(tǒng)版本分別為bullhead Android 6.0.0、bullhead Android 7.1.1和bullhead Android 8.1.0。Pixel手機搭載谷歌原生系統(tǒng)sailfish Android 9.0.0和sailfish Android 10.0.0。小米機型為MI3,系統(tǒng)為MIUI8 7.6.11|開發(fā)版。OPPO機型為OPPO-R9s-Plus,操作系統(tǒng)為ColorOS。

4.2 系統(tǒng)服務漏洞列表

ASFuzzer共發(fā)現(xiàn)25個Android系統(tǒng)服務安全漏洞，漏洞行為主要有手機重啟、應用拒絕服務、手機黑屏、系統(tǒng)應用進程停止運行等。目前已將相關漏洞提交給廠家確認。漏洞詳細信息如表4和表5所示。

表4 谷歌原生Android系統(tǒng)漏洞

表5 第三方定制系統(tǒng)漏洞

4.3 挖掘能力分析

從實驗結果分析來看，ASFuzzer框架挖掘到的漏洞數(shù)量在相同系統(tǒng)版本情況下，多于文獻[3]使用的常規(guī)模糊測試挖掘到的系統(tǒng)服務漏洞數(shù)目，并且在第三方廠家定制系統(tǒng)上測試也取得了一定的成果。遺傳算法變異生成高多樣化的測試用例，大大提高了觸發(fā)漏洞的可能性。通過分析產生異常的接口及其參數(shù)，在25個漏洞中有19個是因為多參數(shù)組合變異所引起的漏洞，即只有當特定數(shù)據(jù)被填充才會引發(fā)異常。實驗結果說明基于遺傳算法的模糊測試在系統(tǒng)服務的漏洞挖掘中遠優(yōu)于常規(guī)的模糊測試方法，具有一定的高效性與優(yōu)越性。

在遺傳算法挖掘策略上，文獻[13]在選擇算子階段采用隨機的方式對當前種群中的個體進行挑選。作為即將進入下一輪的個體，隨機挑選可能會錯失優(yōu)異個體，進而誤導測試的方向，影響挖掘效率。而本文充分利用單個參數(shù)的可變異范圍及參數(shù)的數(shù)量關系，并結合排列組合的方式對遺傳算法過程中的選擇運算進行指導，保證了優(yōu)秀個體的及時輸入，從而引導挖掘測試向高效的方向發(fā)展。

4.4 系統(tǒng)服務安全性分析

SystemServer系統(tǒng)進程運行著大量的基本服務，單個服務引起的異常極易引起系統(tǒng)進程的崩潰，從而影響到Android系統(tǒng)的穩(wěn)定。通過對服務端返回的reply信息以及系統(tǒng)日志等分析發(fā)現(xiàn)，系統(tǒng)服務出現(xiàn)的安全異常主要體現(xiàn)在以下4個方面：

1)存在少量不合法參數(shù)異常。原因是有些參數(shù)類型無法構造或者使用了null填充，無法通過底層目標函數(shù)的參數(shù)校驗。

2)出現(xiàn)較多安全異常。說明目標函數(shù)對調用者的身份權限做了判斷，對接口增加了防護。

3)日志信息無明顯異常。說明參數(shù)通過了目標函數(shù)的參數(shù)校驗或權限判斷。此類接口默認低權限可以調用，接口對外暴露，是漏洞挖掘的重點。

4)嚴重異常信息。如系統(tǒng)重啟、拒絕服務、系統(tǒng)應用崩潰等，表明該接口存在嚴重漏洞。

綜合以上結果及漏洞成因分析，可以得出系統(tǒng)服務安全防護的3要素：參數(shù)校驗、權限判斷、異常處理。做好以上3點可以在一定程度上加強Android系統(tǒng)服務的安全性。

5 結束語

本文在Binder與系統(tǒng)服務之間的通信基礎上設計了ASFuzzer系統(tǒng)服務漏洞挖掘工具。經(jīng)過遺傳算法對用例的持續(xù)優(yōu)化，使其生成更全面、更多樣化的用例去測試目標函數(shù)，進而觸發(fā)漏洞。在不同系統(tǒng)上測試結果顯示，ASFuzzer測試框架可以有效地對系統(tǒng)服務進行漏洞挖掘，進而發(fā)現(xiàn)其中潛在的一些安全問題；同時也表明了該方案相比常規(guī)模糊測試挖掘方法效率的優(yōu)越性。但該工具仍存在一些不足，如對異常信息的記錄及分析不能做到完全自動化，測試結果對遺傳算法的反饋處理不夠細膩等。這些不足之處都需要在未來對其進行改進和優(yōu)化，以便提高測試效率。