Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accidental Google Pixel Lock Screen Bypass

bugs.xdavidhu.me

Post reply on HN
Print view View original

161–170 of 475 posts

Re: Accidental Google Pixel Lock Screen Bypass

#161

Post by joezydeco »

btown wrote: 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…

Am I reading this right? This reads like the presence of a UI element holds the unlock state of the phone?

Re: Accidental Google Pixel Lock Screen Bypass

#162

Post by metalforever »

daneel_w wrote: post #52

Every once in a blue moon when I pick up my locked iPhone (which auto-locks in just 30 seconds) and engage the home button just as the screen comes alive from the gyro sensing movement, it unlocks on its own. It just flashes the PIN dialog and slides right onto the home screen. I don't use Touch ID, and never stored my print with it even once to test the feature/hardware. It's been happening ever since iOS 11, with b…

Yeah I’ve seen this too.

Re: Accidental Google Pixel Lock Screen Bypass

#163

Post by MerelyMortal »

pstation wrote: post #123
phreack wrote: 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.

This was kind of my experience with reporting a bug to Google as well. Some years ago I managed to upload a SWF file to "google.com" which allowed me to do an XSS and access anyone's gmail, contacts, etc. I reported it and they just initially never responded and I had to constantly follow up. It was seemingly a simple bug to fix but it took them a couple months and they eventually only paid $500. Being able to exfilt…

Do you mind sharing a weite-up about that bug?

Re: Accidental Google Pixel Lock Screen Bypass

#164

Post by [deleted] »

photochemsyn wrote: post #158

It's somewhat interesting that there was never a major public pressure campaign by the FBI to force Android phones to be backdoored, as there was with Apple. Maybe this was the tactic used by law enforcement (and others most likely) to unlock Android phones? Maybe Google knew about it and that accounts for their stalling on providing a fix? Yes, that's how you start thinking after reading Yasha Levine's Surveillance…

[deleted]

Re: Accidental Google Pixel Lock Screen Bypass

#165

Post by sofixa »

photochemsyn wrote: post #158

It's somewhat interesting that there was never a major public pressure campaign by the FBI to force Android phones to be backdoored, as there was with Apple. Maybe this was the tactic used by law enforcement (and others most likely) to unlock Android phones? Maybe Google knew about it and that accounts for their stalling on providing a fix? Yes, that's how you start thinking after reading Yasha Levine's Surveillance…

For what it's worth, all the famous either unlocking or remote hacking sagas (like Pegasus) have mostly been around iPhones. Which either indicates that Androids are so trivially hacked that nobody is even talking about it (sounds a bit doubtful, IMO, hopefully), or that the majority of "targets" have been using iPhones. It has certainly been the case with all the hacked journalists I remember.

Also the Android landscape is much more fragmented, so maybe a vanilla Android exploit might not work on MIUI, so hackers don't bother when it's "easier" to develop for iOS, which has the majority of juicy targets anyways?

Re: Accidental Google Pixel Lock Screen Bypass

#166

Post by erwincoumans »

lrvick wrote: post #135
erwincoumans wrote: post #124

Earlier quoted context omitted.

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.

Sleep mode could suspend all activity? You could encrypt all memory before sleep?

It doesn't seem unsolvable, as long as sleep (closing lid) suspends all activity.

(lock with background activity is different, lets discuss the sleep case)

Re: Accidental Google Pixel Lock Screen Bypass

#167

Post by sofixa »

mwint wrote: post #76
lrvick wrote: post #67

Earlier quoted context omitted.

iOS has had many flaws this bad or worse, so what would you have people use? I agree current gen smartphones should not trusted for high risk uses but the reality is, they are. There are staggering numbers of people using their phones for banking, crypto trading, or to transmit sensitive information that could collapse markets or start wars. Also consider not all journalists or dissidents get a choice in what phone t…

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

It has had multiple remote, zero click remote code execution exploits so it's actually worse?

Re: Accidental Google Pixel Lock Screen Bypass

#169

Post by duxup »

photochemsyn wrote: post #158

It's somewhat interesting that there was never a major public pressure campaign by the FBI to force Android phones to be backdoored, as there was with Apple. Maybe this was the tactic used by law enforcement (and others most likely) to unlock Android phones? Maybe Google knew about it and that accounts for their stalling on providing a fix? Yes, that's how you start thinking after reading Yasha Levine's Surveillance…

I suspect pressure to backdoor something or similar requests in the US are often (not always) one off adventures that collectively look like something larger, rather than say a policy where someone goes to companies and make general requests continuously like some regulator going about his business.

The effect may end up being widespread, but the actual access and details are more uneven / look strange to us because of how spotty it is at times.

At least in the us I suspect that law enforcement, the typical surveillance organizations may even try to cast a wide net at times, but I think they're more transactional in their intent / look for what they need for a given person, people, case and less so to keep an eye on where a random citizen comes and goes.

That's not a justification for any of it, but I think it might explain why folks don't always find the 1984 they're looking for / expect in the end result.

Re: Accidental Google Pixel Lock Screen Bypass

#170

Post by gausswho »

Someone1234 wrote: post #146
vitiral wrote: post #117

Earlier quoted context omitted.

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 parent child. 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-…

Maybe I'm misunderstanding what you refer to as blind-firing, but the change is to require a target ID from dismiss calls. That's regardless of focus then right?
Post reply on HN