Pwning the all Google phone with a non-Google bug
github.blog
github.blog
Of course, such an exploit could be used for more nefarious things, but as google wants to limit functionality that the phone has (that is legal where I am), I'll be patient.
Also, my personal point of view of the matter is that apps that require Safetynet, 1. doesn't care about their users, 2. Do just-for-the-show security, and thus users would be better off not using them. I personally don't use any app that require it.
But I am aware that some apps work just fine, 4/7 banking apps I've used just work on aosp. Still haven't ridden a scooter via aosp though.
The real issue is why this is still not the case in "free" countries.
Maybe the author has a stricter and more negative definition of "won't fix" so it sounded wrong to him?
You do not get to sell hardware as "100% google" AND shitcan a kernel bug. you only get to do one of those two, and you must pick and stick with it.
Turns out you totally can.
Wish that were true!
The author knows full well the GPU is not actually made by Google, he is not an ignorant consumer being duped by marketing, so the label is actually 100% accurate for people in-the-know
It's their job to support their SOC and the GPU they chose to integrate onto it.
The article explains why this isn't a safe assumption and documents numerous cases where patches were not deployed to Android devices until well after the vulnerability was publicly disclosed. https://github.blog/2023-01-23-pwning-the-all-google-phone-w...
Thus is seems obvious to me that closing the bug as "won't fix" is the wrong response. The issue shouldn't be closed until the security patch makes its way into the Android Security Bulletin.
> Learn about the details of CVE-2022-38181, a vulnerability in the Arm Mali GPU. ... the exploit that used this vulnerability to gain arbitrary kernel code execution and root on a Pixel 6 from an Android app.
If security is important to you, you carry an iPhone. That's a sad state of affairs, Apple has all sorts of problems and a ton of things I just find weird about the way their devices tend to do things and organize information, but it's just the only actual option right now.
The problem in this case isn't Google dragging its feet on releases. It releases Chrome updates frequently and OS updates monthly. The problem here is Google failing to include security patches for known vulnerabilities in those releases. What's ridiculous is that this is something that can be automated, and after multiple failures, it should have been automated, but here we are.
It's very obvious when something like Heartbleed comes around which affects a ton of operating systems, and Windows and iOS and major Linux distros are patched in like a week and then there's a chart to look at for which manufacturer and model and carrier on whether or not you'll see a fix in the next couple months or ever.
The real problem is patch-gapping across updates (instead of within an update), which Apple also suffers from: https://blog.theori.io/research/webkit-type-confusion/
I'd expect both Apple and Google to spend the resources to automate this problem away, but the article shows this hasn't happened.
Ever heard of NSO's Pegasus? xD
Apple's security model is about securing App Store revenue first and foremost.
Are you aware that the state of security on iPhone is even worse nowadays? At least on Android the system surface has been reduced to its minimum. In iOS, pretty much every system component depends on the OS update and nothing has been decoupled yet.
That's not an excuse of course, but a lot of the blame does lie with the Linux devs and their general disregard for security. I suspect it is a major motivation for Fuchsia.
the most recent mention on their releases page is for the 2022120300 release:
> kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro): update Mali GPU driver to r37p0 (current release is r41p0 but there are substantial changes to the driver for the Tensor SoC on Pixels and it will take substantial work to upgrade all the way)
https://grapheneos.org/releases#2022120300
from the article:
> The Arm security team were very helpful throughout and released a public patch in version r40p0 of the driver on 2022-10-07 to address the issue [...]
That's not correct. Android 13 QPR2 Beta 1 came out on December 12th. This included backports of the ARM Mali GPU driver security along with a separate update to r38p1. GrapheneOS shipped these for the kernel driver.
> the most recent mention on their releases page is for the 2022120300 release:
That's not the most recent mention on our releases page. This is the most recent relevant change:
> full 2023-01-05 security patch level
Here is a previous Mali GPU driver update:
> kernel (Pixel 7, Pixel 7 Pro): update Mali GPU driver to QPR2 Beta 2 release
Here is another previous Mali GPU driver update:
> kernel (Pixel 7, Pixel 7 Pro): update Mali GPU driver to r38p1 along with other changes included in the QPR2 Beta 1 including a bunch of security fixes previously neglected upstream (GrapheneOS will continue applying further updates downstream)
Looking at the version number is not enough. ARM makes separate security patches available to their partners. Google is primarily shipping the backported security patches and gradually upgrades the driver version. The reason for this is that there are massive changes to the Mali GPU kernel driver for the Tensor SoC GPU. This is why GrapheneOS can't simply update it to r41p0 immediately because there are a massive number of complex synchronization, GPU command quality of service and other changes conflicting with newer releases. It makes the most sense to apply the standalone security patches. Unfortunately, ARM doesn't publish the standalone security patches for the public and we need to obtain them from a vendor choosing to include and ship them since they have to publish the code.
My confusion stemmed from the fact that the bug is supposed to affect pixel 6 devices, which aren’t listed in the QPR2 updates but were explicitly mentioned in the update to r37p0.
All of the security fixes first shipped with QPR2 Beta 1 on December 12 which we shipped on December 14th were then shipped in the AOSP / stock Pixel OS January stable release despite it still using r36p0.
The security patches are available without updating the major release, at least if you're either an ARM partner or an ARM partner has published an update with the patches and therefore released them. In our case, we can't get the standalone security patches directly from ARM but we can ship the kernel backports as soon as they're in an Android quarterly or major release beta. We can't necessarily ship the major releases of the driver just because they're in a quarterly or major release since they can depend on other changes which is what happened with the Pixel 6. It crashes without updating the userspace driver, not just the kernel driver, and updating the userspace driver seems to require other changes. It's not blocking any security patches though.
https://grapheneos.org/releases#2022121400
> kernel (Pixel 7, Pixel 7 Pro): update Mali GPU driver to r38p1 along with other changes included in the QPR2 Beta 1 including a bunch of security fixes previously neglected upstream (GrapheneOS will continue applying further updates downstream)
Our December 14th release was the release fixing this vulnerability and a bunch of others based on the Android 13 QPR2 Beta 1 release on December 12th which included these fixes. The January release of AOSP and the stock Pixel OS also included the security patch backports without including the update to r38p1. The update to r38p1 is nice to have since it fixes more bugs than the security bugs and has other improvements, so it's nice that we were able to ship it early but it's not really a security feature.
This isn't like the Linux kernel where there are an enormous number of changes and no serious attempt at determining which ones are security bugs. ARM does a good job determining which are security bugs and making security patches available separately. Unfortunately, ARM is not very friendly towards people building on their platform that are not partnered with them. They don't make the standalone security patches publicly available, even after a delay. It's possible they see making the patches available separately as helpful to attackers but that's a bit ridiculous because the code is available either way and it doesn't take long to identify the security patches which are one of the main things being done in the releases.
If ARM made the standalone security patches public available, we could get them to our stable channel within days of release instead of needing to wait for their partners like Google or Samsung to do their own releases and publish the patches. It would be very helpful to us if an ARM partner collaborated with us since we would be able to ship these fixes faster. The reason we can't simply upgrade to the new major releases of the driver immediately is because there are thousands of lines of changes to the kernel driver for the Tensor SoC with many invasive optimizations switching to finer grained locking across the driver, adding quality of service for GPU commands, etc. They made substantial changes to the driver and seemingly also the firmware/hardware to an extent, although likely just in between the actual GPU and the OS where they handle IOMMU, quality of service, etc. If they had a barely modified ARM Mali GPU and driver, we could easily update to each new major release in days, but that's not the case. We could do that on another device without so many changes to the driver though. It's entirely device specific. ARM provides a base for vendors to build on and how much they optimize/improve things downstream varies a lot. Google decided to do a ton of downstream optimization for the Pixel 7 GPU. They decided to focus on the GPU with that generation and let the CPU get neglected, which they'll almost certainly fix next year. Part of the initial growing pains for Tensor has been that they released the Pixel 6 with a great CPU but weak GPU and then the Pixel 7 with a great GPU but outdated CPU. These delays with Mali patches are another example, although other Android vendors almost all did worse not better.
I mean, I get it. It should not be easy to just unlock my phone and dump all my 2FA tokens. But if I want to back them up, i.e. because steam blocks my account for 7 days if I change to a new device, I want an option to get them!
Make me reboot the thing into a special state, connect it to a computer on blood moon and dance in front of the cam to authenticate myself if you must, but for fucks sake, I want to access my data.
For the specific use case you mentioned, however, I recommend Aegis with Syncthing. Very easy to set up a periodic back up and sync, encrypted at rest and on transit.
[edit: yes it does, although Steam doesn't use the standard, Aegis has special support for it]
Someone in this thread already pointed out that I'm wrong and although they don't use the standard, Steam is supported by Aegis.
For your suggestion, sadly you somehow need to get steam's otp secret first, which is held in the apps data directory. Therefore you would need root/priv-esc to get to it.
It only compromises those features because vendors refuse to build in the functionality to have full control over your purchased hardware out of the box. Make it protected behinds loads of warnings and even hidden behind a trick like what you have to do to enable developer mode, but leave it baked into the OS.
But having root in the running OS seems to be a bad idea. I got this position after an extensive talk on this with some of the graphene os developers. They explained pretty good how rooting the device would impact the security measures taken in graphene.
This is why I suggested putting the access behind a special boot mode.
I'll grant that on most phones you can't use ex. magisk with verified boot (although on ex. the Pixels I think you could? just more work), but AFAIK there's no problem with having root and selinux enforcing at the same time? Obviously it gives you the ability to bypass those protections, but overruling the usual protections is kind of the point of giving an app root, and you shouldn't give that level of access to apps you don't trust completely (like running `sudo someprogram` on a desktop).
I ended up with a new phone, decided not to root it, and found myself in a situation where I needed to get some cached data out of an app I could no longer access normally. That's easy on a rooted phone, but it's next to impossible on a locked down phone.
Lost a bunch of pictures and whatnot as a result.
There is not a great way for a phone to know whose system it is. Possession of the device doesn't necessarily mean that it is theirs.
>But if I want to back them up, i.e. because steam blocks my account for 7 days if I change to a new device, I want an option to get them!
Do you not see the irony in this? If you make it possible to switch to a new device without the 7 day lock then an attacker can bypass it too.
Edit: Thinking about it more, I suppose it all comes down to a cost/benefit analysis. It's true that taking a backup of 2FA secrets does give an attacker more than a single code. But when that trade is leveraged against the legitimate user being unable to control their own device, I think it's a terrible trade, to the point that I'm not convinced it's ever worth taking. And of course my real objection is that the user is rarely if ever actually asked; rather, a company tells the user that they can't control their own device, which is unacceptable.
Because the app aims to prove that someone has possession of the device. If someone has the key instead they can give back the device and generate codes later without possession. They can also resell the key online without having to ship a physical device. They can sell the same key to multiple people.