So basically google wanted to give this guy nothing. Then he set a hard deadline for disclosure and google managed to buy him for 70k so they could stick with their own deadline.
It would not surprise me if in some cases, google runs the exploit up the tree to the NSA to see if they're actively using this for matters of national security, then slow-walk the patch to release. Given how easy the exploit is (no software needed, no special equipment beyond a paper-clip), would not surprise me if this has been in wide use for several years now by various groups.
Accidental Google Pixel Lock Screen Bypass
441–450 of 475 posts
Re: Accidental Google Pixel Lock Screen Bypass
#442The 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…
> The fixed logic, at least judging by the commit message, still feels very shaky on correctness grounds
This was my experience as a dev on a team at Google for a few years. I saw a LOT of exceedingly lax treatment of correctness in the face of concurrency. There have even been multiple decisions I've seen to guess at how to fix concurrency bugs and just say "well, looks good to me, let's see if it does anything."
It's par for the course, and folks get (got? =P) paid handsomely for doing it.
Re: Accidental Google Pixel Lock Screen Bypass
#443Earlier quoted context omitted.
> the number of screens is small and there are few tiers (only 2) Making this kind of assumption, when there are no such guards in the system itself, is exactly what leads to security issues. If the system enforced two named singletons as security screens, so it was impossible to .dismiss() the wrong thing, then sure. But that's not how the system is, and assuming that "the number of screens is small" and "there are…
Since they are dismissing the Lock Screen _type_ (SIM, PUK, Pin) and not the instance, a logical example for where this might go wrong is if you have dual SIM. Then again, worst case you dismiss the incorrect SIM Lock Screen. That will not give you full unlock and also the ‘wrong’ SIM will still not work
Yeah an attacker may be able to use their own personal dual SIM Pixel phone to bypass the SIM lock screen for a stolen SIM card that they don't know the PIN or PUK code to using a similar technique, but like you said, I'm almost certain that it wouldn't actually let them use it to send and receive texts (and if it does, then that's really an issue in the SIM card's OS, considering anyone could just modify AOSP to ignore the SIM lock screen and then put that on their own phone.)
Even still, being able to bypass the SIM lock screen would still be a bug, just not a vulnerability. Google doesn't pay bounties for non-security related bugs to the best of my knowledge, but I can't help but feel this is still not an ideal way to design the system. It likely is fine today, but as strix_varius said, these kind of assumptions are what led to this vulnerability in the first place. Vulnerabilities do pop up from time to time in otherwise well-designed systems, but this lock screen bypass never would have been present in the first place had better design practices been followed. As krajzeg said [1], The whole process and the nature of the fix doesn't inspire a lot of confidence in the security of Pixel/Android in general.
Re: Accidental Google Pixel Lock Screen Bypass
#444I think I triggered this a few times; I use a alarm clock that's dismissed via math equation which I frequently get mixed up with the lock screen when waking up. I have GrapheneOS set to auto-reboot every 8 hours so then there's also the SIM unlock screen. In the state of just waking up it's easy to PUK lock the SIM. I guess I just assumed the "Pixel is starting" message was some unrelated bug and just manually restarted. I think you can still continue to a normal boot if you manually lock or wait for the lock screen PIN timeout to expire.
Re: Accidental Google Pixel Lock Screen Bypass
#445The 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…
Yeah, I suspect this fix isn't going to hold for very long at all now that everybody knows to look at it.
If Google isn't readying a more extensive fix right now, they're going to get pwned shortly.
Re: Accidental Google Pixel Lock Screen Bypass
#446#0016 VENDOR: GOOGLE STATUS: FIXED (NOVEMBER 2022 UPDATE) REPORTED: JUN 13, 2022 DISCLOSED: NOV 10, 2022 (150 DAYS) Project Zero only gives vendors 7 or 90 days before disclosure... The short version: Project Zero won't share technical details of a vulnerability for 30 days if a vendor patches it before the 90-day or 7-day deadline. The 30-day period is intended for user patch adoption. https://googleprojectzero.blog…
This is also the point that stands out to me the most. This is hypocritical and pretty close to negligent, if they set such high standards for other companies they investigate but can't own up to it themselves.
I can only hope this is a singular case or else the argument "yeah we collect your data but we also keep it safe!" falls pretty quickly.
Re: Accidental Google Pixel Lock Screen Bypass
#447Kind of related: My new Samsung S8 c. 2017 has unlocked a few times without my finger or password. The first couple times I figured user error. By the 5th time, I'm pretty sure it's a software/hardware issue. Now my version of Android doesn't even get security updates any more. Maybe time for a new phone.
Re: Accidental Google Pixel Lock Screen Bypass
#448#0016 VENDOR: GOOGLE STATUS: FIXED (NOVEMBER 2022 UPDATE) REPORTED: JUN 13, 2022 DISCLOSED: NOV 10, 2022 (150 DAYS) Project Zero only gives vendors 7 or 90 days before disclosure... The short version: Project Zero won't share technical details of a vulnerability for 30 days if a vendor patches it before the 90-day or 7-day deadline. The 30-day period is intended for user patch adoption. https://googleprojectzero.blog…
If you follow published reports of Android vulnerabilities you'll see that taking longer than 90 days for a fix is actually not that rare. I myself had a similar experience a couple of times.
Re: Accidental Google Pixel Lock Screen Bypass
#449Earlier 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?
Nonsense. If that was true then things like backups and cloud sync couldn't happen when the device is locked. But of course they do, meaning the keys are still sitting there freely accessed by the CPU, along with all the data on disk.
Your camera example is not at all convincing of anything special going on, since that's also the camera behavior of other OS's (like Android) that don't purge the keys. That's far more easily implemented as just a basic app policy than some security system that yanks the file system out from underneath running processes.
Re: Accidental Google Pixel Lock Screen Bypass
#450Earlier quoted context omitted.
It works. It's basically a software brute force that works great for 4 digit pins, takes longer for longer passcodes. Other offerings are a keylogger for the pin/passwords after they "return" the device to the suspect.
How would you install a keylogger on an encrypted device without rooting it or deleting user data?
maybe you could sniff the data coming from the touchscreen with something you physically install into the phone.