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

211–220 of 475 posts

Re: Accidental Google Pixel Lock Screen Bypass

#211

Post by tinus_hn »

izacus wrote: post #114
gcr wrote: post #64

Earlier quoted context omitted.

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?

That's not really true at all - you can of course unlock your iPhone without entering PIN for every screen lock which should give you a clue that keys for disk encryption generally aren't purged when iPhone is locked. Some keys are, but not the ones that are the issue here. I've even seen conditions where iOS devices reboot and still retain keys.

If you unlock the screen using Face ID the OS gets the keys from the Secure Enclave which, depending on the model, does the face recognition itself or using the normal processor in some kind of secure way. Just like if you unlock the phone using the pin code, the OS gets the key from the Secure Enclave which makes sure it’s not easy to brute force. The PIN code is not the key itself of course.

The only key that sometimes gets retained at reboot is the SIM unlock.

Re: Accidental Google Pixel Lock Screen Bypass

#214

Post by rex_lupi »

THIS IS ABSOLUTELY CRAZY! I have personally tested this on my Non-pixel Android 12 device and it works. My findings: - The exploit works even on first pwd input screen on boot. however, the filesystem is still encrypted and cannot be accessed by any means (ADB/MTP). launcher does not load fully. but settings and other things accesible from notification panel can be launched (BT/Hotspot etc). you can get list of installed apps and many other sensitive informations that are not stored in /data/media/0/. - adb can be connected. shell can be launched but data partition is not accesible. - mtp initializes but does not load. I guess although one cannot access the user data, the ability to access/control other parts of system potentially exposes a huge attack surface.

Re: Accidental Google Pixel Lock Screen Bypass

#215

Post by openplatypus »

jagged-chisel wrote: post #122
openplatypus wrote: post #121

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

Surely you can find something more recent than five years.

Software is written by people and organizations made of people.

Security issues are precisely because of that.

Rather than focusing on bug we ought to focus on how it was handled. And, in this case it was obviously poorly addressed.

So let's focus on that, not on "iOS/MacOS is superior" because it is not (it is not free from flaws).

Re: Accidental Google Pixel Lock Screen Bypass

#216

Post by cr4nberry »

krajzeg wrote: post #89
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…

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…

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

Re: Accidental Google Pixel Lock Screen Bypass

#217

Post by [deleted] »

rex_lupi wrote: post #214

THIS IS ABSOLUTELY CRAZY! I have personally tested this on my Non-pixel Android 12 device and it works. My findings: - The exploit works even on first pwd input screen on boot. however, the filesystem is still encrypted and cannot be accessed by any means (ADB/MTP). launcher does not load fully. but settings and other things accesible from notification panel can be launched (BT/Hotspot etc). you can get list of insta…

[deleted]

Re: Accidental Google Pixel Lock Screen Bypass

#220

Post by sgt »

vardump wrote: post #108
sgt wrote: post #53

Earlier quoted context omitted.

Besides my opinion that iOS is just simply better built and more secure, the biggest difference for me comes down to the UI. Maybe my mind is just wired more for iOS, but subjectively I would say that it's by far the superior user interface. Snappy as hell too.

I've used both for about as much for quite some years, both OS phones are always with me. I'd say iPhones used to be snappier maybe 5+ years ago, but nowadays I grab an Android phone if I want something to be done fast, say perform a web search. Two exceptions: 1) Android phones are stuttery disasters for some time after booting up. No big deal, since I rarely power my phones off. 2) iPhone is usually faster to snap…

Love that. Mileage may vary. How long have we computer people said this?
Post reply on HN