Live data from Hacker News

Accidental Google Pixel Lock Screen Bypass

bugs.xdavidhu.me

331–340 of 475 posts

Re: Accidental Google Pixel Lock Screen Bypass

#331

Earlier quoted context omitted.

Out of curiosity, why have you been regretting it? I've been using Pixels for quite a while now and generally been quite happy.

There are plenty of reasons that people how to spell it over the years, but none are actual red flags. For example, I think people give Google grief over making it difficult to unlock the bootloader, but the same can be said of every other vendor. In my experience, using the Pixel is good enough that I don't miss my Nokia 6.1 running LineageOS too much .

The fact they’ve had multiple critical bugs relating to emergency calls over the years is a pretty big red flag to me.

Re: Accidental Google Pixel Lock Screen Bypass

#332
post #296
post #241

Earlier quoted context omitted.

It dose imply that finding it was easier then ones where you are the only reporter; partially justifying lower rewards.

No. A bug that can be trivially found is higher likelihood of being exploited, and thus higher impact.

Higher impact; but if it is just luck you are the first of many to find it and did not invest a lot of work in its discovery is reasonable to pay less. Under "Closed as dup" system the probability is you get nothing for reporting trivially found bugs. Whilst you are still providing valuable information (that lots of people can find it).

Re: Accidental Google Pixel Lock Screen Bypass

#333
post #185
post #136

I wonder how many LEO agencies are now digging androids out of the evidence closet.

LEO already have access to locked phones via stuff like GrayKey. https://www.grayshift.com/graykey/

Why don't Google and Apple buy this product then proceed to analyze and close all holes?

Re: Accidental Google Pixel Lock Screen Bypass

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

I would indeed expect something more robust like a security state machine where not all states can transition to any other state freely. The UI shouldn't even have a say in what transitions are allowed.

The Rx model works nicely. Rather than trying to model state transitions, you model "scopes of work." So if you have something like an event listener, you would tie it to the active unlock session. When that session ends, you dispose of that "scope of work" and all work associated with it would immediately stop.

Re: Accidental Google Pixel Lock Screen Bypass

#335

    > "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 reports before something is reproducible or generates a high enough alert/credibility status, as seemed to have happened here.

What's the correct protocol to be fair to all of the original bug reporters in those situations? Split the bounty? Reward all of them with the full amount?

Re: Accidental Google Pixel Lock Screen Bypass

#336

Earlier quoted context omitted.

They ended up rewarding him with $70,000 tho

> "Due to this, they decided to make an exception" Sounds like they weren't going to at first, though, because it appeared to be a duplicate, but this was the better bug report that prompted an action. (To be fair: my hat's off to Google for even having one, and it's still shocking to me that AWS doesn't have one at all.)

AWS has a bug bounty it's just hosted by the fine black hat community instead of amazon

Re: Accidental Google Pixel Lock Screen Bypass

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

I've reported some bugs to programs on Hackerone before that were flagged as dupe and the triager did reference the original report. Chrome team does this too.

Re: Accidental Google Pixel Lock Screen Bypass

#338
>Two weeks after our call, I got a new message that confirmed the original info I had. They said that even though my report was a duplicate, it was only because of my report that they started working on the fix.

Google engineers don't seem to care much or am I being too harsh here ?

Re: Accidental Google Pixel Lock Screen Bypass

#339

Earlier quoted context omitted.

Confiscated phones often have been confiscated for months and are therefore on a relatively old patch level. If at any point old vulnerabilities come out these can be used. Keeping the phones on and connected to a charger in the evidence lockers doesn't seem like too much work.

> Keeping the phones on and connected to a charger in the evidence lockers doesn't seem like too much work. There's no way that's a standard procedure.

Why? Seems pretty intuitive to me in a time where everything is encrypted.

Re: Accidental Google Pixel Lock Screen Bypass

#340
post #332
post #296

Earlier quoted context omitted.

No. A bug that can be trivially found is higher likelihood of being exploited, and thus higher impact.

Higher impact; but if it is just luck you are the first of many to find it and did not invest a lot of work in its discovery is reasonable to pay less. Under "Closed as dup" system the probability is you get nothing for reporting trivially found bugs. Whilst you are still providing valuable information (that lots of people can find it).

Well i see where you are coming from, the point of bug bounties is to reduce risk to the company not neccesarily to reward effort of the researcher. There is a sense that a bug where you have to be NSA level of skill to find is less likely to be exploitted than a bug that every script-kiddie is stumbling upon.
Post reply on HN