[HN Gopher] Pwning the all Google phone with a non-Google bug
___________________________________________________________________
Pwning the all Google phone with a non-Google bug
Author : chmaynard
Score : 147 points
Date : 2023-01-23 16:03 UTC (6 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| compsciphd wrote:
| I'm waiting for a public exploit for the pixel 7 so that I can do
| some modifications to my phone (enable call recording outside
| countries that google supports call recording in). I could unlock
| the bootloader and root the phone via "normal" methods, however,
| that means having something that will then fail google safetynet
| and the like. A root exploit enables me to make the changes to on
| flash DBs, and then update the device and the DB changes will
| persist and my phone will be secure.
|
| 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.
| phh wrote:
| I perfectly understand not wanting to spend time on working
| around Safetynet, but in case you're not aware, I just want to
| point out that safetynet is pretty reliably broken (Google
| clearly doesn't use it for security. I'm pretty confident that
| it's 99% for passing audits, and 1% for shows). Current stats
| of the Safetynet workarounds is maybe 7 days of down time per
| year.
|
| 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.
| sigmonsays wrote:
| any grapheneOS users here who know if it's protected against this
| CVE?
| ylk wrote:
| as far as I can tell GrapheneOS doesn't have the patch, yet.
|
| 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 [...]
| AstixAndBelix wrote:
| Maybe I'm getting it wrong, but what's the problem in Google
| flagging this bug as "won't fix"? It's the third party driver
| that has a bug, not their software. Once the bug is fixed by the
| third party then automatically it will be fixed for Google.
|
| Maybe the author has a stricter and more negative definition of
| "won't fix" so it sounded wrong to him?
| ccouzens wrote:
| Even if they're not developing the code, it would be good for
| them to push the third party to get it fixed, given that the
| 3rd party is used in their product.
| ikekkdcjkfke wrote:
| They have to keep the source closed since there is ground-
| breaking, unicorn rockstar code that bankrupt them of it is
| open sourced
| dmitrygr wrote:
| > but what's the problem in Google flagging this bug as "won't
| fix"?
|
| 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.
| randmeerkat wrote:
| > You do not get to sell hardware as "100% google" AND
| shitcan a kernel bug.
|
| Turns out you totally can.
| intelVISA wrote:
| > you only get to do one of those two, and you must pick and
| stick with it.
|
| Wish that were true!
| AstixAndBelix wrote:
| We all know not 100% of the hardware is made by google. If
| there was a problem with the touchscreen, fingerprint sensor
| or camera drivers we all would be aware it came from a third
| party.
|
| 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
| dmitrygr wrote:
| GPU is not made by google, but kernel _IS_ compiled by
| google, who can fix a kernel bug in said kernel
| GeekyBear wrote:
| It's also Google's SOC.
|
| It's their job to support their SOC and the GPU they
| chose to integrate onto it.
| shkkmo wrote:
| > Once the bug is fixed by the third party then automatically
| it will be fixed for Google.
|
| 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.
| readams wrote:
| You're assuming that Google isn't keeping track of security
| bugs they forward to their vendors. Almost certainly they
| opened a ticket in a different system and tracked it there.
| roer wrote:
| I found this blog post very interesting, and would like to find
| more like it. Do any of you have go-to sites for this purpose?
| nhoughto wrote:
| https://googleprojectzero.blogspot.com
| herpderperator wrote:
| It should really say all-Google in the title, as it's otherwise
| confusing to read. The article even uses all-Google in the first
| paragraph - but not the title, oddly.
| kokonoko wrote:
| No such thing as an all Google phone. Trying to market the latest
| pixels as "Google silicon" is a complete joke. Not only the SoCs
| used are mildly customized Samsung Exynos, they are also terrible
| at performance and battery life even by Android standards.
| lern_too_spel wrote:
| The last section is damning for the Android security team. This
| is something that should be automatable.
| ocdtrekkie wrote:
| If security patching is important to you, you aren't carrying
| an Android. This has never not been true. Even here, on a
| Google phone, where Google can't blame manufacturers for
| dragging their feet on releases. Over a year after Microsoft
| officially abandoned Windows Mobile, I was still getting
| security patches faster and more often than Android phones ever
| did.
|
| 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.
| lern_too_spel wrote:
| On the contrary, Android is the only somewhat sane popular
| mobile OS today. I don't want to reboot my phone to update
| the web browser the way MacOS and iOS update Safari and the
| way Windows used to update IE. The browser is the application
| I use the most, and it has the largest attack surface.
| IshKebab wrote:
| It's not just Android. I think every Linux device has this
| problem. I seriously doubt my TV has any of these patches for
| example.
|
| 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.
| binkHN wrote:
| Relevant headline from the article:
|
| > 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.
| causi wrote:
| Damn. Wish this was for Adreno GPUs instead of Mali. Would be
| nice to have root on my phone.
| femtozer wrote:
| I was not expecting an Asterix ref here. Is it well known in the
| US?
| asimops wrote:
| OT: With the current state of smartphone operating systems, I
| would need one of those to be release every other month or so. I
| cannot get to data on 'my' system, because an app decided to put
| it in their app folder, which I cannot access at all for
| 'security' reasons...
|
| 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.
| yoavm wrote:
| That's why I still root my phone. It's hard to explain, but
| it's simply the only way to actually be in control of my own
| device.
|
| 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.
| remram wrote:
| Aegis doesn't support Steam.
|
| [edit: yes it does]
| stoltzmann wrote:
| It does (or at least did a couple months ago) - you could
| have it import Steam keys and generate the codes in the
| actual Aegis app. I'm not sure if it requires root or not.
| tecleandor wrote:
| IIRC (I tried to do it a couple months ago), it requires
| root to extract the key file.
| 0xdeadbeefbabe wrote:
| What is so great about Steam on mobile?
| remram wrote:
| I'm not trying to say it's great, just that a few
| websites insist on using their own home-brewed 2FA and
| therefore don't work with the apps that support the
| standard. For example Twilio/SendGrid, Steam, etc.
|
| Someone in this thread already pointed out that I'm wrong
| and although they don't use the standard, Steam is
| supported by Aegis.
| Idiot_in_Vain wrote:
| There's an endless supply of 0-days in both Android and Windows
| drivers.
| [deleted]
| ikekkdcjkfke wrote:
| Good then that it auto installs random vendor supplied blobs
| whenever I plug in a mouse
| fbdab103 wrote:
| How is this blanket approval system acceptable? The majority
| of hardware vendors have lost all credibility in producing
| secure software, and Microsoft think it is ok to let them
| load a Logitech/HP wizard toolkit for funsies? Few of them
| offer any features of note, but I would not be at all
| surprised they run with elevated permissions and contain
| trivially exploited code.
| [deleted]
___________________________________________________________________
(page generated 2023-01-23 23:00 UTC)