Live data from Hacker News

Accidental Google Pixel Lock Screen Bypass

bugs.xdavidhu.me

131–140 of 475 posts

Re: Accidental Google Pixel Lock Screen Bypass

#131
post #89
post #60

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

So you'd go out and refactor a major security sensitive component (which dates to time before your career most likely) in a span of a single month for an emergency security patch deadline?

That doesn't inspire a lot of confidence in your risk assesment and decision making.

I'd do what Google did: rollout a patch that addresses the immediate danger and then backlog proper refactors over time.

Re: Accidental Google Pixel Lock Screen Bypass

#132
post #104
post #88

Earlier quoted context omitted.

What do Windows/Mac/Linux do?

Key is in memory at all times after boot on all of those. Full disk encryption is only useful on a laptop if the device is powered down fully.

> Key is in memory at all times after boot on all of those.

I would think it would have to be while the device is mounted and OS locked, but surely if you dismount a secondary disk/container the key is purged?

Re: Accidental Google Pixel Lock Screen Bypass

#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.

Re: Accidental Google Pixel Lock Screen Bypass

#134
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…

Yeah for purposes of the reward it should only be allowed to be considered a dupe if it duplicates a disclosed bug.

I agree, but just to play devil's advocate if I discover a bug, disclose it, then tell all my friends to also file a report before it is filed they'd have to honor multiple bounties.

I, too, am frustrated that I've read far too many stories about someone reporting a devastating critical exploit and all they get is "this is a dupe" back without further explanation. Makes one paranoid that employees are working with someone externally, back dating their bug reports, and splitting the bounty.

Re: Accidental Google Pixel Lock Screen Bypass

#135
post #104

Earlier quoted context omitted.

Key is in memory at all times after boot on all of those. Full disk encryption is only useful on a laptop if the device is powered down fully.

That sounds like a security issue. Why are disk encryption keys not evicted in sleep mode? Seems like no apps should be running in sleep mode?

It is a major security issue, and one of the reasons people running around with production access on laptops is insane.

It is hard to fix this too, because almost no background desktop processes behave well when they are suddenly unable to write to the disk.

Even if you solved that, your password manager has keys in memory, your browser has cookies in memory, etc etc.

Re: Accidental Google Pixel Lock Screen Bypass

#137

I dislike Google like the next guy. And this is problem of monumental proportions. But if you came here to piss on Android and praise Apple's security, let me remind you of this: https://www.howtogeek.com/334611/huge-macos-bug-allows-root-...

More important not to come here trying to goad other users into some pointless flamewar.

Re: Accidental Google Pixel Lock Screen Bypass

#138
post #107
post #76

Earlier quoted context omitted.

> iOS has had many flaws this bad or worse Has iOS had a Lock Screen bypass in recent history?

There have been MANY such attacks against the iPhone (and every other device), most of them against the biometrics mechanisms, which tend to be pretty weak as a matter of first principles. Add to that the persistent hints/rumors/claims of gray market unlock/rooting kits available to large entities. Phones just aren't that secure, though they're much more so than they were a decade ago. Security vs. physical access is…

Okay, but fooling a biometrics sensor is not exactly a Lock Screen bypass. Has iOS had a Lock Screen bypass?

Re: Accidental Google Pixel Lock Screen Bypass

#139
post #64
post #16

Earlier 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?

Of course we won’t see analogous bug fixes on the Apple side so we can’t compare too closely. Unless you worked on this codebase :-)
Post reply on HN