ANDROID-8219321漏洞－－Android 绕过应用签名认证漏洞

rover12421

        这个漏洞被曝光的时候很火，可以不改签名，修改apk包，涉及目前90%的android系统，不过漏洞很快就修复了，细节也出来了。也很容易被检测，曝光之后利用价值就不大了。
3月和5月google官方发出的补丁说明：

3月：

Improper installation of unsigned code
ID: ANDROID-8219321
Severity: High
Affected versions: Android 2.0 and greater

An inconsistency in the handling of zip files during application installation may lead to the installation and execution of unsigned code in a privileged context.

This issue will be publicly disclosed in 90 days. A CTS test will be included in the next CTS release.


5月：

Insertion of arbitrary code without changing package signature due to incorrect parsing of APKs (update to previous bulletin)
First published: March 4th, 2013
Last Updated: May 31st, 2013
ID: ANDROID-8219321
Severity: High
Affected Android Versions: all

Arbitrary code can be inserted into an APK and pass signature verification due to incorrect parsing of APKs. A maliciously crafted classes.dex can be inserted before a legitimately signed classes.dex in an APK. Signature verification will be performed on the second, legitimate classes.dex, but the first, malicious classes.dex is installed for application use.

Update: This issue will be publicly presented at Blackhat 2013. Please see http://www.blackhat.com/us-13/briefings.html#Forristal for more details. At that time, we expect active public exploitation of this issue outside of Google Play.

一、漏洞描述

      安全公司 Bluebox Security 日前声称，他们在 Android 系统中发现了可能会对 99% 设备造成影响的漏洞。按照其说法，这个漏洞自 Android 1.6（Donut）以来就一直存在，恶意软件制作者可以在不破解加密签名的前提下利用它来修改合规 APK 的代码，可以绕过android应用的签名验证安全机制。

二、影响设备
      
      理论上会影响android1.6至漏洞提报google时间点2013-02之间的所有设备。

三、漏洞原理
      1、恶意APK如何在不修改应用签名情况下绕过android签名验证机制。

原理简述

由于ZIP格式允许存在两个或以上完全相同的路径，而安卓系统没有考虑这种场景。在该情况下，android包管理器校验签名取的是最后一个文件的hash，而运行APK加载的dex文件却是zip的第一个dex文件。

包管理器验证签名验的是最后一个（名字相同情况下）文件。

1. 解析zip的所有Entry，结果存到HashMap（key为路径，value为Entry）。
2. 由于HashMap.put在相同key的情况下，会把value更新，导致上述的HashMap在相同路径下，存储的一定是最后一个文件的Entry。
系统加载dex文件，加载的是第一个dex。
1. 查找dex的Entry用的是dexZipFindEntry
2. dexZipFindEntry的实现是只要match就返回，所以返回的都是第一个文件。
CyanogenMod的修复原理

原代码：
for (int i = 0; i < numEntries; ++i) {
    ZipEntry newEntry = new ZipEntry(hdrBuf, bin);
    mEntries.put(newEntry.getName(), newEntry);
}



修补后：
for (int i = 0; i < numEntries; ++i) {
    ZipEntry newEntry = new ZipEntry(hdrBuf, bin);
    String entryName = newEntry.getName();
    if (mEntries.put(entryName, newEntry) != null) {
        throw new ZipException("Duplicate entry name: " + entryName);
}
}

关键代码为if (mEntries.put(entryName, newEntry) != null) {
该put为HashMap的put，key不存在返回null，反之返回原值。也就是说APK的Entry链存在2个或以上相同的路径即抛出异常