1. 外部動態(tài)加載DEX文件風險描述

Android 系統(tǒng)提供了一種類加載器DexClassLoader，其可以在運行時動態(tài)加載并解釋執(zhí)行包含在JAR或APK文件內(nèi)的DEX文件。外部動態(tài)加載DEX文件的安全風險源于：Anroid4.1之前的系統(tǒng)版本容許Android應(yīng)用將動態(tài)加載的DEX文件存儲在被其他應(yīng)用任意讀寫的目錄中(如sdcard)，因此不能夠保護應(yīng)用免遭惡意代碼的注入;所加載的DEX易被惡意應(yīng)用所替換或者代碼注入，如果沒有對外部所加載的DEX文件做完整性校驗，應(yīng)用將會被惡意代碼注入，從而執(zhí)行的是惡意代碼;

如果應(yīng)用沒有正確的動態(tài)加載DEX文件，將會導致攻擊者的任意代碼被自動執(zhí)行，進一步實施欺詐、獲取賬號密碼或其他惡意行為等危害，如在烏云漏洞平臺上的類似漏洞：QQ游戲Android客戶端漏洞導致任意代碼執(zhí)行和密碼泄漏[1]。

2. 外部動態(tài)加載DEX文件影響范圍

Android 系統(tǒng)

3.外部動態(tài)加載DEX文件風險詳情1) 風險位置:

public DexClassLoader (String dexPath, String optimizedDirectory, String libraryPath, ClassLoader parent)[2]

2) 風險觸發(fā)前提條件： 動態(tài)加載的DEX文件存儲在被其他應(yīng)用讀寫的目錄中，如sdcard; 沒有對外部所加載的DEX文件做完整性校驗;3) 風險原理：

動態(tài)加載的DEX文件存儲在被其他應(yīng)用任意讀寫的目錄中(如sdcard)，如果沒有對外部所加載的DEX文件做完整性校驗，應(yīng)用將會被惡意代碼注入，從而執(zhí)行的是惡意代碼;

4. 外部動態(tài)加載DEX文件風險證明

利用DexClassLoader運行時加載JAR/DEX文件，該將惡意代碼替換掉被加載的DEX文件，或向該被加載的DEX文件注入惡意代碼。

被替換的所加載的JAR/DEX class的惡意代碼如下：

動態(tài)加載JAR/DEX的調(diào)用代碼：

Android 4.1之前系統(tǒng)版本，結(jié)果顯示成功動態(tài)加載JAR/DEX如下圖所示:

Android 4.1之后系統(tǒng)版本，結(jié)果拋出異?！癘ptimized data directory /mnt/sdcard is not owned by the current user. Shared storage cannot protectyour application from code injection attacks.”:

由于Android 4.1之后Android版本增加了對JAR/DEX存放目錄文件的user_id 和動態(tài)加載JAR/DEX的進程的user_id是否一致的判斷，如果不一致將拋出異常導致加載失敗，如下圖所示：

4.1之前版本的Android系統(tǒng)DexFile.java代碼片段[3]：

4.1及其之后版本的Android系統(tǒng)DexFile.java代碼片段[4]：

5. 外部動態(tài)加載DEX文件安全建議1. 將所需要動態(tài)加載的DEX/APK文件放置在APK內(nèi)部或應(yīng)用私有目錄中[5]

為了所加載的DEX/APK不被惡意代碼注入，阿里聚安全建議將要動態(tài)加載的DEX/APK放置在APK內(nèi)部;

2. 使用加密網(wǎng)絡(luò)協(xié)議進行下載加載的DEX/APK文件并將其放置在應(yīng)用私有目錄中[5]

阿里聚安全建議使用加密網(wǎng)絡(luò)協(xié)議進行下載并將下載的DEX或APK放置在應(yīng)用的私有目錄;

3. 對不可信的加載來源進行完整性校驗

如果應(yīng)用必須將所加載的DEX或APK放置在能被其他應(yīng)用人意讀寫的目錄中(如sdcard)或使用沒有加密的網(wǎng)絡(luò)協(xié)議進行下載加載源，阿里聚安全建議對這些不可信的加載源進行完整性校驗和白名單處理，以保證不被惡意代碼注入。