android
The second half of July roused Android users as two very serious and unpleasant vulnerabilities were discovered. Researchers announced these so-called “master keys,” i.e. universal access to any Android device, which allow potential attackers to penetrate mobile defenses, attain root access and run an arbitrary code with the owner of the device completely unaware.
The new vulnerabilities allow you to modify components of the application, bypassing the cryptographic signature so that Android OS would treat such programs as completely legitimate, even though they contain malicious modules.
The vulnerabilities are essentially similar. The analysis showed that the possibilities of exploiting the second flaw are limited to certain conditions for the targeted application.
Vulnerability #8219321
The first vulnerability was detected in February by Bluebox Security Company. Google was notified immediately, and then a long period of radio silence followed.
According to Bluebox the vulnerability is present in all versions of Android since 1.6 and thus could affect almost any device released in the past four years. It could affect nearly 900 million devices, but the threat may actually prove to be much smaller.
Prior to understanding the technical details, a kind of explanation is needed regarding applications for OS Android.
Applications are single files with a .APK extension (Android Package). They are normally ZIP-files with all resources packed in the form of specially named files (the application’s own code is usually stored in classes.dex file).
As a rule, any attempt at changing the contents of an APK-file is stopped while installing the application on an Android OS. Alas, this is just a theory: the ZIP format itself does not exclude duplicate file names, and in case of “duplicated” resources, Android appears to successfully check one file, but run the other.
Technology consultant Jay Freeman (Saurik) did a thorough technical analysis of the vulnerability and described the possible ways to get rid of it, his article is available here. According to him, the core issue is that the Android package (APK) files are parsed and verified by a different implementation of “unzip a file” than the code that eventually loads content from the package: the files are verified in Java, using Harmony’s ZipFile implementation from libcore, while the data is loaded from a C re-implementation. The difference between them allows you to bypass verification: when there are two files with the same names in the stack, the last listed is checked and the other is launched by the Android DalvikVM virtual machine.
Vulnerability #9695860
Information about the second vulnerability was published by Chinese experts. The problem here is the simultaneous use of two methods of reading and unpacking APK-files and the different interpretations of Java and C.
Like the first vulnerability it allows you to rig APK files with executable components with identical names but different content. More specifically, it refers to “duplicating” classes.dex files, which contain the code of the application, by means of exploiting one of the metadata fields in the header of an APK-file.
There is a detailed technical description of the vulnerability in Jay Freeman’s article. It should be noted that a prerequisite of a successful attack is the length of the original classes.dex file – it has to be no longer than 64 kilobytes, and this condition is not met by most Android applications.
In the next post we will describe cybercrooks’ attempts to abuse these vulnerabilities and the countermeasures taken thus far.
To be continued…
