Hacker News Reader

Comment by gruez | Hacker News Reader

>Google already controls the operating system, the installer, and the SDKs you used to develop your Android app in the first place. If they wanted to backdoor your app there are already plenty of opportunities to do so at multiple levels throughout this chain.

It's less straightforward to backdoor the OS/sdk because it's open source and built by various vendors. AFAIK the play store doesn't have a custom installer to handle installs, that's handled by the operating system itself. The play store has special permissions to install apps programmatically, but AFAIK it doesn't have ability to bypass the signature check, which is why this change is being made in the first place.

View on HN

> It's less straightforward to backdoor the OS/sdk because it's open source and built by various vendors.

Not for devices running Google Play Services. If your device is running AOSP with absolutely zero Google services then maybe that's the case (although I'm not even sure that's true at the firmware/driver level), but if you'll never use the Play Store then Play Store restrictions don't really affect you in the first place.

I also think you're seriously underestimating or misunderstanding the potential attack vectors here. You don't need to deliver a blatantly obvious backdoor that can be easily found in the AOSP source code. Consider the history of 0-day RCE exploits on the Android platform and then consider the fact that such exploits can be subtly introduced in a non-obvious way that gives you plausible deniability if discovered. Now consider that you have your own closed-source and privileged code running on billions of Android devices that could take advantage of the 0-days you introduced yourself.

The Play Store is a closed binary which had privileged permissions to silently install, uninstall or update APKs. The Play Services have silent permissions to backup and restore app data. Both of those update themselves silently.

Open source doesn't protect you at all against Google.

The Play Store cannot update an app to a version that is not signed by the original developer. At best it can uninstall and reinstall the app with a different signing key, in which case all app data gets wiped.

edit: Actually I don't even know that the App Store has permission to uninstall apps. If it doesn't, then it can only update apps that are signed with developer keys.

As for backups, apps have control over which data can be backed up. Google cannot access app data if the app doesn't consent to it, assuming the Android OS itself is not somehow compromised.

>edit: Actually I don't even know that the App Store has permission to uninstall apps.

https://developer.android.com/reference/android/Manifest.per...

Skimming the permissions file shipped with opengapps suggests that play store has it.

    <privapp-permissions package="com.android.vending">
        [...]
        <permission name="android.permission.DELETE_PACKAGES" />

Thanks, I suppose that is an avenue of attack then.

… not least because you can indeed uninstall apps directly from the Play Store UI.

That also wipes the data.

>The Play Store is a closed binary which had privileged permissions to [...] update APKs.

AFAIK the OS has checks to prevent "updating" to an APK with different signature.

>The Play Services have silent permissions to backup and restore app data.

It looks like apps can opt out of it. https://developer.android.com/guide/topics/data/autobackup#E... It's unclear whether this is enforced by the OS or google play services.

Portions of the SDK are open source, portions are not. Android also does not have reproducible builds, so you cannot audit that the open source you are viewing relates to the binaries on your phone. Android also widely depends on binary blob firmwares which also cannot be audited.

As it stands if you buy a normal android phone, then you must trust Google.

>Portions of the SDK are open source, portions are not. Android also does not have reproducible builds, so you cannot audit that the open source you are viewing relates to the binaries on your phone. Android also widely depends on binary blob firmwares which also cannot be audited.

1. you still need way more parties involved (eg. OEMs, chipset makers), unlike google which probably has acesss 95+% of the non-chinese android phones.

2. backdoors involving the SDK/OS are far less discriminate and therefore has higher risk of detection by third party researchers. (eg. https://www.xda-developers.com/mediatek-su-rootkit-exploit/)

You're completely ignoring existence of silently updated Play Store and Play Services which are controlled by Google and have enough permissions to do exactly what you think they can't.

Google has been decoupling things like Play Services from the BSP for a long time now. They could certainly push a backdoored version to a specific set of phones if they so wished.

If you wanted to add the exploit to the kernel, there are plenty of hooks to do so that would not require the kernel to be recompiled (e.g. a loadable module, or BPF). Again, these could be targeted at specific individuals, or groups of individuals.

Still, Google is extremely unlikely to add any backdoor willingly, and unlikely to add one in general. And more to the point, controlling the signing keys for a specific App does not make it easier to backdoor someones phone.

Reply on news.ycombinator.com