Second Android signature attack disclosed

 

Chinese security bloggers have disclosed an alternative to Bluebox's Android signature attack. Although the attack is different in its execution, it does the same basic trick of fooling Android's APK-reading routines into thinking an APK has been properly signed by using a copy of correctly signed data in one location but tricking the system into running an unsigned modified version of that data stored in another location. The Bluebox approach exploited a flaw that allowed two copies of the same file to be present in a ZIP archive.
The new Chinese attack works instead by modifying the classes.dex file which contains an application's compiled code within the APK file. That file's header includes a variable-sized space between the header, which includes the file name with a .dex extension and the class files for an "extra field". It is into the last three characters of the file name and the extra field that the original class files are copied, with the length of the extra field set to 0xFFFD.


After this, padding is added and then the attackers' own class files can be included. When validating, a bug in the reading code means that 0xFFFD is converted to -3 and the validation takes places starting at the "dex" part of the file name extension which also happens to be the opening header of the dex file format. When being loaded though, the reading code follows 0xFFFD correctly and reads the modified code.
The flaw exploits a confusion between short and int types and has been given the bug id 9695860. The nature of the problem does mean, though, that it only works for classes.dex files that are less than 64K in size. The problem has been corrected with a patch which simply forces all values to be unsigned.
The patch, along with the fix for the Bluebox flaw, has already been deployed in the latest versions of CyanogenMod 10.1.2 and the team are looking at addressing the same problems in CM7 and CM9. For Google, though, the problem is the same as with the Bluebox issue; how to get phone manufacturers to ship out firmware updates that will correct both issues, not only in new editions of Android but in older versions, as these problems date back to early Android versions, as far back as Android 1.6.