Hacker News new | ask | show | jobs
by cr4nberry 1312 days ago
This just sounds like you're prematurely optimizing for additional security screens getting added.

Maybe that's not on the table atm? Still odd that they took so long to change a couple method signatures and write a couple test cases
1 comments
avianlyric 1312 days ago
They already have multiple security screens, and a demonstrated critical bug with security screen confusion. Not sure how this is premature optimisation.
link
cr4nberry 1312 days ago
because if the number of screens is small and there are few tiers (only 2), passing an identifier around could be overkill

sounds to me like it's an optimization for introducing more tiers than what there are

link
strix_varius 1312 days ago
> 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 only 2 tiers" without enforcing that assumption with code is pretty much how the original bug was introduced.

link
roywashere 1312 days ago
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
link
johnfernow 1312 days ago
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.

1. https://news.ycombinator.com/item?id=33545685

link