Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accidental Google Pixel Lock Screen Bypass

bugs.xdavidhu.me

Post reply on HN
Print view View original

311–320 of 475 posts

Re: Accidental Google Pixel Lock Screen Bypass

#311

Post by tmd83 »

Very weird implementation with UI stacks and dismiss. The way we designed a multi step flow for a web app was basically having a sort of state machine/flow which says what are possible transitions

say password > mfa1 > mfa2 > done

and as each steps complete what's the next security steps for this particular user's configuration and simply allow just that transition. Once we are at the done state the authentication is marked as successful.

Not storing auth state in UI (regardless of any MVC concern) and allowing only a very narrow allowed state of transition seems like a trivial design choice. I assume google has no shortage of people for security focused design.

The UI stack being created together and dismissed rather than created/called on demand as state transition happens also seem a very wired design. Perhaps I don't understand the reason cause I'm not an android programmer.

Re: Accidental Google Pixel Lock Screen Bypass

#312

Post by Twisell »

klausa wrote: post #75
gcr wrote: post #64

Earlier quoted context omitted.

On iPhone, keys are evicted from memory when the device is locked. Apps running behind the Lock Screen can only write files to special file inboxes (this is why the camera lets you take pictures while locked but doesn’t display earlier pictures, for example) You’re telling me that android keeps keys in memory for its entire uptime?

That's not exactly true. There is a data protection class that is like what you're describing, but it is not used super-widely, the one most commonly used is exactly what is being described and makes data available after first unlock. https://developer.apple.com/documentation/security/ksecattra...

Maybe but this should be limited to application data scope.

What baffles me is that lock-screen is a system wide critical application and should in no way rely on this method.

iOS lock screen in theory shouldn't only respond to cryptographic validation from the secure enclave.

Re: Accidental Google Pixel Lock Screen Bypass

#313

Post by joecool1029 »

noasaservice wrote: post #239
onychomys wrote: post #207

Earlier quoted context omitted.

Maybe having morals is worth $230k to the author.

You can say that, but he was going to get $0 if he already didn't have internal connections to google. If these companies try to cheap people out of what bounties they offer, then they need reminded that they're not the only game in town that'll pay for exploits.

This is the correct takeaway. It's damaging to their reputation to not admit the error and cheap out like this. I would hope they at least split the bounty between the two researchers, the one who initially raised it (but didn't complete their report?) and this one that had a fully documented chain.

Re: Accidental Google Pixel Lock Screen Bypass

#314

Post by _yb2s »

gcr wrote: post #64
tyingq wrote: post #16

Earlier quoted context omitted.

It didn't work on a fresh reboot, so presumably, it functioned like you're describing. But, when he swapped the sim live, without the reboot, the phone was already running with the key in memory.

On iPhone, keys are evicted from memory when the device is locked. Apps running behind the Lock Screen can only write files to special file inboxes (this is why the camera lets you take pictures while locked but doesn’t display earlier pictures, for example) You’re telling me that android keeps keys in memory for its entire uptime?

Do you have any more details about how that works on iphone? It seems very hard to believe, given the complexity and diversity of background apps on iphones, some of which access huge data that would be impossible in system memory (e.g. offline GPS/navigation apps). For example, Google Photos can send the full photo library on the phone, even if large, to the cloud while the device is locked.

Re: Accidental Google Pixel Lock Screen Bypass

#315

Post by 0cf8612b2e1e »

gw98 wrote: post #278
julianlam wrote: post #250

Earlier quoted context omitted.

Did this self-reported hardware engineer from Google tell you WHY his colleagues don't use a Pixel? You could have just as likely been listening to hot air from a random individual. Perhaps an Apple store employee with an axe to grind.

I'm not the OP but I know a couple of Google SRE's and an Android Auto HCI person and they use iPhones...

Sigh, like Microsoft UI designers using MacBooks. How does someone in charge not demand that the developers dogfood the product?

Re: Accidental Google Pixel Lock Screen Bypass

#316

Post by kelnos »

This is pretty terrible.

* The security screen "system" works as a stack, and the individual handlers for them don't actually have a reference to their own security screen. That seems like a terrible design; this design caused this bug, and the fix for it feels like a band-aid that could have unintended consequences (and thus new security implications) in the future. The handler for the security screen should have a reference to the security screen itself (or an opaque token or something like that), so it can be sure it is only dismissing its own screen. Passing a "security screen type", as the new, "fixed" code does, is not specific enough for this kind of code, and still seems unsafe to me.

* I'm a bit confused as to how this could unlock a newly-rebooted phone. Isn't the user data partition unmounted and encrypted? How could this partition get decrypted if the user doesn't get the opportunity to enter their device PIN, which should be needed to gain access to the partition's encryption key? I guess maybe it isn't decrypted, and that's why the system got stuck on the "Pixel is Starting" screen. Still, pretty concerning.

Meanwhile, my Pixel 4 still only has the October 2022 security update, claims there is no update waiting, and is presumably still vulnerable.

Re: Accidental Google Pixel Lock Screen Bypass

#317

Post by GaryPalmer »

titaniczero wrote: post #302
GaryPalmer wrote: post #258

Earlier quoted context omitted.

Quoted post unavailable.

They ended up rewarding him with $70,000 tho

yeah because he made a fuzz about it. Guess how many bugs are reported in and they just tell you it was already submitted and never talk to you again.

Re: Accidental Google Pixel Lock Screen Bypass

#318

Post by stardenburden »

kelnos wrote: post #316

This is pretty terrible. * The security screen "system" works as a stack, and the individual handlers for them don't actually have a reference to their own security screen. That seems like a terrible design; this design caused this bug, and the fix for it feels like a band-aid that could have unintended consequences (and thus new security implications) in the future. The handler for the security screen should have a…

It doesn't get decrypted. The data is still safe after a reboot. That's presumably why the phone hangs for the author after a reboot. Although some comments have said Android itself loads (and I guess also the launcher) but they can't really do anything

Re: Accidental Google Pixel Lock Screen Bypass

#319

Post by foobiekr »

gcr wrote: post #64
tyingq wrote: post #16

Earlier quoted context omitted.

It didn't work on a fresh reboot, so presumably, it functioned like you're describing. But, when he swapped the sim live, without the reboot, the phone was already running with the key in memory.

On iPhone, keys are evicted from memory when the device is locked. Apps running behind the Lock Screen can only write files to special file inboxes (this is why the camera lets you take pictures while locked but doesn’t display earlier pictures, for example) You’re telling me that android keeps keys in memory for its entire uptime?

This.

I actually find this incredible. I am familiar with iPhone security but not android and had naively assumed Google probably did a better job on the non-UX aspects.

Re: Accidental Google Pixel Lock Screen Bypass

#320

Post by int_19h »

rippercushions wrote: post #248
Edman274 wrote: post #244

I went to buy a phone maybe two months ago. Before I had my current Google Pixel 6, I used a OnePlus 3T for six years, and even then I only stopped because I sat in a hot tub with it on. At the T-Mobile store, I announced to the salesman that I would be back to buy a Pixel 6 when they had it in stock, and a man pulled me aside and privately asked me why I wanted to buy a Pixel. He explained to me that he was actually…

Out of curiosity, why have you been regretting it? I've been using Pixels for quite a while now and generally been quite happy.

Not OP, but for me, the biggest annoyance with Pixel 6 compared to older devices was the fingerprint reader under the screen - so uncomfortable to use, and so much less precise than dedicated readers on the back like they had before (or on power button, like some other phones do).

A general frustration with the entire Pixel line is the lack of video output options. It's basically Chromecast or GTFO - no Miracast, no USB-C video. It's kind of sad when an Android phone has worse compatibility with generic hardware than iPad! And the most annoying part is that Google deliberately removed all these at some point in the past.

Post reply on HN