Android 系統提供了一種類加載器DexClassLoader,其能夠在運行時動態加載並解釋執行包含在JAR或APK文件內的DEX文件。外部動態加載DEX文件的安全風險源於:Anroid4.1以前的系統版本允許Android應用將動態加載的DEX文件存儲在被其餘應用任意讀寫的目錄中(如sdcard),所以不可以保護應用免遭惡意代碼的注入;所加載的DEX易被惡意應用所替換或者代碼注入,若是沒有對外部所加載的DEX文件作完整性校驗,應用將會被惡意代碼注入,從而執行的是惡意代碼;
若是應用沒有正確的動態加載DEX文件,將會致使攻擊者的任意代碼被自動執行,進一步實施欺詐、獲取帳號密碼或其餘惡意行爲等危害,如在烏雲漏洞平臺上的相似漏洞:QQ遊戲Android客戶端漏洞致使任意代碼執行和密碼泄漏[1]。html
Android 系統java
public DexClassLoader (String dexPath, String optimizedDirectory, String libraryPath, ClassLoader parent)[2]
動態加載的DEX文件存儲在被其餘應用任意讀寫的目錄中(如sdcard),若是沒有對外部所加載的DEX文件作完整性校驗,應用將會被惡意代碼注入,從而執行的是惡意代碼;android
利用DexClassLoader()運行時加載JAR/DEX文件,該將惡意代碼替換掉被加載的DEX文件,或向該被加載的DEX文件注入惡意代碼。安全
被替換的所加載的JAR/DEX class的惡意代碼以下:網絡
動態加載JAR/DEX的調用代碼:app
Android 4.1以前系統版本,結果顯示成功動態加載JAR/DEX以下圖所示:
google
Android 4.1以後系統版本,結果拋出異常「Optimized data directory /mnt/sdcard is not owned by the current user. Shared storage cannot protect your application from code injection attacks.」:加密
因爲Android 4.1以後Android版本增長了對JAR/DEX存放目錄文件的user_id 和動態加載JAR/DEX的進程的user_id是否一致的判斷,若是不一致將拋出異常致使加載失敗,以下圖所示:spa
4.1以前版本的Android系統DexFile.java代碼片斷[3]:3d
4.1及其以後版本的Android系統DexFile.java代碼片斷[4]:
爲了所加載的DEX/APK不被惡意代碼注入,阿里聚安全建議將要動態加載的DEX/APK放置在APK內部;
阿里聚安全建議使用加密網絡協議進行下載並將下載的DEX或APK放置在應用的私有目錄;
若是應用必須將所加載的DEX或APK放置在能被其餘應用人意讀寫的目錄中(如sdcard)或使用沒有加密的網絡協議進行下載加載源,阿里聚安全建議對這些不可信的加載源進行完整性校驗和白名單處理,以保證不被惡意代碼注入。
引用
[1] http://www.wooyun.org/bugs/wooyun-2010-09299
[2] http://developer.android.com/reference/dalvik/system/DexClassLoader.html
[3] https://android.googlesource.com/platform/libcore-snapshot/+/ics-mr1/dalvik/src/main/java/dalvik/system/DexFile.java
[4]https://android.googlesource.com/platform/libcore/+/45e02606b35996f61487f512ee91d0df83e75c9e/dalvik/src/main/java/dalvik/system/DexFile.java
[5] http://developer.android.com/training/articles/security-tips.html#DynamicCode