Android security remarks #1
Comments
The link does that.
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.
Wasn't a comparison.
Please quote where I said otherwise.
Ok, please quote where I said otherwise.
It's not. You can have verified boot without rollback protection.
Plenty of OEMs do. A few examples are Google, Xiaomi and Lg.
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?
That depends on the ROM. What you're claiming is far too fetched and cannot be universally said about everything.
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
Citation needed.
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
Finally a valid suggestion.
How isn't it?
Name one.
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?
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. |
The only useful thing it says is "with the ability to enable additional debugging that normally violates the security model of the platform."
"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
I really don't understand the point of the sentence then.
So "exposes root access via adb" isn't a security issue.
It's weird to be incremental like this in the argument, but ok fair enough.
Well please convince Google 🗡️
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.
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
It doesn't make sense to make a whole paragraph about firewalling and then not mention it in the conclusion.
Download Pixel 4 factory image,
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.
So you confirm that all Qualcomm devices have hardened basebands?
I can't, I haven't audited other OEM's security.
So, in the threat model implied in this document, it is expected to have attackers get remote root access to your device?
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. |
It then links to more resources with more information such as https://source.android.com/setup/develop/new-device
It's trivial in comparison to the default.
"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.
Yes, it is. It's more secure than application-facing root but is still a security issue.
Google already has them separate.
"Lineage is always ahead of every single OEM, including Pixels."
Citation needed.
No, I'm not. You're making baseless attacks.
Not all implementations use a privileged permission.
It has support for work profiles but whether they're used is up to the user.
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.
Citation needed.
Modern basebands such as in Pixels do.
So you're making baseless assumptions.
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.
No, I'm not and you're making baseless attacks again.
That is the threat model for verified boot.
I expect people to have basic knowledge of Android security first.
No, it's not. Those things aren't implied. You just keep making random assumptions. |
|
I would like to spill some words regarding your post @phhusson :
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.
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.
https://source.android.com/devices/bootloader/partitions-images
You mentioned Lineage is ahead of blobs with OEMs and in the same statement mentioned they pull them from OEM OTAs updates.
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 is simply out of the means of what is described in this paragraph. This is about apps acting as firewalls.
See the referenced github-issue and where it leads to?
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.
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.
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.
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. |
|
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.
Quote:
Closest definition of trivial I can find on Wiktionary is
Then the argument should simply be that Linux is insecure.
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.
No they don't: https://source.android.com/security/bulletin/2020-03-01
I don't mention blobs there, thanks for misquoting.
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 (I took the first lineage kernel that I found https://github.com/LineageOS/ search kernel)
That's correct. Would you agree on adding that exception in your page? This would help promote using privileged permission instead of dangerous.
So from your point of view, simply applying CVE fixes means it's secure?
For which part? Snapdragon 835 has an iommu on pci-express:
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!
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
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?
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.
To me, dm-verity is when you care about your product, not what is on 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. |
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.
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.
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.
Go for 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.
See the linux chapter. Nothing else is claimed.
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.
Read what I stated above, or:
Works too.
I now see your sentence structure, excuse my mis-reading. You're in the right there
I wouldnt generalize as much but I else accept and agree on your point.
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.
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.
You didn't, not even close :'(
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.
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. |
They should be worried about ruining the security model of their device.
GrapheneOS does protect more against dangerous apps because it hardens the OS far more against exploitation.
No, not just tech-savvy people.
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.
Clickjacking is just an example.
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.
The patch level is the exact same.
Yes.
When it gets all security fixes, how is an LTS release less secure?
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. |
This isn't how Linux kernel security works.
My pleasure!
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.
What is "debugging"? Many apps have include remote logcat capabilities, is that debugging? (it is to me)
I was pretty sure that wasn't the case (because I already wanted to do that) so I just tried: 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
As far as I know, for Android framework security team, anything where:
So I'm not to sure what's left?
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. |
|
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. |
|
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. |
|
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. |
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. |
|
AOSP-supported devices set the OS rollback index to the patch level, in response to that topic from earlier. |
|
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. |
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. |
|
Also, an issue with most other devices aside from monthly security updates is lack of support for the verified boot and other features tied the hardware keystore, etc. with other operating systems. This appears to be getting better over time but the status quo is still that most devices either don't bother with it or ship an incomplete / broken implementation. They need to properly support the yellow boot state with AVB (secure storage of the public key and rollback index + enforcement of them) and have the integration for it with the keystore and disk encryption. For GrapheneOS, what we want is a hardware partner capable of getting a device produced doing all of these things properly including having a good secure element providing the full set of features. Then, we can think about doing better rather than simply matching the existing security while having control over the device. It's just not interesting to us to consider devices with major flaws in these areas. |
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.
The text was updated successfully, but these errors were encountered: