Earlier quoted context omitted.
Surely you can find something more recent than five years.
I don't see how the timing is relevant here.
Do we need to remind everyone that Google made a bug fifty years ago, too?
141–150 of 475 posts
Earlier quoted context omitted.
Surely you can find something more recent than five years.
I don't see how the timing is relevant here.
Do we need to remind everyone that Google made a bug fifty years ago, too?
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…
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.
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.
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.
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).
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.
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.
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.
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…
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.
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.
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…