Hacker News Reader

Comment by nodamage | Hacker News Reader

At this point I am convinced this entire line of thought is just FUD.

> This means that Google can (or can be forced to) distribute backdoored versions of popular apps to targeted people. The app you are downloading may be different from the app your neighbour is downloading. And the app signature will be perfectly valid for both of them.

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. Retaining your own signing keys does not eliminate this potential threat, so you still have to trust them. If you don't, then you should avoid using Android entirely.

View on HN

>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.

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.

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.

> 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.

What happens if google gets a "national security letter" that says "hey, we wanna read $NAME's whatsapp messages". In the scenario without this system, google needs to use their control over the OS, the installer and the SDK to somehow deliver a changed version of the app, or run an exploit / backdoor against that app from other code they control. Excluding the exploit and pre-existing backdoor, that is something they could refuse to do somewhat easily.

Compare that to if google has the signing keys for updates to whatsapp. Then the national security letter could just state "hey, here is an update to whatsapp, please sign it with the appropriate keys". That is so much harder for Google to refuse.

I have a lot more faith that google would not comply with the first national security letter than with the second.

I don't really see a meaningful difference between those two scenarios. In both cases Google has the ability to exploit your app and you have to trust them not to do it. Whether one approach is more politically acceptable than the other is an interesting question but I don't know if it matters that much in the end.

> Whether one approach is more politically acceptable than the other is an interesting question but I don't know if it matters that much in the end.

It seems to me that if one approach is so politically unacceptable as to be quite unlikely, and the other approach is so politically acceptable as to be feasible, that is highly relevant.

In the first scenario, this is just a hypothetical attack google could do if they were evil. In the second scenario this is a realistic attack we need to consider could happen. The difference between "hypothetical" and "realistic" matters quite a bit.

Or, Google will tell the NSA to get stuffed because NSLs don't compel them to ship code updates to devices.

Compare the NSA asking Google "please sign this update to signal". To the FBI asking Apple "please sign this this new OS that allows brute-forcing".

The second case was apparently feasible enough that the FBI thought it was worth trying in open court. I don't think the first case is that dissimilar. And I think there is a decent chance that the NSA/CIA has stronger pressure methods than what the FBI tried in the San-bernedino case.

And if not, it seems quite a bit more feasible for new legislation to be written that could be used to force google to cooperate with malicious update signing. It certainly fits with the theme of recent "we should be allowed to read your messages" legislation attempts. Heck, I think it would be one of the more reasonable ways to implement such legislation.

If these cases are structurally the same and you assume (without evidence) that Google resists less than Apple - then why aren't you worried about OS updates for Android? You've never been able to trust any code running on an Android phone in this case.

Hypothetical new legislation could require you to download a NSA rootkit on all of your devices too. Nothing about this feature is uniquely weak to arbitrary legislation.

Disagree. If a developer signs a build, then I can verify the build came from the developer. If it is signed by Google, then who knows what may have been inserted into the app. This is especially bad for open source and security conscious apps.

Google literally controls the software delivery platform and silently updates a highly privileged service called Play Services on every phone. That service can access and backup data from apps private storage.

They really really don't need to touch your APK to get any user or app data. If you don't realize that, you may have been thinking of wrong threat models.

Apps have control over which data they allow to be backed up, and this is controlled by the OS, not the Google Play Store.

Verifying that the build came from the developer tells you nothing about whether the app has been backdoored when your adversary controls the compiler used to build the app and the operating system used to execute the app. Reflections on Trusting Trust explains why:

https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

If the SDK was backdoored it would show up on everyone's downloads, which greatly increases the chances of detection. Conversely, if the binaries were uploaded to an app store and were only signed by the app store itself, it's impossible to know whether you got a backdoored version or not.

What do you mean it would "show up in everyones downloads"? Google Play Services are constantly being updated on peoples phones. Literally nothing besides Google's decision not to prevents these updates from containing a backdoor.

Google Play Services is still bound by Android's own security mechanisms, it can't do everything but it can do a lot, yes.

It can silently replace APKs which is exactly what the conversation here is about. It's more than enough.

Can it? Does it run with root permissions? (Honest question, I don't know.)

If it's bound by the OS permission system and doesn't have full root, it might be able to replace apps with another version that is signed by a different key (using the "programmatic app installing" permission). However, that would wipe the app data and break app updates. Not even adb can replace an app with one that is signed by a different key without data loss (adb install -r). And I'm sure a lot of developers ask for this feature.

It can't. It can uninstall them, but then the app doesn't have any data after reinstallation.

I have no idea whether there are any APIs the Play Store has access to which expose that feature, but through ADB (or directly calling the package manager from the shell of a rooted device) you have been able to instruct Android to keep the app data even after uninstalling for a long time already.

(I haven't actually tried whether you can really successfully switch signatures on an APK that way without losing all user data, tough)

Additionally, starting from Android 10 it seems that there is a new official feature allowing data to be kept after uninstallation if an app opts-in (https://stackoverflow.com/questions/58750567/how-to-enable-o...).

> If the SDK was backdoored it would show up on everyone's downloads, which greatly increases the chances of detection.

I think you have far too much confidence in this. How exactly would the average Android developer check to see if the SDK they downloaded from Android Studio doesn't have a targeted exploit in it? Or Android Studio itself for that matter?

Have you ever checked the signing key on an app downloaded from Play? What developers even publish their public keys on the web?

This is mostly about updates (TOFU): If the OS installs the update, then you know it comes from the same developer.

Android has done it for me every time I install an update to an app.

Have you checked? Because people here are claiming that Google is an adversary in their threat models. So you can't just assume that the OS actually did verify the signing key.

Or perhaps it makes more sense to not consider the developer of your operating system to be adversarial.

> Have you checked?

Yes, I've stripped, patched and re-signed apps and verified that installing them as an update failed.

For various reasons I think it's reasonable to assume it's more difficult to be running a phone with a compromised OS (particularly given the bootloader is unlockable and you can install a 100% OSS ROM) than to assume the Play store is not serving something malicious.

Google is not some monolithic entity. And my android install is not under direct control by google (barring some back-door they installed). If google wants to change my android OS, they need to go through the play-store, or through Samsung to push an update. Those are difficult things to do. The play-store should still be bound by the OS, as it is simply an application. And going through samsung to deliver me a targeted update seems quite difficult and involves another party.

Besides, the worry is not "Google Evil". The worry is "Google might be coerced into compromising a specific user". For that usecase, presuming google is _not_ evil and has not backdoored pre-existing android installs, signed updates to apps actually help a lot.

As a matter of legal theory, forcing google to backdoor android / the play-store is so much harder than forcing google to just sign this one update of an app. This is not about "protecting ourselves from Google". This is about making it as hard as possible for google to do bad things, so it is harder for outsiders to influence Google.

I think that, for the argument you are making, the play-store is the strongest point. I am unsure of how deep the privileges of the play-store run, but it has more control than most apps, and is easily google controlled. I suspect that google would still need to run an exploit against android OS to actually get e.g. my signal messages.

> barring some back-door they installed

But that is the whole point. People are apparently concerned about a backdoor using one channel and not in another, which makes little sense. Either you trust Google or you don't. "It would be a little trickier to ship a bad OS version / WebView implementation / GMS implementation" isn't an especially meaningful approach.

> As a matter of legal theory, forcing google to backdoor android / the play-store is so much harder than forcing google to just sign this one update of an app.

I don't believe there is any evidence for this.

> I suspect that google would still need to run an exploit against android OS to actually get e.g. my signal messages.

If you are specifically worried about Signal then this change does not affect you because this is only a requirement for new apps. This is one reason why I find the argument that this is all a backdoor for the NSA so ridiculous. People seem to be claiming that the NSA has the strength to strongarm Google to implement a feature like this and roll it out for years (App Bundles have been around for a long time as an option) and is willing to wait for basically the entire market to turnover so that privacy-critical apps are all using this feature but can't force a change at the OS level that works universally.

Well, google doesn't control all of the android OSs currently installed so they'd have to jump through quite some hoops to not accidentally make such a backdoor obvious to a small but sizeable group of people.

Reply on news.ycombinator.com