GET_ACCOUNTS should be allowed for Google-signed apps on Marshmallow

[nyanpasu64]

Nexus 5X, PureNexus 6.0.1 June, Xposed FakeGApps.

Description

After installing MicroG, I discovered that the Project Fi app crashes on startup.

I ran a logcat, revealing that MicroG AccountContentProvider.java raised an exception:
Access denied, missing GET_ACCOUNTS or EXTENDED_ACCESS permission

I granted the GET_ACCOUNTS permission using pm grant com.google.android.apps.tycho android.permission.GET_ACCOUNTS, and the app appears to work properly.

Issue

In reality, MicroG should be allowing Project Fi to load, even without that permission.

Quote Android docs (https://developer.android.com/reference/android/Manifest.permission.html#GET_ACCOUNTS):

Note: Beginning with Android 6.0 (API level 23), if an app shares the signature of the authenticator that manages an account, it does not need "GET_ACCOUNTS" permission to read information about that account. On Android 5.1 and lower, all apps need "GET_ACCOUNTS" permission to read information about any account.

As MicroG is imitating a Google-signed app, it should allow Google-signed apps to read accounts without that permission.

[Lanchon]

this shows that signature spoofing as implemented in Omni is not enough.

app signatures were a feature introduced to make decentralized apps with safe upgrades possible in the early days of really free Android. now signatures have been re-purposed into an anti-feature (attestation) to strip users of essential freedoms of the information age (eg, the freedom to tinker) and empower platform and app developers at the expense of device owners.

i believe it is very important to develop full-featured signature spoofing to advance Android towards the much needed direction of freedom. not having capable and versatile signature spoofing hinders liberating efforts such as GmsCore and tinkering efforts like DexPatcher.

i am not much versed in android security but even i can see the need for different levels of signature spoofing. for instance, these are fairly obvious:

1. report a faked signature to apps querying the signature of a package. this is basic signature spoofing as implemented in Omni.
2. in addition, make Android's runtime security model believe the spoofed signature. this means that the spoofing app can access (and be accessed from) the ecosystem of components that share that signature. it would be able to share data, permissions, etc with the same privileges the genuine app would have. and regarding this bug report, if GET_ACCOUNTS were implemented in a package that spoofs at this level, then the bug would disappear.
3. in addition, make package manager believe the spoofed signature. this would allow a patched app to replace or upgrade the genuine version in-place without resetting app data. this is sometimes necessary to remove anti-features from software, either by reverse engineering or when rebuilding a FLOSS app from source, and also when switching providers of a FLOSS app (eg, switching from the play store version of an app to the f-droid version). this can currently be done with XInstaller, but Xposed and XInstaller both introduce security issues. a good solution for this level of spoofing would probably always require user interaction at package install time. i imagine a confirmation popup whenever an app version is being replaced by another with a different real signature. (this popup might be disabled by default and might require a toggle in developer settings to help guard unsophisticated users from attacks.)

[nyanpasu64]

(I'm using Xposed FakeGApps, is that the same as Omni?)

[Lanchon]

no, FakeGApps is even more restricted and only works for this project. but you could use Needle which i think is the same as Omni.

[nyanpasu64]

Is the implicit GET_ACCOUNTS handled by the Android runtime or MicroG? If the former, this could be a FakeGApps bug.

Can anyone reproduce/confirm this?

[Lanchon]

this could be fixed within FakeGApps. but what about the 'standard' signature spoofing that this project added to Omni? i read that the patch only deals with signature reporting to apps and does not impact the security model otherwise.

this means that this bug should also be present in Omni (but somebody should test). which brings us to the point i've talked about: we need a full implementation of signature spoofing for android.

[nyanpasu64]

Do the Google apps normally get GET_ACCOUNTS privilege by installing in /sys/priv-app, in pre-6.0 Android?

See here: http://forum.xda-developers.com/showpost.php?p=67552644&postcount=1333

[mar-v-in]

Google apps pre-installed on the system are automatically granted certain permissions, including GET_ACCOUNTS. If the app requests GET_ACCOUNTS permission (and this is a requirement for pm grant to actually work), you can also grant GET_ACCOUNTS within the UI, it's part of the "contacts" permission set.

However, not all apps by Google request the GET_ACCOUNTS permission even if the signature is not the same as the original Google package. This is because Google just allows them to access the data based on the signature and the whole purpose of the AccountContentProvider is to bypass the security model enforced by the AccountManager (which will require the GET_ACCOUNTS permission).

We already keep a list of certain Google app signatures that will be granted "extended access", a system developed to mimic the Google behavior to grant their own apps more permissions than third party apps (note that with microG, normal apps can request extended access using the permission org.microg.gms.EXTENDED_ACCESS).

It is certainly possible that Project Fi key is not part of this list yet. You can verify this by watching logcat, it should post a line Not granting extended access to [com.google.android.apps.tycho], signature: ????. I will check this later and add Project Fi to the list of google signatures.

[mar-v-in]

@Lanchon I don't think that it is a good idea to spoof the android security system. Especially there is no real reason to do so: You would only need to spoof the system, in a situation with two apps of the same author, one being modified (and with app signature spoofing) and one being the original. In this case you could also just modify the signature of the original and use app signature spoofing and you would have the same result. The only difference is, that you can't update the app through the original source anymore, which I don't consider a bad thing, because this way, the user will notice, that he uses a non-original app.

I consider signatures a good feature to ensure that two apps are published by the same entity. This is important to ensure privacy and to protect the lazy user. Experienced users should always be able to "be their own publisher" and thus bypass security systems based on signatures. This is made possible with app signature spoofing.
The security impact of app signature spoofing is negligible whereas the impact of system signature spoofing is not.

I also see it would be an awesome feature to allow cross-signature updates with user's consent. This could be added to third-party ROMs in a way that will still be secure. The way you described this feature (protected in developer or security settings) I think chances are not bad that OmniROM would accept it as a pull request.

[zoff99]

if you want to update an app with different signatures just use "XInstaller" xposed module. this has an option to do that. !! use at your own risk !!

but please do not do bad things with microG
also if gmscore is granting special access to some google apps, bypassing the normal permission, then please make a screen for that in miroG setting, which shows which apps are granted these permissions.
and also allow for a switch (on/off) to disable to per app basis

[Lanchon]

@mar-v-in thank you for your detailed response!

IMHO, asking users to spoof all signatures of all apps that share a signature to patch a single app is undue burden on the user. not to mention, you can't install patched versions of apps from different sources without resigning them all yourself.

and keep in mind that a change of signature currently requires wiping app data (unless you use xposed, which we don't want for security reasons (but i am forced to use anyway)), so that solution is not really workable.

also, one usage scenario you didn't envision is having one untouched single closed-source app with a 3rd party signature installed, and then installing a FLOSS spoofing the signature to overcome some restriction of the closed-source app.

for example, an app could store user data, but then not let you export your data, holding you hostage. a simple FLOSS app could overcome that by accessing the immoral app's database directly and freeing your data; but that requires level 2 signature spoofing.

---

and a couple of questions:

Q1) if an app is granted "extended access" by virtue of its signature, will it be granted said access immediately and transparently? or will it go though a user UI request such as when an app requests the org.microg.gms.EXTENDED_ACCESS permission?

Q2) and regardless of how the extended access permission is granted, when such powers are actually executed, say by requesting the list of accounts, will a UI "account data access" confirmation pop-up appear? or will the access be granted transparently?

Q3) could Q2) be implemented by making the system behave as if a list of permissions were added to the permission lists of the apps that are granted EXTENDED_ACCESS instead of directly granting those accesses, triggering the usual UI confirmations?

thanks!

[mar-v-in]

I understand your arguments and have nothing to add. Apps that use signatures to protect access outside the Google app space are very few, I don't thank that adding the described feature to the operating system is worth the effort or possible security impact. A proper user interface that allows to easily sign the application with a different key combined with the ability to install updates with different signatures will provide the same results with a less deep intrusion in the operating systems security design.

Regarding your questions:
The current application will automatically "grant" extended access to apps signed by Google (or spoofing Google signature). the permission is not granted on a technical level, the permission check is just skipped in case a known Google signature is present. This is far from perfect, but user interaction is not always possible (e.g. would cause the Google app to spawn a "force close" dialog) and it's the same behavior implemented in original Google Play Services. I want to improve this before features that work with sensitive data are added (accessing contacts, etc).
Third party apps that request the EXTENDED_ACCESS permission must go through the usual granting procedure (which means install time granting on Android < 6 apps and platform and runtime permission granting for Android 6 apps on Android 6).
Regarding accessing the account list, the current implementation requires the app to either hold GET_ACCOUNTS or EXTENDED_ACCESS permission or be signed by Google. No additional UI will pop up (this is also one of those situations, where it's not easily possible to show UI, as the call to the content provider is blocking).
Not all extended access features have a corresponding permission. e.g. directly accessing the Android Wear database is not possible to any third party application. Nonetheless, it's a good idea to seperate different data in the permission granting process.

As this is a bit off topic here, further questions regarding "extended access" or ideas to improve its security design, should go in the new issue #149. Thanks.

[Lanchon]

thank you, extremely helpful and complete answer. and yes, there is a lot of trouble where blocking API need to be authorized, maybe spoofing empty responses while on the UI being the only choice. thanks again!

[mar-v-in]

@jimbo1qaz Please check if the problem persists with 0.2.3-5

[nyanpasu64]

I'm no longer using MicroG because it causes too many issues. Can someone confirm? Should I close?

[nyanpasu64]

all my project fi 5x's died of various causes. The app does not crash on a Moto G4 Plus.