[jcfrei]

I would like your take on a more specific question: Do you think that Google applications (GMail, Search, Translate, Maps, etc) themselves can get access to the necessary kernel subroutines to catch information which is intended for encryption? Or would running a custom rom (ie. cyanogenmod) while still using Google applications suffice to mitigate these attacks?

[md_]

Wait, what?

If you are running something based off of AOSP, you're running code that was touched by Google employees. Is your fear that Google is installing backdoors to help the CIA? If so, why are you afraid of that?

[sqeaky]

> you're running code that was touched by Google employees

Doesn't matter who touches code when that code is publicly visible and available to the scrutiny of everyone. AOSP can be checked out and audited independently, just like any open source project.

[md_]

Sure, I guess. As I noted elsewhere in this thread, in general your risk is that the cost of exploitation is low (e.g. Android 4.x) or your value of exploitation is high (e.g. San Bernardino shooter).

Open vs closed source is a distinction I don't see a lot of folks in the security community take seriously, and for good reason: it's a response to a very specific threat model, where your concern is not primarily accidental 0days but intentional backdoors.

I would posit that the cost of a backdoor is probably higher than the cost of an 0day: the reputational risk to Google or Apple if they were discovered to have planted one is worth potentially billions of dollars in sales, so they will spend a lot of money fighting any such court order (and, as far as we know, such an order has never been successfully made).

The counterargument here is that if the government did win such an order, the backdoor is the gift that keeps on giving, whereas 0days eventually get patched and fixed.

But that's a long digression. For most users, this is simply the wrong threat model.

[jcfrei]

Right, so in the scenario I mentioned, an update to a Google application would give this application more access to the kernel (through some backdoor) and enable it to intercept the communication of other apps. I'm asking whether this is possible or not - assuming the kernel itself cannot be modified. If that's the case then parts of the android kernel or the way android handles access to microphones, etc. might need to be hardened in the future.

[md_]

The Android security model doesn't work that way. Non-system applications can't access the kernel, minus a local EOP or something like that.

Is that your concern? And if so, why are you concerned specifically about Google apps? Any malicious app can exploit a local EOP.

[matharmin]

Google Apps are typically installed as system apps. Play Store is obvious, since it needs to be able to install/update applications without prompting. The need for other apps (e.g. Gmail) to need system-level permissions is less obvious, but most of them fail to run if you just sideload it without the permissions.

[md_]

Huh? What permissions are you referring to that the Gmail app has?

Also, if I remember right (and I'm not an Android expert, so grain of salt here), Android OS itself enforces sandboxing based on app signing keys; even the Play app can't overwrite the Signal binary without a binary signed by the same key (though conceivably it could install some other fake-Signal app that looks just like Signal and has a similar icon--but that app would not have access to your private key!).

[crowbahr]

While you are correct about the enforcement applying to Google Apps the Google Play Services has all possible permissions. I don't know if they could do something with the kernel from that alone though.

Personally I trust Android as much as I'd trust iOS... Which is to say I expect the government can get at either with physical access but only at the highest levels of government (CIA/NSA/FBI).

[jcfrei]

> Huh? What permissions are you referring to that the Gmail app has?

Maybe he was referring to these privileged permissions: http://android.stackexchange.com/a/17874/104563

[jcfrei]

Yes, that is my concern. You mention system applications - I believe this excludes any application which can be installed (with an app store or apk)? What is a local EOP? I couldn't find any info on this abbreviation. I used Google as an example.

[md_]

EOP = Elevation Of Privilege. e.g. a local->root exploit.

To expand, this would be some vulnerability which allows a non-privileged local app (like Gmail) to execute code at a higher security level.

The focus on Google apps specifically here is misleading. In the Android (and iOS) security model, apps are sandboxed, and cannot generally inject code into other apps (in contrast to most desktop OSes, where all processes running as "you" can sort of do what they want to each other).

The threats that apply on Android or iOS are, roughly speaking:

1. You grant an app more permission than it should have (e.g. microphone or keyboard input)

2. Local EOP plus installing a malicious nonprivileged app (or a remote code execution vuln) such that someone can get root on the device and inject code into Signal (or whatever)

3. A backdoor in the OS or app you are using

Android and iOS both have vulnerabilities in the wild. Older Androids are riddled with them, and the Android ecosystem is shit for getting updates out. If you're not using a Nexus or Pixel or a device from a reputable OEM (supposedly Samsung takes patches seriously, but I don't pay attention to this), you're probably easily exploited.

That's all the news that's here, AFAICT. The focus on encrypted messaging apps is on the one hand silly and on the othe rprobably necessary. Everyone in the security world knows that the easiest way to beat end-to-end encryption is to compromise the endpoint. But everyone in the wider world thinks that if they use Telegram they're secure, even if they're using an unpatched Samsung from 2011.

[shawnz]

Well, the Play store can seemingly update my system apps with no prompting. So I would guess that it's possible even on Cyanogenmod.

[sqeaky]

The open source side of that spun off as LineageOS: http://lineageos.org/

There was some huge political problem and the Cyanogen company did something the open source guys didn't like, so they left.