Lol this reminds me of those windows login bypasses by navigating some convoluted menus
Accidental Google Pixel Lock Screen Bypass
51–60 of 475 posts
Re: Accidental Google Pixel Lock Screen Bypass
#52Every once in a blue moon when I pick up my locked iPhone (which auto-locks in just 30 seconds) and engage the home button just as the screen comes alive from the gyro sensing movement, it unlocks on its own. It just flashes the PIN dialog and slides right onto the home screen. I don't use Touch ID, and never stored my print with it even once to test the feature/hardware. It's been happening ever since iOS 11, with both my 1st gen. iPhone SE and my current iPhone 8.
Re: Accidental Google Pixel Lock Screen Bypass
#53This is a great example of why you should use iOS. Most android devices do not receive security updates long enough to get this update. Since the author effectively tells you how to do it, all you need to do is find a pixel 4 or older and you’re golden.
Besides my opinion that iOS is just simply better built and more secure, the biggest difference for me comes down to the UI. Maybe my mind is just wired more for iOS, but subjectively I would say that it's by far the superior user interface. Snappy as hell too.
Re: Accidental Google Pixel Lock Screen Bypass
#54> The bug just got fixed in the November 5, 2022 security update. Lovely. My Pixel 4 got it's last update in Oct.
Same. Absolutely unbelievable that they sat on this to avoid having to fix it.
Re: Accidental Google Pixel Lock Screen Bypass
#55I can't believe this is not a "drop everything and get it fixed ASAP" bug. This makes me think there's probably tons of other similar bugs out there being exploited right now even with disclosure.
I forget which Pixel generation. For one generation Google I believe never shipped the ability to unlock your phone with your face. Despite having all the hardware on the phone, it just didn't have the feature. This was a serious feature deficit viz a viz the relevant iPhone at the time. The gossip was, the feature was finished, completely. Had to be ripped out after external pen-testing bypassed it with Facebook pho…
Android introduced face unlocking in 2011[0]. It used the regular front camera and hence had no depth information, which makes it vulnerable to photos[1]. It was removed in Android 10, when a new face authentication interface[2] was added. Face unlocking without specialized hardware such as what iPhones have is not secure.
[0] https://www.androidauthority.com/face-unlock-android-4-0-ice...
[1] https://www.androidauthority.com/android-jelly-bean-face-unl...
[2] https://source.android.com/docs/security/features/biometric/...
Re: Accidental Google Pixel Lock Screen Bypass
#56I wish closing things as "this is a duplicate" essentially required disclosure of the original (dupe) report. It may well be that it's a dupe, or it may be something that looks similar but not actually the same. And indeed as in this case it's only the follow up report that got the bug fixed. In this case it seems that contacts at google allowed them to escalate anyway and get it fixed. But so often and especially wi…
> I wish closing things as "this is a duplicate" essentially required disclosure of the original (dupe) report.
Only if it has been fixed and is allowed to be talked about, else malicious actors will submit speculative bugs to see if they catch anything.
Re: Accidental Google Pixel Lock Screen Bypass
#57I can't believe this is not a "drop everything and get it fixed ASAP" bug. This makes me think there's probably tons of other similar bugs out there being exploited right now even with disclosure.
The security researchers only mistake was letting Google fart around for so long. You give them 90 days, then you go public. That is the policy Google Project Zero holds other companies to, so it is only fair to hold Google to the same standard. People using their device for high risk applications need to be informed in a timely manner, and Google needs to pay a reputational price for their negligence.
If you use a Pixel for high risk applications you are a bit at fault here
Re: Accidental Google Pixel Lock Screen Bypass
#58Given how much engineers make at Google after a long interview process to supposedly only get the best people, how significant the login system is to security, how "industry standard" the Google process is, it's not a bug that should have ever made it live. The bug fix show that the issue was clearly a case of a set of people not communicating well, code reviews being lax, and a general lack of understanding of how Android works.
It's also possible that the code is too complex to understand fully which is a requirement for a correct operation. Bugs happen, but I've seen way too many cases where complexity and lack of understanding led to surprisingly bad outcomes.
The login process should have the highest amount of scrutiny.
Re: Accidental Google Pixel Lock Screen Bypass
#59I can't believe this is not a "drop everything and get it fixed ASAP" bug. This makes me think there's probably tons of other similar bugs out there being exploited right now even with disclosure.
The security researchers only mistake was letting Google fart around for so long. You give them 90 days, then you go public. That is the policy Google Project Zero holds other companies to, so it is only fair to hold Google to the same standard. People using their device for high risk applications need to be informed in a timely manner, and Google needs to pay a reputational price for their negligence.
70,000 reasons to think long and hard about that appraoch though :-D
Re: Accidental Google Pixel Lock Screen Bypass
#60The 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 red flags.
Of course it’s annoying to have to track the identity of “our screen” and bind that identity to event handlers, or make it accessible with context etc. But it’s necessary in anything remotely security-adjacent.
(And never assume anything is a singleton unless you add a breadcrumb comment for someone who might change that assumption on a different team!)