There is a new security vulnerability in town, this time labeled "Fake ID" (Google bug 13678484).
The bug allows malicious apps to pretend to be signed by trusted providers and be loaded as extensions in several contexts such as NFC access, browser plugins and others.
An excellent explanation can be found on this article by Jeff Forristal from Bluebox.
Checking if you're vulnerable
It appears to currently affect all devices, to a lesser or greater extent depending on which extensions each manufacturer included in their ROMs.
You can use Bluebox Security Scanner to detect if your system is vulnerable.
Installing the fix
Fetch the package from the Xposed repository: http://repo.xposed.info/module/tungstwenty.xposed.fakeidfix (it is also available on Google play)
Install as usual and make sure that you enable the module on the Xposed Installer and reboot.
There are no configuration options. There is a simple information screen which can be accessed by tapping the entry on the Installer's module list (you won't see an icon for this on your launcher).
Fix details
For the tech savvy, here's an explanation of what this patch does.
The JarTools class has an API for grabbing all signature certificatates present on an APK / jar. That API doesn't however check if *all* certificates form a valid chain, where each certificate is properly signed by the next one and so on, and not additional certificates are present that don't belong to that chain. It is therefore possible to insert additional certificates in that list, and *certain* callers of that API might be fooled if they assume that just because a certificate is on that list, the party to which it belongs did in fact sign or trust that code.
This behavior could not be blindly changed to enforce checking the chain validity, as apparently it would create compatibility issues on some legitimate callers of that API that rely on that behavior, and Google opted (see this AOSP commit) to include an option to both of the behaviors, keeping the old "insecure" one for code that doesn't bother specifying what it wants, i.e. all existing code.
I haven't spotted any other commits that rely on this new behavior, but from my analysis it seems that the identified vulnerability vectors all go through the getPackageInfo(..., GET_SIGNATURES) PM API.
Therefore, so as not to cause the compatibility issues that Google seems to be cautious about, I have chosen to modify the behavior of JarTools.createChain() only when it's being used by the PM service. This will stop the possibility of using malicious apps impersonating NFC extensions (e.g. Google Wallet), Adobe web plugins, etc.
Additionally, and since Bluebox Security Scanner does a more direct check (in order not to require installing a malicious / proof-of-concept APK in order to then ask the PM service about its signatures), I also included code specific to this scanner so that it reports the bug as not present.
Source code
Available on Github
If you appreciated this fix, consider donating with Paypal.
Thanks!
The bug allows malicious apps to pretend to be signed by trusted providers and be loaded as extensions in several contexts such as NFC access, browser plugins and others.
An excellent explanation can be found on this article by Jeff Forristal from Bluebox.
Checking if you're vulnerable
It appears to currently affect all devices, to a lesser or greater extent depending on which extensions each manufacturer included in their ROMs.
You can use Bluebox Security Scanner to detect if your system is vulnerable.
Installing the fix
Fetch the package from the Xposed repository: http://repo.xposed.info/module/tungstwenty.xposed.fakeidfix (it is also available on Google play)
Install as usual and make sure that you enable the module on the Xposed Installer and reboot.
There are no configuration options. There is a simple information screen which can be accessed by tapping the entry on the Installer's module list (you won't see an icon for this on your launcher).
Fix details
For the tech savvy, here's an explanation of what this patch does.
The JarTools class has an API for grabbing all signature certificatates present on an APK / jar. That API doesn't however check if *all* certificates form a valid chain, where each certificate is properly signed by the next one and so on, and not additional certificates are present that don't belong to that chain. It is therefore possible to insert additional certificates in that list, and *certain* callers of that API might be fooled if they assume that just because a certificate is on that list, the party to which it belongs did in fact sign or trust that code.
This behavior could not be blindly changed to enforce checking the chain validity, as apparently it would create compatibility issues on some legitimate callers of that API that rely on that behavior, and Google opted (see this AOSP commit) to include an option to both of the behaviors, keeping the old "insecure" one for code that doesn't bother specifying what it wants, i.e. all existing code.
I haven't spotted any other commits that rely on this new behavior, but from my analysis it seems that the identified vulnerability vectors all go through the getPackageInfo(..., GET_SIGNATURES) PM API.
Therefore, so as not to cause the compatibility issues that Google seems to be cautious about, I have chosen to modify the behavior of JarTools.createChain() only when it's being used by the PM service. This will stop the possibility of using malicious apps impersonating NFC extensions (e.g. Google Wallet), Adobe web plugins, etc.
Additionally, and since Bluebox Security Scanner does a more direct check (in order not to require installing a malicious / proof-of-concept APK in order to then ask the PM service about its signatures), I also included code specific to this scanner so that it reports the bug as not present.
Source code
Available on Github
If you appreciated this fix, consider donating with Paypal.
Thanks!
Last edited:
