171–180 of 475 posts
Security is still such a weird concept. Some times it feels like a paralyzing debilitating effort. Similar to how parents yell at you for things you should not be doing, even though it is exciting and useful .
Earlier quoted context omitted.
Okay, but fooling a biometrics sensor is not exactly a Lock Screen bypass. Has iOS had a Lock Screen bypass?
Fooling a biometric sensor is precisely a lock screen bypass, that's what the biometrics are for. By that logic the linked bug was "fooling the SIM security layer" and not a "lock screen bypass". Don't play that game, it's bad logic and bad security practice.
I see this as a different class: I can grab an unknown person’s Pixel they left in a coffee shop and get into it.
Earlier quoted context omitted.
It's also a great example why not to use iOS. If you find a hardware flaw in an iPhone and it can't be patched then literally everyone is effected. Even worse is if Apple decides you can no longer use feature/app, it's gone. Fragmentation has it's issues but centralisation is way worse.
except apple takes bug fixes and security 100x more than google does. I remember the Android nightmares of Camera1 Camera2 CameraX APIs, then bluetooth all buggy implementation with years passing by and no decent solution in place. I don't remember a single big bug by iOS
Earlier quoted context omitted.
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.
Think about that first security researcher. You literally found a Screen Unlock bypass (should be Priority #1, right?) - and Google just went and put fixing it on the backburner.
If they will put something like that on the backburner, what else are they ignoring? It isn't confidence-inspiring.
Edit: Also, knowing Google, what are the odds of your full refactor? "Temporary" fixes become permanent fixes quickly.
Earlier quoted context omitted.
The security researchers only mistake was letting Google fart around for so long. You give them 90 days, then you go public. That is the policy Google Project Zero holds other companies to, so it is only fair to hold Google to the same standard. People using their device for high risk applications need to be informed in a timely manner, and Google needs to pay a reputational price for their negligence.
If you use a Pixel for high risk applications you are a bit at fault here
Appalling handling on Google’s end here. The duplicate issue part I can understand, but why should it take two reports of a critical vulnerability to take action? Surely when the first one comes through it’s something you jump on, fix and push out ASAP, not give delay to the point where a second user can come along, find the bug, and report it. The refactor that’s mentioned towards the end of the article is great, bu…
> The same issue was submitted to our program earlier this year, but we were not able to reproduce the vulnerability. When you submitted your report, we were able to identify and reproduce the issue and began developing a fix.
I wonder if it really was the same bug or what they did wrong to reproduce it. Or maybe they just made some mistake in reproducing it.
Earlier quoted context omitted.
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.
I don't think that is as much of an issue as the ridiculous process he had to go through. Think about that first security researcher. You literally found a Screen Unlock bypass (should be Priority #1, right?) - and Google just went and put fixing it on the backburner. If they will put something like that on the backburner, what else are they ignoring? It isn't confidence-inspiring. Edit: Also, knowing Google, what ar…
Hahah, I wish that was only Google :D
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?
Earlier quoted context omitted.
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.
I do agree that in the real world, sometimes you have to settle for a less-than-ideal solution. I hope my post reads less like "those people are idiots", which was not my intent, but more like: this specific fix isn't ideal, and knowing this type of code is live in a device doesn't fill me with confidence, even if I can understand reasons for why it was done that way.
Seems to me like this impacts not only Pixel devices but all Android devices? Patch was to AOSP: https://github.com/aosp-mirror/platform_frameworks_base/comm... I don't have a locked SIM handy, but can someone please test on their non-Pixel device and confirm?