Android Update Lets Malware Bypass Digital Signature Check 85
msm1267 writes "A vulnerability exists in the Android code base that would allow a hacker to modify a legitimate, digitally signed Android application package file (APK) and not break the app's cryptographic signature — an action that would normally set off a red flag that something is amiss. Researchers at startup Bluebox Security will disclose details on the vulnerability at the upcoming Black Hat Briefings in Las Vegas on Aug. 1. In the meantime, some handset vendors have patched the issue; Google will soon release a patch to the Android Open Source Project (AOSP), Bluebox chief technology officer Jeff Forristal said. The vulnerability, Bluebox said, affects multiple generations of Android devices since 1.6, the Donut version, which is about four years old. Nearly 900 million devices are potentially affected."
Looking forward to 1st August (Score:5, Insightful)
It will be really interesting to see what this vulnerability is, on the 1st of August, since all that can be gathered from the press release is essentially:
It is possible to change an APK without changing its signature, and Android will not notice. That does have big implications, but it isn't enough detail to say anything much more than "Oh, that's not good".
Re:900 million is a pretty big number (Score:5, Insightful)
And thus we dispel one of the many myths of open source. F/OSS is not bad and proprietary software is not necessarily better in any way or any of that shit but the cold hard fact is that even if you have access to the source code this sort of thing is going to happen! Nobody is reading and understanding all the code in its entirety being assured that there are no vulnerabilities or backdoors, no matter how much the fossies like to believe it.
I'm not advocating one way or the other, just sayin that whole argument about security because we have access to the sourcecode is rubbish.
Comment removed (Score:5, Insightful)
Re:Android fragmenting (Score:3, Insightful)
Patches? Hahahahahahaha
I'm pretty sure my carrier forgot my phone model existed the moment they sold it to me. It's a buggy piece of shit that hasn't ever gotten any patches.
Ah, Java... (Score:2, Insightful)
...write once, zero-day everywhere!
Re:Looking forward to 1st August (Score:5, Insightful)
I will wager a guess as to what the vulnerability is. If that is not it, then it just means there is another vulnerability.
I'll just state that I'm not sure this is it, as what I'm talking about is not trigerrable via an update. You would need root to trigger it.
The information I am writing here is a product of my own research. It may or may not be the same as discussed above, but the symptoms are similar enough that I think it is.
An APK is a zip file composed of two main parts. The compiled dalvik code (in a file called classes.dex), as well as the resources (spanning multiple files, exact format irrelevant here). All of those files are listed in a directory inside the APK with their hash, and that file is digitally signed. This is the Androidn signing process.
The code, however, is in a format that is not immediately usable. I'm a bit fuzzy on the specific details, but the general idea is that you would need to adapt it to load addresses, based on everything else running in the same address space (the framework, and other libraries, if applicable). As a result, when Android first sees an APK, it does "optimization", in which it essentially takes the dex file, does all of the necessary relocations, and stores it in a directory called "dalvik-cache". As long as none of the APKs on which this cache file depends changed (the cache file stores the hashes for the original APK and all other dependencies), then Android does not bother with the classes.dex file stored inside the APK. It simply loads the optimized dex (odex) directly from the cache whenever needed. Needless to say, the odex is not hashed and is not signed. If you change it, Android will load your modified code without complaining.
I had more to say, and typed it in and all, but then I got "Filter error: Lameness filter encountered" error. Probably too long. I think you will have to make do with the first half of my comment :-)
Shachar
Re:Looking forward to 1st August (Score:5, Insightful)
Second half of above comment:
It gets worse, however. Some vendors do not like the fact that after factory reset, the phone takes a long time to boot as it turns all of the dex files into odex files. They also do not like the fact that these files take space in the data partition, which is where downloaded APKs and application data is stored by default. As a result, Android has a mechanism by which you can place an APK in the system partition that is already odexed. The APK file does not contain a classes.dex file at all. Instead, next to the APK there is another file, called with the same base name and an .odex extension. On such a system, the original, signed, code is not around, and all of the actual code of the application is unsigned.
The severity of this attack, scary though it may sound, is not very high. You need root access in order to change the system folder or access the dalvik-cache directory. There is no privilege escalation. Just running unsigned code that seems to be signed. Also, any change to other parts of the system will invalidate the cache, and cause your exploit to disappear.
All in all, an interesting, but not very scary, vulnerability.
Shachar