Live data from Hacker News

Accidental Google Pixel Lock Screen Bypass

bugs.xdavidhu.me

381–390 of 475 posts

Re: Accidental Google Pixel Lock Screen Bypass

#381
I have an obsession with classifying software bugs into general categories, looking for the "root cause", or more constructively, for a way to avoid entire classes of bugs altogether. I've been doing that for more than 20 years now.

This bug, if you look into the fix, falls into my "state transition" category. You can (and should) model large parts of your software as a state machine, with explicit transitions and invariant checks. If you do not, you still end up with states, just implemented haphazardly, and sooner or later someone will forget to perform a task or set a variable when transitioning from state to state.

This category is my strong contender for #1 problem area in all devices that have a user interface.

Re: Accidental Google Pixel Lock Screen Bypass

#382
post #363

Do you think there was an previous report for which this was a duplicate or were they just trying to get away without paying?

This may be a stretch but I could see the original report coming from an intelligence service.

The report might be accompanied by a request to hold off on patching it due to active use.

This would explain the desire to wait on G's side, and why it would not explain the prior report.

Re: Accidental Google Pixel Lock Screen Bypass

#384

> "Hopefully they treated the original reporter(s) fairly as well." Perhaps they should have reconsidered a bounty payment of some sort for the first bug reporter as well. Perhaps that's where the other $30k of the $100k went. This actually says something interesting about bug bounty programs in general: Given a high level of false positives, it's probably not uncommon AT ALL that sometimes it takes a couple of bug r…

> Given a high level of false positives, it's probably not uncommon AT ALL that sometimes it takes a couple of bug reports before something is reproducible or generates a high enough alert/credibility status, as seemed to have happened here. This case was not the case of eventually the same reports being taken seriously. None of them were, until the author met people working at Google in person at some event, and him…

> Security reports from proper pentesters tend to include easy to reproduce steps and if you can't reproduce it yourself from that, you can ask them to expand, since it's in their interest for you to be able to understand them, since that's how they get paid.

Fair point, but it's also in their interest to overestimate the impact of the bug they found. And, even if the reports are well written, many reports that I've seen (mostly from new gray hats) were not actually exploitable, even with aggressive poc code.

Re: Accidental Google Pixel Lock Screen Bypass

#385

Earlier quoted context omitted.

Text messages (iMessages) can be displayed on lock screens. Not sure how they do that with encryption but maybe the notification is separate.

I think for iMessage, the actual messages are sent using APNS, so the message is in the push notification itself. Thus while you can see the message itself without unlocking, any older messages that are behind the Secure Enclave are inaccessible without keys.

This is correct. For example, when I connect my iPhone to my provided work wi-fi, and I get a Tinder notification. I can partially see the message on the lock screen (once Face ID authenticates), but as Tinder is blocked on the wi-fi if I want to read and respond in the app I have to pop to cellular.

Re: Accidental Google Pixel Lock Screen Bypass

#386
post #7

How come the security model is so basic? I even think they should dismiss modal by id instead of type. As this is a highly sensitive part, I think stacking lock screens on top of the unlocked menu leaves the door open for many bugs that could unlock your device. The unlocked menu should be locked at all times, and use a flag to monitor if it’s locked/unlocked, and only flip the flag when you unlock with biometrics or…

It is android.

Re: Accidental Google Pixel Lock Screen Bypass

#387

Earlier quoted context omitted.

Do you have an Apple Watch? My phone unlocks as long as I'm nearby, wearing the watch and have it unlocked.

No Apple watch, and it can happen without the phone being connected to anything Bluetooth/Wi-Fi.

You better record and show it to people if possible.

Re: Accidental Google Pixel Lock Screen Bypass

#388
post #135

Earlier quoted context omitted.

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.

Mac seems mote secure in sleep: "If your Mac has the T2 Security Chip (recent Intel-based Macs) or uses an Apple silicon chip (M1 family and future), security is significantly improved. The Secure Enclave in both systems uses encrypted memory, and has exclusive control over FileVault keys. The Intel CPU or the Application processor (M1) never sees the keys, and they are never stored in regular (unencrypted) RAM. Due…

The most valuable information for an adversary is typically found in Ram. Like your password manager master password, browser cookies, etc. Ram can be dumped easily with the right equipment.

The only safe encryption is on a powered down device.

Re: Accidental Google Pixel Lock Screen Bypass

#389

Earlier quoted context omitted.

It works. It's basically a software brute force that works great for 4 digit pins, takes longer for longer passcodes. Other offerings are a keylogger for the pin/passwords after they "return" the device to the suspect.

How would you install a keylogger on an encrypted device without rooting it or deleting user data?

I guess you could replace the screen with one that logs taps.

Re: Accidental Google Pixel Lock Screen Bypass

#390
post #245

So basically google wanted to give this guy nothing. Then he set a hard deadline for disclosure and google managed to buy him for 70k so they could stick with their own deadline.

According to the article, the reporter had already decided before the bounty had been set that they would wait for the fix:

> I also decided (even before the bounty) that I am too scared to actually put out the live bug and since the fix was less than a month away, it was not really worth it anyway.

Post reply on HN