Android security remarks

[phhusson]

About userdebug builds: "adds tons of debugging tools as extra attack surface"
You need to explain how significant the extension of surface attack is. There are already dozens of Turing Complete Machines available in a user build. The extension of SELinux policy is small compared to the holes most OEMs make in their SELinux policy.

"An attacker can fake user input by for example, clickjackers or they can exploit vulnerabilities in apps you've granted root to. "
Unlike the wording says, this isn't an actual attack. An attacker would need to find a security flaw for clickjacking. If user is using a Custom ROM, this isn't an issue, because Custom ROMs are always up-to-date with framework security patch, and the vast majority of clickjacks are framework-side.

The argument against root comparison with Linux is stupid. It's st ill harder for an attacker to get root on a root-ed Android device than on Linux. Even root-ed, the security of an Android is still much higher than of GNU/Linux. So yes using a root-ed device is still pretty secure.

"exposes root access via adb" this requires both physical access, and clickjacking exploit to be usable. This is still much more secure than application-facing root, and thus still infinitely more secure than any desktop OS.

"disables verified boot" even though it's true, it's already part of "unlocked bootloader" by design of Android, so it's redundant.

"It does not implement rollback protection" again, this is exactly the same argument. Also, please list OEMs that properly implement rollback protection. I believe even Google pretty much never uses rollback protection.

"It does not include firmware updates which prevents you from getting new patches to fix vulnerabilities." That's just plain wrong? kernel-wise (which in Android is considered "firmware update", I don't know if you do), Lineage is always ahead of every single OEM, including Pixels. They often include updated blobs from OEM when OTA appear.

"requiring signature spoofing which allows apps to request" Assuming this is behind a "privileged" permission, this requires secure-boot break of chain to exploit. If you break secure-boot chain, you don't fucking care about spoofing an app's signature.

"Firewalls" That's why users are additionally work profiles, for instance with Island for Android.

"Conclusion"
GrapheneOS doesn't give any answer to the "Firewall" section. Google is notorious for using very old version of Qualcomm's BSP, so following Linus' "Every bug is a security bug", Google is missing a lot of "firmware" security fixes

IOMMUs aren't exclusive to Pixels, by a wide margin.
Hardware-backed keystore is a requirement for every single Android device running Google applications. You should rather mention Pixel >= 3 have tamper-resistant keystore.
"hardened basebands", your source doesn't say this hardening isn't for all Qualcomm devices.
kernel CFI is "STRONGLY RECOMMENDED" in CDD, so you can bet most flagships already have it as well.
So, you haven't been able to list a single positive security aspect of Pixels. There is indeed one with Pixel, but using any 10€ SIM card as keystore would achieve the exact same feat.

"Verified boot is not just for local security as many people assume. Its main purpose is protection against remote attackers and the physical security is a nice side-effect. " This is bullshit.
The only positive aspect of verified boot when it comes to remote attackers is to prevent persistence, nothing else. If you find an exploit to become root, you'll become root, no matter whether there is verified boot or not.

[madaidans-insecurities]

About userdebug builds: "adds tons of debugging tools as extra attack surface"
You need to explain how significant the extension of surface attack is.

The link does that.

Unlike the wording says, this isn't an actual attack. An attacker would need to find a security flaw for clickjacking.

You're turning huge swaths of the OS into root attack surface. As soon as an attacker finds a flaw in the UI layer, they have root. Any harm made to the integrity of a closed system and its own security features is a potential vulnerability in its own. Even with custom controls you do add more layers of trust which can potentially fail, making something more insecure.

The argument against root comparison with Linux is stupid.

Wasn't a comparison.

It's st ill harder for an attacker to get root on a root-ed Android device than on Linux.

Please quote where I said otherwise.

"exposes root access via adb" this requires both physical access, and clickjacking exploit to be usable. This is still much more secure than application-facing root, and thus still infinitely more secure than any desktop OS.

Ok, please quote where I said otherwise.

"It does not implement rollback protection" again, this is exactly the same argument.

It's not. You can have verified boot without rollback protection.

Also, please list OEMs that properly implement rollback protection. I believe even Google pretty much never uses rollback protection.

Plenty of OEMs do. A few examples are Google, Xiaomi and Lg.

That's just plain wrong? kernel-wise (which in Android is considered "firmware update", I don't know if you do), Lineage is always ahead of every single OEM, including Pixels. They often include updated blobs from OEM when OTA appear.

Kernel updates aren't the same as firmware updates. How are they ahead of the OEM if they use OEM OTA's for the blobs?

Assuming this is behind a "privileged" permission, this requires secure-boot break of chain to exploit.

That depends on the ROM. What you're claiming is far too fetched and cannot be universally said about everything.

GrapheneOS doesn't give any answer to the "Firewall" section.

Never said it did. GrapheneOS does allow you to revoke the INTERNET permission though and there is an issue on restricting IPC: GrapheneOS/os-issue-tracker#156

Google is notorious for using very old version of Qualcomm's BSP, so following Linus' "Every bug is a security bug", Google is missing a lot of "firmware" security fixes

Citation needed.

IOMMUs aren't exclusive to Pixels, by a wide margin.

Never said it was. Not all devices do have an IOMMU. One example is Broadcom https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html

You should rather mention Pixel >= 3 have tamper-resistant keystore.

Finally a valid suggestion.

"hardened basebands", your source doesn't say this hardening isn't for all Qualcomm devices.

How isn't it?

kernel CFI is "STRONGLY RECOMMENDED" in CDD, so you can bet most flagships already have it as well.

Name one.

The only positive aspect of verified boot when it comes to remote attackers is to prevent persistence, nothing else.

Which is the "protection against remote attackers"...

Malware persistence is one of the biggest issues and shouldn't be downplayed. Would you rather have an attacker gain root once, or have a persistent rootkit spying on you indefinitely?

If you find an exploit to become root, you'll become root, no matter whether there is verified boot or not.

Please quote where I said otherwise. Sure, verified boot doesn't do anything to prevent gaining root but it does prevent persisting as root which is extremely important (see above).

Stop putting words in my mouth and creating straw men. You shouldn't call me out for things I didn't say to promote your own ideology. Please stick to what's written.

[phhusson]

About userdebug builds: "adds tons of debugging tools as extra attack surface"
You need to explain how significant the extension of surface attack is.

The link does that.

The only useful thing it says is "with the ability to enable additional debugging that normally violates the security model of the platform."

Unlike the wording says, this isn't an actual attack. An attacker would need to find a security flaw for clickjacking.

You're turning huge swaths of the OS into root attack surface. As soon as an attacker finds a flaw in the UI layer, they have root. Any harm made to the integrity of a closed system and its own security features is a potential vulnerability in its own. Even with custom controls you do add more layers of trust which can potentially fail, making something more insecure.

"Rooting your device allows an attacker to trivially gain extremely high privileges." So you're saying that clickjacking is trivial? Well please make me an UI clickjack on latest AOSP. I give you 2 hours. Should be plenty since it's trivial

The argument against root comparison with Linux is stupid.

Wasn't a comparison.

I really don't understand the point of the sentence then.
Or maybe your point is that using even the most atrociously broken custom rom with the worst root is still more secure than a desktop? Then maybe just say it so.

"exposes root access via adb" this requires both physical access, and clickjacking exploit to be usable. This is still much more secure than application-facing root, and thus still infinitely more secure than any desktop OS.

Ok, please quote where I said otherwise.

So "exposes root access via adb" isn't a security issue.

"It does not implement rollback protection" again, this is exactly the same argument.

It's not. You can have verified boot without rollback protection.

It's weird to be incremental like this in the argument, but ok fair enough.

That's just plain wrong? kernel-wise (which in Android is considered "firmware update", I don't know if you do), Lineage is always ahead of every single OEM, including Pixels. They often include updated blobs from OEM when OTA appear.

Kernel updates aren't the same as firmware updates.

Well please convince Google 🗡️

How are they ahead of the OEM if they use OEM OTA's for the blobs?

Where do I say they are ahead of OEM for blobs?

My point remains, custom ROMs are ahead in kernel patches, and the vast majority of plain sight security flaws are in the kernel. But I understand now that you're not trying to list pros and cons, you just want to impose your PoV.

Assuming this is behind a "privileged" permission, this requires secure-boot break of chain to exploit.

That depends on the ROM. What you're claiming is far too fetched and cannot be universally said about everything.

How is that far fetched? How is that "about everything"? You're speaking of a very specific feature, whose patch is a 30 liners, and which uses Android security measures. If you manage to break a "privileged" permission, then you got much better than faking signatures, you got INSTALL_PACKAGE

GrapheneOS doesn't give any answer to the "Firewall" section.

Never said it did. GrapheneOS does allow you to revoke the INTERNET permission though and there is an issue on restricting IPC: GrapheneOS/os_issue_tracker#156

It doesn't make sense to make a whole paragraph about firewalling and then not mention it in the conclusion.
As far restricting IPC, what I'm doing is have many work profiles. Does Graphene OS does that? That's not ideal, but that's easy to do.

Google is notorious for using very old version of Qualcomm's BSP, so following Linus' "Every bug is a security bug", Google is missing a lot of "firmware" security fixes

Citation needed.

Download Pixel 4 factory image, strings radio*.img |grep LA. you'll get LA.UM.8.1.c9, which is LTS of LA.UM.8.1, (i.e. only CVE fixes). Latest branch for Snapdragon 855 is LA.UM.8.1.r1 (LA.UM.8.1 is to be read as LA.UM.8.1.r0)

IOMMUs aren't exclusive to Pixels, by a wide margin.

Never said it was. Not all devices do have an IOMMU. One example is Broadcom https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html

Broadcom doesn't do smartphone Application Processors. they could implement IO-MMU in their WiFi SoC, but that's not needed if the PCI-E host has IO-MMU.
All high-end SoCs have got PCI-E IO-MMU for a long time.

"hardened basebands", your source doesn't say this hardening isn't for all Qualcomm devices.

How isn't it?

So you confirm that all Qualcomm devices have hardened basebands?

kernel CFI is "STRONGLY RECOMMENDED" in CDD, so you can bet most flagships already have it as well.

Name one.

I can't, I haven't audited other OEM's security.
Since you're not providing any sources, I guess you're basing your arguments exclusively on the marketing slides of the OEM, and Google has the best one?

The only positive aspect of verified boot when it comes to remote attackers is to prevent persistence, nothing else.

Which is the "protection against remote attackers"...

Malware persistence is one of the biggest issues and shouldn't be downplayed. Would you rather have an attacker gain root once, or have a persistent rootkit spying on you indefinitely?

So, in the threat model implied in this document, it is expected to have attackers get remote root access to your device?
You should write this in the introduction, because I think this is a major thing to know before reading the rest.

Stop putting words in my mouth and creating straw men. You shouldn't call me out for things I didn't say to promote your own ideology. Please stick to what's written.

Actually that's part of the problem. Waayyy too many things are implied, starting from the threat model. For most of the content of the article, it is almost state-level threat-model, and then when it comes malware persistence, it looks like it's protecting a 30$ toy.

[madaidans-insecurities]

The only useful thing it says is "with the ability to enable additional debugging that normally violates the security model of the platform."

It then links to more resources with more information such as https://source.android.com/setup/develop/new-device

So you're saying that clickjacking is trivial? Well please make me an UI clickjack on latest AOSP. I give you 2 hours. Should be plenty since it's trivial

It's trivial in comparison to the default.

I really don't understand the point of the sentence then.

"People often try to argue that if root was insecure then why does Linux allow root."

It's common argument for rooting I see around.

"Oh, so if rooting was so insecure then why does Linux allow root, huh?"

It's not comparing AOSP to Linux.

So "exposes root access via adb" isn't a security issue.

Yes, it is. It's more secure than application-facing root but is still a security issue.

Well please convince Google

Google already has them separate.

Where do I say they are ahead of OEM for blobs?

"Lineage is always ahead of every single OEM, including Pixels."

My point remains, custom ROMs are ahead in kernel patches, and the vast majority of plain sight security flaws are in the kernel.

Citation needed.

But I understand now that you're not trying to list pros and cons, you just want to impose your PoV.

No, I'm not. You're making baseless attacks.

How is that far fetched? How is that "about everything"? You're speaking of a very specific feature, whose patch is a 30 liners, and which uses Android security measures. If you manage to break a "privileged" permission, then you got much better than faking signatures, you got INSTALL_PACKAGE

Not all implementations use a privileged permission.

Does Graphene OS does that?

It has support for work profiles but whether they're used is up to the user.

Download Pixel 4 factory image, strings radio*.img |grep LA. you'll get LA.UM.8.1.c9, which is LTS of LA.UM.8.1, (i.e. only CVE fixes). Latest branch for Snapdragon 855 is LA.UM.8.1.r1 (LA.UM.8.1 is to be read as LA.UM.8.1.r0)

Yes, it's LTS, so obviously it won't be the latest release. They get security fixes backported so it is not a security risk.

Broadcom doesn't do smartphone Application Processors. they could implement IO-MMU in their WiFi SoC, but that's not needed if the PCI-E host has IO-MMU.
All high-end SoCs have got PCI-E IO-MMU for a long time.

Citation needed.

So you confirm that all Qualcomm devices have hardened basebands?

Modern basebands such as in Pixels do.

I can't, I haven't audited other OEM's security.

So you're making baseless assumptions.

Since you're not providing any sources

I did provide sources for Pixel's CFI. How am I meant to provide sources for other devices not having that? How do I give you a non-existent link? The burden of proof is on you to prove it exists.

I guess you're basing your arguments exclusively on the marketing slides of the OEM, and Google has the best one?

No, I'm not and you're making baseless attacks again.

So, in the threat model implied in this document, it is expected to have attackers get remote root access to your device?

That is the threat model for verified boot.

You should write this in the introduction, because I think this is a major thing to know before reading the rest.

I expect people to have basic knowledge of Android security first.

Actually that's part of the problem. Waayyy too many things are implied, starting from the threat model. For most of the content of the article, it is almost state-level threat-model, and then when it comes malware persistence, it looks like it's protecting a 30$ toy.

No, it's not. Those things aren't implied. You just keep making random assumptions.

[kyunal]

I would like to spill some words regarding your post @phhusson :

"Rooting your device allows an attacker to trivially gain extremely high privileges." So you're saying that clickjacking is trivial? Well please make me an UI clickjack on latest AOSP. I give you 2 hours. Should be plenty since it's trivial

Clickjacking is just a single side of the dice. As before, you add another layer of trust which you can never be assured fails. You have a door, but the lock might be picked. At the same time, you may forget to close the door or open it on accident. I.e., using Magisk you may press Allow on accident because the prompt just so happens to appear when you wanted to click on something else. You can just say it's the users fault, but in a secure environment there shouldn't even be the possibility for something to gain root access with one or even just a few button presses. On another hand, it's another door for someone else to inject malicious stuff without you noticing. Maybe it's just your kid doing BS or a friend without a clue. These are just examples, just like clickjacking is.

So "exposes root access via adb" isn't a security issue.

In what fucking state of mind are you? Your way of argumentation is ridiculous, it was simply mentioned that nothing like, what you mentioned, was ever said, and you attempt to turn it around into a useless claim. This is simply blaming.
Fyi, yes it is an issue.

Well please convince Google 🗡️

https://source.android.com/devices/bootloader/partitions-images
Should be sufficient, I could see them including kernel updates in a firmware update but it's generally not the same. In the same sense, Google here describes firmwares in various means, e.g. "baseband firmware", which is unrelated to the kernel in this very sense.

Where do I say they are ahead of OEM for blobs?

You mentioned Lineage is ahead of blobs with OEMs and in the same statement mentioned they pull them from OEM OTAs updates.

My point remains, custom ROMs are ahead in kernel patches, and the vast majority of plain sight security flaws are in the kernel. But I understand now that you're not trying to list pros and cons, you just want to impose your PoV.

What are you even talking about? Is it blobs or kernel patches? Also, this is a full generalization. And provide evidence that the most security flaws are in the kernel. Also, nice callout. If that's the case then you, at the very least, are not any different.

It doesn't make sense to make a whole paragraph about firewalling and then not mention it in the conclusion.

It is simply out of the means of what is described in this paragraph. This is about apps acting as firewalls.

As far restricting IPC, what I'm doing is have many work profiles. Does Graphene OS does that? That's not ideal, but that's easy to do.

See the referenced github-issue and where it leads to?

Download Pixel 4 factory image, strings radio*.img |grep LA. you'll get LA.UM.8.1.c9, which is LTS of LA.UM.8.1, (i.e. only CVE fixes). Latest branch for Snapdragon 855 is LA.UM.8.1.r1 (LA.UM.8.1 is to be read as LA.UM.8.1.r0)

If it is an LTS branch, meant to provide security patches over long time, then how is that a security vulnerability, considering they actively maintain it? That's just contradictionary, same as saying if I don't use a mainline kernel I'm automatically insecure just by it's release-flag.

I can't, I haven't audited other OEM's security.

Since you're not providing any sources, I guess you're basing your arguments exclusively on the marketing slides of the OEM, and Google has the best one?

Google essentially provides the reference implementations for security models on android devices also according to their very own guidelines. This isn't about marketing, but who is in charge of security measurements and what they may or may not do. Then again, you're contradicting yourself. You say you can bet on kernel CFI being a thing, cannot provide evidence, then call out for one's other belief.

So, in the threat model implied in this document, it is expected to have attackers get remote root access to your device?
You should write this in the introduction, because I think this is a major thing to know before reading the rest.

For one, this is just a given scenario. If you want to further specialize, having one install an app and the app abuses an active, e.g. kernel privelege escalation, exploit isnt necessarily uncommon. Issue being, without verified boot the attacker can now write themselves persistently into the system. Even if the malicious app is removed then, whatever has been installed will remain. This is much more dangerous and just one given scenario. This is further promoted by the things above about general, on-purpose root. This argument is not about the means in which root destroys the security itself, but rather having an active measurement to provide additional security for a sense in which the devices integrity might be at significant harm without.

Actually that's part of the problem. Waayyy too many things are implied, starting from the threat model. For most of the content of the article, it is almost state-level threat-model, and then when it comes malware persistence, it looks like it's protecting a 30$ toy.

Which is a shame since the style of argumentation that you're attempting to put critics on is the same one you seem to propose. What it seems like is that you're all so angry about at this being a specialized blog and not a general one. What you do not get is that this is someone elses and not your realm. The arguments made in the blog stand despite your misbelief. If you find them realistic or not is your thing but in the world of security every probability is a thing you can bet one someone will attempt to abuse, even if the sample size is strictly limited and not widespread. This is about bare security.

Man was this a long read.

[phhusson]

Okay, so for the context, I'm quite angry at this page, because I've seen people who don't understand anything about security read it. And from an outsider's PoV, it looks like this page is written by someone who knows about security and want to explain it to people who don't. Those people totally freaked out at even the idea of touching their phone. This is utterly stupid, especially then GrapheneOS won't protect those people, since they are much more likely to fall into phishing or installing dangerous apps from the store! GrapheneOS WILL protect tech-savvy people, sure, and the security they do is very nice, I'm happy they do their work, and I can't wait to see their micro-kernel architecture work.

The only useful thing it says is "with the ability to enable additional debugging that normally violates the security model of the platform."

It then links to more resources with more information such as https://source.android.com/setup/develop/new-device

Quote:
"The same as user, with these exceptions:

• Also installs modules tagged with debug.
• ro.debuggable=1
• adb is enabled by default.
  "
  So, it really says nothing if you don't already know what it is!
  I'm honestly interested in an actual analysis of this, because I sadly don't have much choice but to release userdebug ROMs (because of the way Treble certification works), but I'm happy to reduce the security risks by actually fixing thos issues.

So you're saying that clickjacking is trivial? Well please make me an UI clickjack on latest AOSP. I give you 2 hours. Should be plenty since it's trivial

It's trivial in comparison to the default.

Closest definition of trivial I can find on Wiktionary is
"Commonplace, ordinary. " I think I've seen three clicking issues in 8 years of Android? While rooting exploits are every year, so I guess that's not it
"(philosophy) Indistinguishable in case of truth or falsity." oh well maybe it's this one

I really don't understand the point of the sentence then.

"People often try to argue that if root was insecure then why does Linux allow root."

It's common argument for rooting I see around.

Then the argument should simply be that Linux is insecure.

So "exposes root access via adb" isn't a security issue.

Yes, it is. It's more secure than application-facing root but is still a security issue.

I agree. The point I was trying to make is that your document shows absolutely no sign of difference of dangerosity's range, while security is all about ranges, there is no absolute security.

Well please convince Google

Google already has them separate.

No they don't: https://source.android.com/security/bulletin/2020-03-01
2020-03-01 patches are framework patches; 2020-03-05 are vendor patches.
Kernel patches are in vendor patches, just like the others.

Where do I say they are ahead of OEM for blobs?

"Lineage is always ahead of every single OEM, including Pixels."

I don't mention blobs there, thanks for misquoting.

My point remains, custom ROMs are ahead in kernel patches, and the vast majority of plain sight security flaws are in the kernel.

Citation needed.

I don't mind doing the whole job, I just hope you'll agree on updating the page afterwards.

https://github.com/LineageOS/android_kernel_xiaomi_sdm845/blob/lineage-17.1/Makefile
https://android.googlesource.com/kernel/msm/+/refs/heads/android-msm-crosshatch-4.9-android10/Makefile

(I took the first lineage kernel that I found https://github.com/LineageOS/ search kernel)

How is that far fetched? How is that "about everything"? You're speaking of a very specific feature, whose patch is a 30 liners, and which uses Android security measures. If you manage to break a "privileged" permission, then you got much better than faking signatures, you got INSTALL_PACKAGE

Not all implementations use a privileged permission.

That's correct. Would you agree on adding that exception in your page? This would help promote using privileged permission instead of dangerous.

Does Graphene OS does that?

It has support for work profiles but whether they're used is up to the user.

Download Pixel 4 factory image, strings radio*.img |grep LA. you'll get LA.UM.8.1.c9, which is LTS of LA.UM.8.1, (i.e. only CVE fixes). Latest branch for Snapdragon 855 is LA.UM.8.1.r1 (LA.UM.8.1 is to be read as LA.UM.8.1.r0)

Yes, it's LTS, so obviously it won't be the latest release. They get security fixes backported so it is not a security risk.

So from your point of view, simply applying CVE fixes means it's secure?
(No I don't have proof that those LTS are exclusively based on CVEs, however that's the case of 99% LTS in the embedded industry, and since this isn't opensource, I can only assume)

Broadcom doesn't do smartphone Application Processors. they could implement IO-MMU in their WiFi SoC, but that's not needed if the PCI-E host has IO-MMU.
All high-end SoCs have got PCI-E IO-MMU for a long time.

Citation needed.

For which part?

Snapdragon 835 has an iommu on pci-express:
https://github.com/torvalds/linux/blob/663b7d41d5beab7fd0a5df123a1ac65e97718fc5/arch/arm64/boot/dts/qcom/msm8998.dtsi#L961
Of course, it is the same for Snapdragon 845, 855, 865

So, in the threat model implied in this document, it is expected to have attackers get remote root access to your device?

That is the threat model for verified boot.

Correct. Why did Google invested time in verified boot? It was at the time of Android KitKat, devices were riddled with malwares, and users had no way to remove it. This wasn't done for high grade security, it was made as a way to make malware more complicated. To show to which point this was just a first and easy line of defense: this was implemented before security patch bulletins even existed!
When you're an OEM that releases three security patches after the device release and you stop any updates after it, dm-verity is very useful, so that for most malwares users can just do a factory reset. But using a custom ROM, you're less likely to be hit with a rooting malware in the first place.

Actually that's part of the problem. Waayyy too many things are implied, starting from the threat model. For most of the content of the article, it is almost state-level threat-model, and then when it comes malware persistence, it looks like it's protecting a 30$ toy.

No, it's not. Those things aren't implied. You just keep making random assumptions.

Okay, sorry, my english might be wrong there. When I said "imply", I don't mean it's your intention, but that it's what many people would infer.

@kyunal I believe I answered to all of your points either on top or below, sorry if that's not the case

See the referenced github-issue and where it leads to?

Yes... and...? The issue refers to generic "profiles", it doesn't really say if it's multiple profiles on one device. Assuming it does say it supports multiple profiles on one device it doesn't mention the features available for it. And anyway, mentioning GrapheneOS supports it would be most useful in this page, no?

Also, this is a full generalization. And provide evidence that the most security flaws are in the kernel.

Okay, when I say "plain sight" I mean that anyone just has to look at Linux LTS releases, and pick random patches in it, and they'll most like find an issue which is an actual security issue. I'm not speaking theorically, gregkh did a demo where he took the first kernel patches in his latest LTS release that might have looked somehow relevant to a Pixel, and the 4th one managed to kernel panic the device from a non-privileged app. (You can watch his presentation at Kernel Recipes 2018)

I believe this is the only component in an Android device like this.

For one, this is just a given scenario. If you want to further specialize, having one install an app and the app abuses an active, e.g. kernel privelege escalation, exploit isnt necessarily uncommon. Issue being, without verified boot the attacker can now write themselves persistently into the system. Even if the malicious app is removed then, whatever has been installed will remain. This is much more dangerous and just one given scenario. This is further promoted by the things above about general, on-purpose root. This argument is not about the means in which root destroys the security itself, but rather having an active measurement to provide additional security for a sense in which the devices integrity might be at significant harm without.

To me, dm-verity is when you care about your product, not what is on it:

• If you care about not leaking your data, or not being victim of a crypto-ransomware, dm-verity is of no use
• If you care about not having to buy a new product, or being able to re-sell it, dm-verity is useful to be able to factory reset it and be cool with it

The issue, in my opinion, is that this page talks quite a lot about privacy leaks, and dm-verity does nothing about that. But I understand this is just my PoV, and that's why I think this page would gain a lot from having a simple threat model explained.

For CFI, I'll actually look at various device's kernels and report back, so that we can make this page larger.

[kyunal]

And from an outsider's PoV, it looks like this page is written by someone who knows about security and want to explain it to people who don't. Those people totally freaked out at even the idea of touching their phone. This is utterly stupid, especially then GrapheneOS won't protect those people, since they are much more likely to fall into phishing or installing dangerous apps from the store!

This blog is a bare collection of research and discoveries made over time. It's goal is not to enlighten those completly unaware or any similar. It is a reference. No one here is faulty of what other people make of it, how it is being spread and misused and it is not the author's concern.
Besides, phishing, as a general issue, is highly out of this range right here and completly unrelated. Again, this is bare security and not thing such as behaviour. And from a security standpoint, Graphene is definitely worth mentioning.

GrapheneOS WILL protect tech-savvy people, sure, and the security they do is very nice, I'm happy they do their work, and I can't wait to see their micro-kernel architecture work.

Graphene is not the end-all solution to every problem we have out there. It hardens the system against outside and even some inside attacks. That's it's goal and that's also what this blog is claiming.

So, it really says nothing if you don't already know what it is!

Two things: One, debugging shouldn't be enabled by default on a user's device. Again, this opens another, potential door for things go wrong and adds another layer of trust. Second, property "ro.debuggable=1" allows any app in a running system to be debugged, if access is available. That in connection with the former may cause security implications (say, we start debugging a banking app against it's will, password managers..) and shouldn't be enabled on a user's device.

but I'm happy to reduce the security risks by actually fixing thos issues.

Go for it.

Closest definition of trivial I can find on Wiktionary is
"Commonplace, ordinary. " I think I've seen three clicking issues in 8 years of Android? While rooting exploits are every year, so I guess that's not it

Clickjacking isn't much about exploitation, it's intended misbehaviour. It is not worth assigning actual vulnerabilities unless something in the system is wrong that makes said thing accessible. It's similar to phishing.

Then the argument should simply be that Linux is insecure.

See the linux chapter. Nothing else is claimed.

I agree. The point I was trying to make is that your document shows absolutely no sign of difference of dangerosity's range, while security is all about ranges, there is no absolute security.

Yet, no issue shall be left out. Some may be more critical than others, still, a vulnerability remains a vulnerability, which literally means security implication. Nothing there should be left out.

No they don't: https://source.android.com/security/bulletin/2020-03-01
2020-03-01 patches are framework patches; 2020-03-05 are vendor patches.
Kernel patches are in vendor patches, just like the others.

Read what I stated above, or:

https://source.android.com/devices/bootloader/partitions-images
Should be sufficient, I could see them including kernel updates in a firmware update but it's generally not the same. In the same sense, Google here describes firmwares in various means, e.g. "baseband firmware", which is unrelated to the kernel in this very sense.

Works too.

I don't mention blobs there, thanks for misquoting.

I now see your sentence structure, excuse my mis-reading. You're in the right there

I don't mind doing the whole job, I just hope you'll agree on updating the page afterwards.
https://github.com/LineageOS/android_kernel_xiaomi_sdm845/blob/lineage-17.1/Makefile
https://android.googlesource.com/kernel/msm/+/refs/heads/android-msm-crosshatch-4.9-android10/Makefile
(I took the first lineage kernel that I found https://github.com/LineageOS/ search kernel)

I wouldnt generalize as much but I else accept and agree on your point.

So from your point of view, simply applying CVE fixes means it's secure?
(No I don't have proof that those LTS are exclusively based on CVEs, however that's the case of 99% LTS in the embedded industry, and since this isn't opensource, I can only assume)

Generally: No. In this case, though the LTS fixes are made to ensure a proper running of the closed ecosystem which, in itself, is essentially secure (architecturally). Thus, using an LTS branch is in my opinion acceptable. Besides, this opens a completly new discussion about the dangerosity of running mainline vs. LTS. Neither is automatically superior.

Correct. Why did Google invested time in verified boot? It was at the time of Android KitKat, devices were riddled with malwares, and users had no way to remove it. This wasn't done for high grade security, it was made as a way to make malware more complicated. To show to which point this was just a first and easy line of defense: this was implemented before security patch bulletins even existed!
When you're an OEM that releases three security patches after the device release and you stop any updates after it, dm-verity is very useful, so that for most malwares users can just do a factory reset. But using a custom ROM, you're less likely to be hit with a rooting malware in the first place.

I don't see how that defeats the argument. Having an additional line of defense is always good and the world doesn't evolve around Custom ROMs. This is a valid and useful implementation done. See what I stated above as well.

@kyunal I believe I answered to all of your points either on top or below, sorry if that's not the case

You didn't, not even close :'(

Okay, when I say "plain sight" I mean that anyone just has to look at Linux LTS releases, and pick random patches in it, and they'll most like find an issue which is an actual security issue. I'm not speaking theorically, gregkh did a demo where he took the first kernel patches in his latest LTS release that might have looked somehow relevant to a Pixel, and the 4th one managed to kernel panic the device from a non-privileged app. (You can watch his presentation at Kernel Recipes 2018)
I believe this is the only component in an Android device like this.

I don't think I fully get you. In an LTS release of Linux, you don't expect features but fixes, be it security / whatsoever. This does not immediately imply, that this is the root cause of most problems. On a scale this big, issues are always to be expected if you will.
However, I will research what you suggested.

To me, dm-verity is when you care about your product, not what is on it:
If you care about not leaking your data, or not being victim of a crypto-ransomware, dm-verity is of no use
If you care about not having to buy a new product, or being able to re-sell it, dm-verity is useful to be able to factory reset it and be cool with it
The issue, in my opinion, is that this page talks quite a lot about privacy leaks, and dm-verity does nothing about that. But I understand this is just my PoV, and that's why I think this page would gain a lot from having a simple threat model explained.

See the things stated above about what this blog is about and what not. Besides, I don't think privacy is the entire concern here either. It may take some significant parts of the Android section, though. Yet, I wouldn't deny that dm-verity does not contribute to the device's integrity, as described in my above scenario. I see your cases to, but as you also pointed out it's opinion based, as is mine. I don't see dm-verity as a solution, rather as an addition, though.

[madaidans-insecurities]

Okay, so for the context, I'm quite angry at this page, because I've seen people who don't understand anything about security read it. And from an outsider's PoV, it looks like this page is written by someone who knows about security and want to explain it to people who don't. Those people totally freaked out at even the idea of touching their phone.

They should be worried about ruining the security model of their device.

This is utterly stupid, especially then GrapheneOS won't protect those people, since they are much more likely to fall into phishing or installing dangerous apps from the store!

GrapheneOS does protect more against dangerous apps because it hardens the OS far more against exploitation.

GrapheneOS WILL protect tech-savvy people, sure,

No, not just tech-savvy people.

So, it really says nothing if you don't already know what it is!

It tells you exactly what it does. If you want more information, you can look more into the stuff listed there.

The site is for a general overview. Not an in-depth analysis of userdebug builds.

I think I've seen three clicking issues in 8 years of Android?

Clickjacking is just an example.

Then the argument should simply be that Linux is insecure.

That's exactly what it is.

"Linux does not have a security model like Android does. On the usual Linux system, gaining root is extremely easy. "

This is quite clearly showing the insecurity of Linux.

https://github.com/LineageOS/android_kernel_xiaomi_sdm845/blob/lineage-17.1/Makefile
https://android.googlesource.com/kernel/msm/+/refs/heads/android-msm-crosshatch-4.9-android10/Makefile

The patch level is the exact same.

Would you agree on adding that exception in your page?

Yes.

So from your point of view, simply applying CVE fixes means it's secure?

When it gets all security fixes, how is an LTS release less secure?

Snapdragon 835 has an iommu on pci-express:

Obviously. We've already acknowledged that Qualcomm has an IOMMU. You said all high-end SoCs have one so show me one that isn't Qualcomm.

[phhusson]

The patch level is the exact same.

This isn't how Linux kernel security works.

Obviously. We've already acknowledged that Qualcomm has an IOMMU. You said all high-end SoCs have one so show me one that isn't Qualcomm.

My pleasure!

https://github.com/ivanmeler/android_kernel_samsung_beyondlte/blob/lineage-17.1/arch/arm64/boot/dts/exynos9825/exynos9825.dts#L9226

@kyunal

No one here is faulty of what other people make of it, how it is being spread and misused and it is not the author's concern.

I believe it is every expert's responsibility to put things in context to prevent misinterpretation. (No matter the area). It is of course not easy, so I won't say it's their /fault/. Not wanting to change anything, more so.

Two things: One, debugging shouldn't be enabled by default on a user's device. Again, this opens another, potential door for things go wrong and adds another layer of trust.

What is "debugging"? Many apps have include remote logcat capabilities, is that debugging? (it is to me)

Second, property "ro.debuggable=1" allows any app in a running system to be debugged, if access is available. That in connection with the former may cause security implications (say, we start debugging a banking app against it's will, password managers..) and shouldn't be enabled on a user's device.

I was pretty sure that wasn't the case (because I already wanted to do that) so I just tried:

beyond0:/ $ getprop ro.debuggable
1
beyond0:/ $ run-as com.lemonde.androidapp
run-as: package not debuggable: com.lemonde.androidapp
1|beyond0:/ $

I'm not saying you're wrong though, possibly it's just one tweak away from enabling it (and with adb root it's definitely possible). Yes that's a debuggable device without adb root (a security feature of Samsung kernel)

Clickjacking isn't much about exploitation, it's intended misbehaviour. It is not worth assigning actual vulnerabilities unless something in the system is wrong that makes said thing accessible. It's similar to phishing.

As far as I know, for Android framework security team, anything where:

• the attacker can control a field, or UI settings, that could mislead the user
• the attacker can ask for a seemingly not dangerous permission
• the attacker controls the timing of the click
  is considered a security flaw.

So I'm not to sure what's left?

I wouldnt generalize as much but I else accept and agree on your point.

I wouldn't either, but this page does. FWIW, the kernel I took as an example was the second I found on lineage github, first one was a 3.18, so I didn't bother trying to compare it with Pixel, but then github sorts by latest activity, so yeah latest active kernel could be up-to-date but not oldest.

[thestinger]

Having an IOMMU doesn't imply anything about how it's configured and used to isolate components. There is a huge range in what is done with it in practice. Those devices with uncontained Broadcom Wi-Fi have an IOMMU for PCIe. It doesn't mean that every (or any) PCIe device is actually isolated.

[thestinger]

2020-12-01 patch levels implies having 2020-11-05 and all other previous patch levels. The split into what's provided by AOSP and changes more specific to devices exists to acknowledge the additional difficulty in applying those patches. It means a device can claim to have the January 2021 patch level with only the December 2020 patches that are tied to the device. It does not mean that the components covered by the 2nd part of the monthly patch level are considered firmware. That's not the case.

The patches levels for the 1st of the month still include all the previous device-specific patches. The overall patch level is supposed to be set based on the overall security. At the moment, it is not actually supported to set a higher patch level for system for a production system. The system image is still assumed to be built with the rest and is assumed to reflect the overall patch level. If they actually want to start supporting separate system upgrades in production, they'll need to adjust the patch level display to take the minimum of all the OS images. It is not supposed to reflect the system patch level alone. It's unclear how low-level firmware would be handled, since having an updated vendor image doesn't imply that it's updated. There are expected version properties they could use in vendor to trigger a warning if the firmware gets out of sync but at the moment the warning is disabled for the SoC firmware versions in AOSP.

[thestinger]

There isn't actually a hard rule that kernel fixes go into the 2nd part of the monthly patch level. Without changing how any of it formally works, they could start having some of the kernel fixes included in the 1st part of the monthly patch level. It certainly doesn't mean the kernel or vendor image is considered firmware rather than part of the OS. It's not split based on system vs. vendor either. There are YYYY-MM-05 fixes that are dealt with via system image updates. That stuff should probably be in vendor or product, but it isn't always split that way.

Either way, the YYYY-MM-01 patch levels implies having all previous patch levels including the previous month's YYYY-MM-05 patch level. This is explained very explicitly in the documentation. And yes, that means the UI code in AOSP does not properly handle not updating everything in sync with each other. To properly support that, it would need to take a minimum across all the OS images along with having the expect properties set in the vendor image for SoC firmware and the code for enforcing that uncommented in frameworks/base since it's disabled by default.

[thestinger]

kernel CFI is "STRONGLY RECOMMENDED" in CDD, so you can bet most flagships already have it as well.

That's not how the CDD works in practice. Many things are recommended or strongly recommended that are not adopted elsewhere. Also, coarse-grained CFI like Samsung's old implementation is not at all comparable to type-based CFI. As with SELinux policies and IOMMU setup, this is not a black and white thing at all.

[thestinger]

AOSP-supported devices set the OS rollback index to the patch level, in response to that topic from earlier.

[thestinger]

Verified boot doesn't work properly if the OS breaks the security model it provides. Having a persistent way to grant root access to applications completely breaks it. The whole point of verified boot is to avoid trusting persistent state as much as possible. If an attacker can simply grant themselves root access without having to exploit the OS every boot to obtain it, then it bypasses the feature by breaking the security model it depends on having. This also breaks the application portion of the hardware-based key attestation feature. It can no longer chain trust to the application through the OS.

Having root access available via the UI certainly has a substantial impact on security. It makes it so that an enormous portion of the higher level OS has root equivalent access. Control over the UI is root access. This breaks a lot of the security model of the OS, not just verified boot. It also breaks the isolation of user profiles. It creates an enormous amount of highly privileged attack surface. It turns temporary control over the UI via much more common kinds of bugs into a deep compromise of the OS as a whole across all apps and profiles via persistent root access.

The root access from userdebug is much more constrained: only via adb, and not persistently granted. A userdebug build with ro.adb.secure=1 isn't that bad. It's a lot different than having root access granting via the UI in the OS without requiring anything special. Persistently granting it makes it worse by breaking verified boot, but it's quite bad without that. It screws up a lot of how OS security is supposed to work. The system profile also really isn't supposed to be able to spy on all the other profiles and mess with their data, and the same applies on a per-app basis and beyond that.

[thestinger]

Hardware-backed keystore is a requirement for every single Android device running Google applications

It's again not something that's black or white. The traditional TEE-based keystore has serious flaws. TEE implementations have massive attack surface in practice and they lack reliable deletion of data since they encrypt it and store it externally, generally via the OS. They have to rely on rollback resistance implementations, which aren't perfect, and are often missing. It also turns it into something that can be compromised, instead of having reliable deletion. The massively reduced attack surface and reliable deletion of keys are both very useful. Being able to reliably wipe data that has been written to persistent storage has a lot of practical uses.

The secure element on Pixels also doesn't only provide StrongBox either. It has other APIs that it provides including Weaver and it has insider attack resistance (must authenticate as the owner profile to upgrade the firmware on it). The https://grapheneos.org/faq#encryption section explains how Weaver works. On a device without Weaver, this hardware-based throttling is missing and they have to rely on a hash of a randomly generated 16kiB file (secdiscardable hash) to mimic having reliable deletion. It's essentially a hack and doesn't necessarily work.

Also, there's a huge different in secure element implementation quality. The Pixel 2 NXP secure element for Weaver was comparable to other off-the-shelf, typical Java smartcard secure elements. It wasn't on the same level as the Titan M. There is also hardware integration required beyond simply having the chip such as 1-bit secure input. Ideally, there would be secure input and output beyond that but it's infeasible that mainstream devices will provide it. 1-bit secure input means it can implement U2F. Traditional TEE has something similar via fingerprint reader but it's much less secure. Think about an actual hardware wallet for Bitcoin with secure confirmation of transactions (amount, destination, fee) vs. a generic secure element without secure input/output like that. It applies to more things than a Bitcoin wallet.

The secure element is not the only security advantage. It's one of the things that we'd need a hardware partner to provide in order to match (and then exceed) the security of Pixels. It would help a lot if Open Titan was actually complete and had the Android secure element APIs from the Titan M implemented so it could simply be produced based on that. The main issue we see is that we really wouldn't want to release devices yearly and it would take a lot of effort to make one. 3 year support from the SoC vendor is not nearly enough. It becoming 4 years isn't enough at all either. We'd at least want to be able to wait 2 years between releasing a device. Personally don't see much point in providing only half of the important security updates.