Second "Master Key" Style APK Exploit Is Revealed Just Two Days After Original Goes Public, Already Patched By Google

Hot on the heels of Bluebox's disclosure of the "Master Key" exploit, a Chinese blog has posted details of a similar vulnerability. This attack also sidesteps a bug in the signature verification step and allows seemingly innocent APKs to include a potentially dangerous payload; and like its brethren, Google has already patched the flaw and posted it to the Android Open Source Project (AOSP). The information comes to us from a China-based group (or possibly individual) calling itself the Android Security Squad. The original post is in Chinese, but a vaguely comprehensibletranslation can be had thanks to Google.

Initial discovery of the flaw, known as "bug 9695860," occurred as the security researcher was examining a changeset that was subtly posted to AOSP on July 3rd. The only comment for the update reads, "Values in ZIP files are unsigned," but based on code changes, the researcher was able to unearth the previously unpublicized vulnerability. Of course, since this discovery resulted from an existing fix, we know that Google already patched up the bug. We don't know if Google itself found the weakness, or if a 3rd party disclosed it without claiming credit (yet).

The nature of the exploit is fairly complicated and relies on some tricky modifications to the APK. Basically, two versions of the classes.dex file are placed inside of the package, the original and a hacked alternative. By overlapping the valid version (which begins with the characters 'dex') with part of the filename (which ends with 'dex'), it becomes invisible to the extraction process. The container is then modified to trick Android into examining the original. This bait-and-switch tactic depends on an oversight in the signature check process where the system reads a pair of values (the length of the filename and extra field) to determine how far to skip to get to the actual file data. By providing a negative number here, the valid version is checked. Google's fix for the problem was to simply force the values to be interpreted as positive numbers, making it impossible to use this particular method for misdirection.

Google's fix: red shows the original code, green is the new version.

Like the previous exploit demonstrated by Bluebox, this one relies on the Android system to perform signature verification and extraction in slightly different ways. Fortunately, there are a few limitations to this attack. To begin with, unlike the "Master Key" exploit, this one can only replace a single file, classes.dex, and only if the original is smaller than 64k. Further, the process to construct the modified APK is more precise and relies on a fairly complete knowledge about the structure of the files.

There is some unfortunate news: since the fix appears to be pretty new, it's unlikely to have propagated to any device in the wild yet, including Nexus devices and the Google Play Edition variants of the Samsung Galaxy S4 and HTC One. Given the speed with which CyanogenMod is pushing out security fixes, we can probably expect its users will be among the first to be protected. However, since Google has clearly been aware of the issue, it's likely that the Play Store is already checking apps to ensure APKs are not being distributed with this attack. In other words, keep installing apps through the Play Store and be extremely wary of any untrusted sources. While this exploit is potentially just as dangerous as the one from Bluebox, it's still more limited and future security updates will surely patch both issues at the same time, so there's not really much more to worry about from this discovery.

Source Sina [translated link], AOSP patch

Thanks, Anon