Live data from Hacker News

Accidental Google Pixel Lock Screen Bypass

bugs.xdavidhu.me

141–150 of 475 posts

Re: Accidental Google Pixel Lock Screen Bypass

#141
post #125

Earlier quoted context omitted.

Surely you can find something more recent than five years.

I don't see how the timing is relevant here.

Let’s take it to the extreme. Suppose this becomes the last bug Google exhibits in the next fifty years. Forty nine years in the future Apple makes a major security faux pas.

Do we need to remind everyone that Google made a bug fifty years ago, too?

Re: Accidental Google Pixel Lock Screen Bypass

#142
post #19
post #11

I 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…

I'm not really sure what you're talking about - the only generation that had LIDAR was Pixels 4/4XL and those shipped with face unlock.

There WAS a rumor about Pixel 6, but it doesn't have any special face unlocking camera. Pixel 7 does support face unlock without special hardware with caveat that it's less secure.

Re: Accidental Google Pixel Lock Screen Bypass

#143
post #103

Earlier quoted context omitted.

There's nothing OOP-specific about this bug. The bug is in too-wide variable scoping, insufficient OO really.

It calls .dismiss() expecting the PUK screen but it's a different object instead. This is the kind of thing that OOP rely on.

Sure, but it’s a race condition that could happen in a functional language, too. FP has an analogue to a class called ADTs, and you could have the same bug using those

Re: Accidental Google Pixel Lock Screen Bypass

#144
post #103

Earlier quoted context omitted.

There's nothing OOP-specific about this bug. The bug is in too-wide variable scoping, insufficient OO really.

It calls .dismiss() expecting the PUK screen but it's a different object instead. This is the kind of thing that OOP rely on.

Again not really, somewhere, something send a signals, and outcome of that signal depends on UI state. The problem is a lack of qualified signals and validated state changes, whatever the programming model used, if the logic is «remove topmost screen without any context check», you'll end up with this issue.

Re: Accidental Google Pixel Lock Screen Bypass

#145
post #126

Earlier quoted context omitted.

Surely you can find something more recent than five years.

Like Apple not patching macOS security holes on older versions: https://arstechnica.com/gadgets/2021/11/psa-apple-isnt-actua... ? (This happened again with Ventura).

Exactly. And I suggest this is a much better example of egregious security practices than that 5yo article.

Re: Accidental Google Pixel Lock Screen Bypass

#146
post #103

Earlier quoted context omitted.

There's nothing OOP-specific about this bug. The bug is in too-wide variable scoping, insufficient OO really.

It calls .dismiss() expecting the PUK screen but it's a different object instead. This is the kind of thing that OOP rely on.

It has nothing to do with OOP. The design we're talking about is blind firing events at the in-focus window, and the in-focus window is being changed unexpectedly. The problem is loose coupling between the parentchild. If the child window (PUK entry/pin reset window) knew the parent's ID and fired the dismiss event at that ID this wouldn't be possible.

Even the fix they implemented is poor: The child is STILL blind-firing a dismiss event, but they just told the lock screen to ignore dismiss events from the PUK entry window. Instead, the fix should have been to stop blind-firing events at whatever happens to be in-focus. They've added more complexity rather than fixing the poor design.

Re: Accidental Google Pixel Lock Screen Bypass

#147
post #15

I was under the impression that decrypting storage actually requires the passcode of the phone, but this bug makes it look like the device is able to decrypt itself without any external input. Does anybody know more context about this? What's the point of encryption if the device can just essentially backdoor decrypt itself?

In the write-up search for the bit that says "and one time I forgot to reboot the phone". tl;dr: It's not an encryption bypass, it bypasses the lock screen once the phone has been unlocked once.

Which is equally important. Most people have their phone in that state than powered down.

Re: Accidental Google Pixel Lock Screen Bypass

#148
post #21

I 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…

Surely in this case, the second report must have added some details, since they weren't fixing the original report and i assume android doesn't just sit on lock bypasses.

Seems to me that if you report something that significantly recontextualizes a previous report (e.g. make it go from a low to a high severity), then your report shouldn't be considered a dupe.

Re: Accidental Google Pixel Lock Screen Bypass

#149
post #133
post #21

I 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…

Everyone who reports a undisclosed bug should get a share of the bounty; this incentivizes them to stick to the embargo. If too many people are reporting the bug before you fix it then you have other problems. I also start to feel that at Google's scale bounties this serious should start doubling every month.

Do you mean each new person should get a new bounty, or all reporters should split the bounty? The latter does not really incentivize much, but the former incentivizes reporters to collude with other reporters (i.e. you find a bug, tell your 40 friends to report the same bug, you get a kickback from all your friends who also reported it. $$$$).

Re: Accidental Google Pixel Lock Screen Bypass

#150
post #21

I 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…

[deleted]
Post reply on HN