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

351–360 of 475 posts

Re: Accidental Google Pixel Lock Screen Bypass

#351

Post by dshpala »

btown wrote: post #60

The discussion on race conditions at the end is an important one, and IMO the bugfix is a bandage at best: the notion of anything accessing the “current” object after any kind of delay, especially in an event handler, when there is any chance the thing is not a singleton, is a recipe for disaster. In this case, dismissing the “current” security code screen was a supported API surface and that should set off all the r…

And of course fix includes magic SecurityMode.Invalid value, which makes dismiss() behave like it did before.

I'd look very hard at places that use SecurityMode.Invalid.

Re: Accidental Google Pixel Lock Screen Bypass

#352

Post by btown »

krajzeg wrote: post #179
izacus wrote: post #131

Earlier quoted context omitted.

So you'd go out and refactor a major security sensitive component (which dates to time before your career most likely) in a span of a single month for an emergency security patch deadline? That doesn't inspire a lot of confidence in your risk assesment and decision making. I'd do what Google did: rollout a patch that addresses the immediate danger and then backlog proper refactors over time.

Their fix included a similarly large refactor, they just used the "security screen type" as a newly introduced parameter instead of something unique to the screen instance. I do agree that in the real world, sometimes you have to settle for a less-than-ideal solution. I hope my post reads less like "those people are idiots", which was not my intent, but more like: this specific fix isn't ideal, and knowing this type…

Right? This was absolutely the "right" level of refactor for a hotfix, as the full refactor would introduce much more state management that could itself introduce bugs. And especially if behind the scenes there was a detailed audit of what things can currently access the current security screen, it would be fine for now.

But I sincerely hope that in the postmortem, there would be a larger meta-discussion around code review practices and how something like this "global dismiss" became part of the API surface to begin with, and a sincere prioritization of a larger review within the backlog. Though with everyone on edge at this time in big tech, I doubt that ends up happening :(

Re: Accidental Google Pixel Lock Screen Bypass

#353

Post by martinclayton »

jaywalk wrote: post #284
martinclayton wrote: post #109

My daughter wears earrings, so she never needs a SIM ejection tool. But I keep one on my keyring - amazing how handy it is. (I don't carry a PIN-locked SIM card!)

Why do you need to pop out your SIM so often? Is that an Android thing, or are you actually swapping your SIM all the time?

No, big family, frequent SIMs moving between phones. But it comes in handy for other things that need a similar pointy end too.

Re: Accidental Google Pixel Lock Screen Bypass

#354

Post by bluocms »

bluocms wrote: post #7

How come the security model is so basic? I even think they should dismiss modal by id instead of type. As this is a highly sensitive part, I think stacking lock screens on top of the unlocked menu leaves the door open for many bugs that could unlock your device. The unlocked menu should be locked at all times, and use a flag to monitor if it’s locked/unlocked, and only flip the flag when you unlock with biometrics or…

And this is something I come up on the spot. Engineers should think about like their life depends on it, this is a major security flaw.

Even more robust would be to switch that flag off by using the password or derived password from biometrics.

Re: Accidental Google Pixel Lock Screen Bypass

#355

Post by btown »

joezydeco wrote: post #161
btown wrote: post #60

The discussion on race conditions at the end is an important one, and IMO the bugfix is a bandage at best: the notion of anything accessing the “current” object after any kind of delay, especially in an event handler, when there is any chance the thing is not a singleton, is a recipe for disaster. In this case, dismissing the “current” security code screen was a supported API surface and that should set off all the r…

Am I reading this right? This reads like the presence of a UI element holds the unlock state of the phone?

Well, the UI element’s dismissal is what signals the system that holds unlock state. And the problem was that multiple other systems would automate the dismissal of the current UI element… without checking whether it was the appropriate UI element they expected to be there!

Re: Accidental Google Pixel Lock Screen Bypass

#356

Post by Sugimot0 »

Add to that the fact that the pixel 6 left audiophiles SOL for almost a year with no 3.5mm jack and broken USB-C DAC compatibility. Ontop of that Display Port Alt Mode is still disabled on every pixel for no good reason, despite many pixel owners reaching out to them, leaving us SOL for an alternative to samsung dex, or compaitibility with devices like the Nreal Air AR glasses.

Google's hardware support IME is a shit show. They need to stop spending all their time playing with ML tricks that nobody uses outside of ads and keynotes (aside from normal camera stuff), and start listening to customers and addressing bugs and missing features that even the mid-tier chinese phones have rolled out.

I'm buying a oneplus next time around and never looking back, idc if google's new chip gives me 2x battery life at the same price, it's not worth the frustration.

Re: Accidental Google Pixel Lock Screen Bypass

#357

Post by quantumsequoia »

Sugimot0 wrote: post #356

Add to that the fact that the pixel 6 left audiophiles SOL for almost a year with no 3.5mm jack and broken USB-C DAC compatibility. Ontop of that Display Port Alt Mode is still disabled on every pixel for no good reason, despite many pixel owners reaching out to them, leaving us SOL for an alternative to samsung dex, or compaitibility with devices like the Nreal Air AR glasses. Google's hardware support IME is a shit…

If you want a stable bug-free phone, oneplus is not the phone for you. Ever since they merged oxygenos and color os, oneplus phones are laden with bugs.

I was planning to switch from oneplus to pixel for this reason.

Re: Accidental Google Pixel Lock Screen Bypass

#358

Post by adrianprestamo2 »

krajzeg wrote: post #89
btown wrote: post #60

The discussion on race conditions at the end is an important one, and IMO the bugfix is a bandage at best: the notion of anything accessing the “current” object after any kind of delay, especially in an event handler, when there is any chance the thing is not a singleton, is a recipe for disaster. In this case, dismissing the “current” security code screen was a supported API surface and that should set off all the r…

Agreed. The fixed logic, at least judging by the commit message, still feels very shaky on correctness grounds ("if we are dismissing something that doesn't seem to be right, ignore it"). Since they're rewriting code and changing method signatures anyway, I would prefer they got rid of the notion of "currently visible screen" and made sure that all dismiss() calls have a unique pointer or token pointing to what exact…

No post body was provided.

Re: Accidental Google Pixel Lock Screen Bypass

#359

Post by adrianprestamo2 »

adrianprestamo2 wrote: post #358
krajzeg wrote: post #89

Earlier quoted context omitted.

Agreed. The fixed logic, at least judging by the commit message, still feels very shaky on correctness grounds ("if we are dismissing something that doesn't seem to be right, ignore it"). Since they're rewriting code and changing method signatures anyway, I would prefer they got rid of the notion of "currently visible screen" and made sure that all dismiss() calls have a unique pointer or token pointing to what exact…

Quoted post unavailable.

recursive comment
Post reply on HN