Accidental Google Pixel Lock Screen Bypass
bugs.xdavidhu.me
bugs.xdavidhu.me
Of course it’s annoying to have to track the identity of “our screen” and bind that identity to event handlers, or make it accessible with context etc. But it’s necessary in anything remotely security-adjacent.
(And never assume anything is a singleton unless you add a breadcrumb comment for someone who might change that assumption on a different team!)
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 exactly is being dismissed. If this was my codebase, their approach would give me all sorts of bad vibes about additional problems lurking deeper.
The whole process and the nature of the fix doesn't inspire a lot of confidence in the security of Pixel/Android in general.
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.
Hahah, I wish that was only Google :D
You can have 2 major rewrite over 3 years or you can have a new temporary-became-permanent bug fix.
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.
But I sincerely hope that in the postmortem, there would be a larger meta-discussion around code review practices and how something like this "global dismiss" became part of the API surface to begin with, and a sincere prioritization of a larger review within the backlog. Though with everyone on edge at this time in big tech, I doubt that ends up happening :(
Their change is hardly a big refactor. This includes all the new code, all the parameter changes everywhere the function is used, and two additional test cases. This is a tiny change.
>12 changed files with 102 additions and 26 deletions. [1]
https://github.com/aosp-mirror/platform_frameworks_base/comm...
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
sounds to me like it's an optimization for introducing more tiers than what there are
Making this kind of assumption, when there are no such guards in the system itself, is exactly what leads to security issues.
If the system enforced two named singletons as security screens, so it was impossible to .dismiss() the wrong thing, then sure. But that's not how the system is, and assuming that "the number of screens is small" and "there are only 2 tiers" without enforcing that assumption with code is pretty much how the original bug was introduced.
Even still, being able to bypass the SIM lock screen would still be a bug, just not a vulnerability. Google doesn't pay bounties for non-security related bugs to the best of my knowledge, but I can't help but feel this is still not an ideal way to design the system. It likely is fine today, but as strix_varius said, these kind of assumptions are what led to this vulnerability in the first place. Vulnerabilities do pop up from time to time in otherwise well-designed systems, but this lock screen bypass never would have been present in the first place had better design practices been followed. As krajzeg said [1], The whole process and the nature of the fix doesn't inspire a lot of confidence in the security of Pixel/Android in general.
This was my experience as a dev on a team at Google for a few years. I saw a LOT of exceedingly lax treatment of correctness in the face of concurrency. There have even been multiple decisions I've seen to guess at how to fix concurrency bugs and just say "well, looks good to me, let's see if it does anything."
It's par for the course, and folks get (got? =P) paid handsomely for doing it.
You might like this post on statig, an HSM library for Rust
https://old.reddit.com/r/rust/comments/yqp2cq/announcing_sta...
I'd look very hard at places that use SecurityMode.Invalid.
If Google isn't readying a more extensive fix right now, they're going to get pwned shortly.
tl;dr: It's not an encryption bypass, it bypasses the lock screen once the phone has been unlocked once.
You’re telling me that android keeps keys in memory for its entire uptime?
There is a data protection class that is like what you're describing, but it is not used super-widely, the one most commonly used is exactly what is being described and makes data available after first unlock.
https://developer.apple.com/documentation/security/ksecattra...
What baffles me is that lock-screen is a system wide critical application and should in no way rely on this method.
iOS lock screen in theory shouldn't only respond to cryptographic validation from the secure enclave.
Yes. I've known that for quite some time, and yet I keep forgetting considering how stupid this feels [1] . Google provides "lockdown" button which is supposedly more secure (I think it's recommended for journalists?)... Well it doesn't evict keys either. Only eviction is to reboot.
[1] It feels stupid because there had been a LOT of work to move from FDE to FBE and to allow two states of data encryption and telling apps to support both of them. Doing all this work just to be able to store incoming SMS and to display wallpaper on first lockscreen...?
Full disk encryption is only useful on a laptop if the device is powered down fully.
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.
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)
"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 to this, an attacker would only be able to extract encrypted keys (which can't be decrypted), and only if the system failed to prevent the DMA attack in the first place. These protections make it a lot safer to leave your Mac asleep."
The only safe encryption is on a powered down device.
I would think it would have to be while the device is mounted and OS locked, but surely if you dismount a secondary disk/container the key is purged?
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.
The only key that sometimes gets retained at reboot is the SIM unlock.
From what I gather the more secured keys should be discarded 10 seconds after lock screen event. Lower security keys stay in memory to allow background activity.
Encryption on ios, if i understand correctly, is on a per file basis. There is thus no "mount" event to look for and it should provide no value to use a less secured key if you do not intend to run on background because decryption is supposed to happen on the fly.
PS: Also if I remember correctly pressing down the emergency sequence (holding power + volume up) discard ALL keys instantly and unlock require the passphrase as if you just rebooted. Emergency call don't need to be issued just initiated (must hold 10 sec or confirm on screen to make the actual emergency call).
If you receive a phone call while locked presumably the phone can still access the address book to display the contact name and photo?
And music playing apps can presumably access their database of music to play songs whilst the phone is locked?
The music playing is a different story
Just so you know, this is true on an iPhone, but NOT if the phone has NEVER been unlocked since reboot. If you get an SMS/call in this state, it will just show the number. It can't read the address book.
I actually find this incredible. I am familiar with iPhone security but not android and had naively assumed Google probably did a better job on the non-UX aspects.
Your camera example is not at all convincing of anything special going on, since that's also the camera behavior of other OS's (like Android) that don't purge the keys. That's far more easily implemented as just a basic app policy than some security system that yanks the file system out from underneath running processes.
It was a fresh boot, and instead of the usual lock icon, the fingerprint icon
was showing. It accepted my finger, which should not happen, since after a
reboot, you must enter the lock screen PIN or password at least once to decrypt
the device.
of course this detail doesn't take away from the rest of the report - great find xdavidhu!
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.
The issue with this is that systems have a tendency to return to their default state. If the modal is dismissed or has a bug that makes it crash or has a memory corruption, or any number of things then the system will return to the default state.
I would turn it upside down, and let the logged out state be the default one. The logged-in state is then a lockscreen that is hidden behind a session. If the session dies you are back at the lock screen. The lock screen can't be dismissed because it's always there. If the lockscreen crashes the phone locks up completely because there is nothing else there to show.
It's acceptable for failures and exceptions to decrease privilege (boot you out), but they must never increase it.
Edit: Ideally the lockscreen should also run with reduced privileges so that it literally can't start a session even if it wants to, except indirectly by supplying a password to some other system.
Failure is not lack of rigour, it's from fundamentally flawed architecture.
"When a fail-safe system fails, it fails by failing to fail-safe." (from the wonderful "Systemantics").
Yes, one should definitely try to fail safe. But managing your states and state transitions explicitly and carefully is a good way to avoid these kinds of bugs.
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 with password.
If the flag is locked, then the whole screen is black and can’t have any interactivity via touch, mouse, kw…
This way is more robust, so even if you manage to bypass the stack of lock screens, you end up with main menu locked.
The other question is, why would background tasks be permitted to call dismiss at all? I can imagine a scenario where you get a malware app installed using whatever method. Then when you get physical access to the phone, you send a notification to the malware app. The malware app in the background calls dismiss on every possible type several times to unlock any possible security screens.
There should be some sort of lock/flag/semaphore that is held by the current top level security screen. Dismiss should only be callable by whatever process has a hold of that. Dismiss calls from anyone else should not only be denied, but processes that make such calls should be blocked, quarantined, marked as suspicious, etc.
And you can only move down one tier of unlocking at a time. Unlocking SIM PIN moves you down one tier to phone PIN screen.
It almost sounds intentional, but at the very least like a very sluggish approach to security.
Even more robust would be to switch that flag off by using the password or derived password from biometrics.
Project Zero only gives vendors 7 or 90 days before disclosure...
The short version: Project Zero won't share technical details of a vulnerability for 30 days if a vendor patches it before the 90-day or 7-day deadline. The 30-day period is intended for user patch adoption.
https://googleprojectzero.blogspot.com/2021/04/policy-and-di...
Google should have given Mr. Schütz $200,000 alone for not revealing it.
I can only hope this is a singular case or else the argument "yeah we collect your data but we also keep it safe!" falls pretty quickly.
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?
Unless of course you can do this long after it locks…
> "Hopefully they treated the original reporter(s) fairly as well."
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?
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 showing them the issue and then persisting.
Different than "Ops, we received a couple of requests, better look into it" and more like "this guy won't stop bothering us about it, probably should look into it".
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.
Probably at Google size it's impossible to have a team large enough to deal with all the reports.
I knew and accepted that it wouldn't get new features and major android versions, but to not even get security updates, after only three years?
So my options are: live with the piece of technology in my life that is both the most vunerable to physical security issues and has the widest access to my critical information no longer getting active security updates, attempt to root it and install my own build (is cyanogenmod still a thing?), or throw a working piece of complex technology in the trash?
Amazing
The most recent Pixels get a few extra years of only security updates after regular updates run out. So at least they have improved the policy somewhat now.
It would be great if Google went ahead and fixed this problem in particular for more devices, though.
EDIT: I stand corrected, they stopped support in September. :(
Can you tell me where to find release informationen for the Pixel 3/3a? I see that there's a new version from Nov 11 (only) for the 3 series but the most recent changelog is from Nov 10 (https://grapheneos.org/releases#2022111000) and I don't see any information there regarding the lock screen bug.
Very disappointed with Google here - even though I lost a lot of trust in them in other areas, I still rated their security stance as excellent, especially on their own phones.
* The security screen "system" works as a stack, and the individual handlers for them don't actually have a reference to their own security screen. That seems like a terrible design; this design caused this bug, and the fix for it feels like a band-aid that could have unintended consequences (and thus new security implications) in the future. The handler for the security screen should have a reference to the security screen itself (or an opaque token or something like that), so it can be sure it is only dismissing its own screen. Passing a "security screen type", as the new, "fixed" code does, is not specific enough for this kind of code, and still seems unsafe to me.
* I'm a bit confused as to how this could unlock a newly-rebooted phone. Isn't the user data partition unmounted and encrypted? How could this partition get decrypted if the user doesn't get the opportunity to enter their device PIN, which should be needed to gain access to the partition's encryption key? I guess maybe it isn't decrypted, and that's why the system got stuck on the "Pixel is Starting" screen. Still, pretty concerning.
Meanwhile, my Pixel 4 still only has the October 2022 security update, claims there is no update waiting, and is presumably still vulnerable.
He explained to me that he was actually working in the hardware division at Google and that the team that he was managing was responsible for some parts of the Pixel's design. But he added that he had never actually talked with anyone out "in the wild" who owned a Pixel or made a positive attempt to buy one. He went on to explain that most of his team didn't use a Pixel either - they were all pretty much using iPhones, but some were even using Samsung devices.
I understand that this was someone from the hardware team and it doesn't necessarily reflect on the people who work on the Android OS, but I feel silly for not having taken what he said into consideration when I finally bought a phone. If the people working on a device don't even want to use it themselves and can't figure out a compelling reason for anyone else to use it, shouldn't that have been a strong signal to me that I shouldn't have selected it? But I did, and I've been regretting it since. Great camera though.
especially the bit with samsung devices, i've had the misfortune of setting up a samsung phone for a family member and the amount of crap on those is just unbelievable
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.
It's not so much that as it is buying an unlocked Pixel and RMA'ing it when hardware problems happen only to receive a locked phone in return. This is the sort of thing that makes people angry.
A general frustration with the entire Pixel line is the lack of video output options. It's basically Chromecast or GTFO - no Miracast, no USB-C video. It's kind of sad when an Android phone has worse compatibility with generic hardware than iPad! And the most annoying part is that Google deliberately removed all these at some point in the past.
You could have just as likely been listening to hot air from a random individual. Perhaps an Apple store employee with an axe to grind.
TBC I also agree that you should dogfood things you build, especially in the cruisy world of software development where if you really hate what you work on you can just go somewhere else. It is a bad look in the media though
It's kind of a post-hoc realization that I should've used his admission to me as a reason to second guess a purchase on a device which I've come to discover: has a stock messenger application that fails to sync message receipt times, that gets very hot to the touch, drops cell phone tower connections until rebooted. And, as the article we're replying to points out, had a lock screen bypass bug that wasn't fixed for months.
(I actually do have both and definitely prefer the Pixel -- especially the cameras on the Pixel are amazing in low light, but it's a bit annoying how the official Gcam app seems to expect that Google photos is installed.)
How funny is it that the best way to de-Google is to buy a Google device, and that Apple is incredibly prescriptive about knowing exactly who you are, connecting to wifi, and getting your purchasing on file before you can even get through the initial setup on an iPhone.
The one thing I like about iPhone over Android is that the animations are a bit nicer and more polished, and the stock color scheme is pretty bright (but awful at night), and everything else about Android seems to be better.
It's not even just that iMessage segregates non-iPhone messages by color. It screws up video and group texts.
Just use another app if you want. They already provide compatibility with SMS. What more do you want?
As [w]cdma is shut down in preference for 5g and LTE, Pixels (model 3 and above) will be more desirable for users who wish to run Android without Google on modern cellular networks.
I am one such user.
Supposedly, two different implementations of VoLTE exist in AOSP, neither of wich are used outside Pixels (if I understood previous discussions correctly).
I have received and read your response regarding my apology to you. I'm concerned that I may have upset you more than I realised.
My grandfather once told me not to take in too seriously random strangers comments. I try to live by that advice, wether it's comments from internet strangers, or, for that matter, customers at the phone shop.
This is of course not an advice from me to you. But I thought I'd share it with you in case you might find it useful too.
DBNR,
R. Root
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 with other programs almost everything gets closed as "dupe" which is just dispiriting.
In any case, if something this serious is a duplicate then there's the suspicion it went unfixed for long enough to be independently discovered and reported which is worrying.
Only if it has been fixed and is allowed to be talked about, else malicious actors will submit speculative bugs to see if they catch anything.
Even so, surprisingly many researchers disclose a bug after setting a reasonable fix deadline, risking to forfeit compensation. Kudos to them!
Person A finds the issue, reports it.
Then Person A secretly tells Person B about it (with no apparent connection), and Person B reports the same issues a few weeks later, but with apparent different code/description to look ever so slightly different.
No system is perfect.
I, too, am frustrated that I've read far too many stories about someone reporting a devastating critical exploit and all they get is "this is a dupe" back without further explanation. Makes one paranoid that employees are working with someone externally, back dating their bug reports, and splitting the bounty.
If too many people are reporting the bug before you fix it then you have other problems.
I also start to feel that at Google's scale bounties this serious should start doubling every month.
Having worked with but bounty programs, I can guarantee this would be abused to no end. Reporters would enlist their friends and family to submit as many duplicate reports as possible.
There are a lot of good security researchers out there doing work in public, but bug bounty programs also get flooded by people looking to game the system in any way possible.
Seems to me that if you report something that significantly recontextualizes a previous report (e.g. make it go from a low to a high severity), then your report shouldn't be considered a dupe.
I find it rather convenient that the "detailed support matrix" is only available for current customers only, seems to me like the actual amount of supported devices/operating systems would be limited to things such as outdated Samsung Galaxy phones and similar.
Since the pin/password isn't actually the encryption key and is instead just the code that is provided to the security module/TPM on the device, I fail to see how this can be bruteforced. Unless there is also a magic hardware backdoor in Android phones, but in that case why would there need to be private companies and how would they even have access to this.
There's no way that's a standard procedure.
Police can't really pop out e-sims, that means the police needs to keep the phone in an RF proof bag/work in an RF proof room.
If you are at all familiar with the histories of jailbreaking, previous exploits, and the gray unlock market, it’s unreasonable you would not consider this this to be the default case.
If that's the case, it's possible that this attack may still work from a fresh boot for unencrypted devices.
say password > mfa1 > mfa2 > done
and as each steps complete what's the next security steps for this particular user's configuration and simply allow just that transition. Once we are at the done state the authentication is marked as successful.
Not storing auth state in UI (regardless of any MVC concern) and allowing only a very narrow allowed state of transition seems like a trivial design choice. I assume google has no shortage of people for security focused design.
The UI stack being created together and dismissed rather than created/called on demand as state transition happens also seem a very wired design. Perhaps I don't understand the reason cause I'm not an android programmer.
> We typically do not reward duplicate reports; however, because your report resulted in us taking action to fix this issue, we are happy to reward you the full amount of $70,000 USD for this LockScreen Bypass exploit!
Lots of mixed feelings just reading this, but at least in the end it seems like a positive outcome for everyone.
The refactor that’s mentioned towards the end of the article is great, but would you not just get a fix out there as soon as possible, then work on a good fix after that? For a company that claims to lead the way in bug bounty programs this is a pretty disappointing story.
I would personally be highly suspicious of a security flaw being a duplicate though. It's can be a very convenient excuse not to pay the bounty.
> 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.
> I did something weird after putting in a new PIN, and I was able to access my home screen without my password, but I'm not sure of the exact steps I did
then that's not really a duplicate. If the original bug report doesn't have enough information to recreate the steps, the second one is the only real bug report.
> 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.
I'm actually very suprised it's coded the way it is, a stack of screens that are dismissed over the top of each other. I would expect one very specific boolean/flag bottleneck that says if the device is locked or unlocked. Then a list of actions that can be taken when locked (such as sim pins, emergency calls etc) and then unlocked (such as everything else). And that flag can only be flipped by unlocking the phone. This set of screens on top of the phone that can be dismissed is very surprising to me.
Does anyone know how the iOS lock screen works? Is it the same way?
*Edit: ̶H̶o̶w̶ ̶t̶o̶ ̶s̶t̶r̶i̶k̶e̶t̶h̶r̶o̶u̶g̶h̶?̶ - cheers
̶t̶e̶s̶t̶
This is going to be one if the uncounted casualties of a downturn in tech and layoffs. When the organization is in turmoil, and the tenured folks have left out the backdoor, security flaws are going to remain open for a lot longer
I agree, my commentary is more on tech as a whole, which is in turmoil rn.
If I had experienced the same situation I'm sure I wouldn't have noticed that something was wrong. Kudos for noticing that and thank you for documenting it for everyone to understand :)
Google engineers don't seem to care much or am I being too harsh here ?
> "Insert a SIM card > With your phone off:"
[0] https://support.google.com/pixelphone/answer/7086887?hl=en
Many phones used to have the SIM under the battery (back when it was commonly removable), ensuring you couldn't remove it without powering the device off first.
https://support.google.com/nexus/answer/4457705?hl=en#zippy=...
Pressure on disclosure date until Bug bounty, then relent.
https://support.google.com/pixelphone/answer/4457705?hl=en#z...
This is one of the reasons I recommend the most recent lowest-priced iOS device you can afford to family and friends who don’t upgrade often.
My grandfathers iPhone 6s is just now going EOL after 7 years. Apple is a little inconsistent with updates for prior iOS versions but it still received the iOS 15 security update.
It wonder if iPhones end up being cheaper because of the extended support?
Google's hardware support IME is a shit show. They need to stop spending all their time playing with ML tricks that nobody uses outside of ads and keynotes (aside from normal camera stuff), and start listening to customers and addressing bugs and missing features that even the mid-tier chinese phones have rolled out.
I'm buying a oneplus next time around and never looking back, idc if google's new chip gives me 2x battery life at the same price, it's not worth the frustration.
I was planning to switch from oneplus to pixel for this reason.
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 .
[...]
> 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. I decided to wait for the fix.
I have gone through similar trepidation.
What were you scared of?
I should have asked "at what point did you decide that the wait outweighs the risk?"
That is, at what point wait becomes too long, and is worse?
I didn't have one yesterday night. Things that work: the classic paper clip, a small staple for paper sheets, the inner metallic wire of twist ties (or whatever they are named.) I discovered the latter yesterday.
No jail time for simply telling the truth about a discovery I made on my own time.
https://www.vice.com/en/article/3kxy4k/high-tech-japanese-ho...
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.
Ship it mentality much?
I will try to exploit before and after downloading.
For one generation Google I believe never shipped the ability to unlock your phone with your face. Despite having all the hardware on the phone, it just didn't have the feature.
This was a serious feature deficit viz a viz the relevant iPhone at the time.
The gossip was, the feature was finished, completely.
Had to be ripped out after external pen-testing bypassed it with Facebook photos.
They have many, big, problems.
IIRC, the iPhone uses not just a photo from the selfie cam, but adds infrared to construct a sort-of-3d-ish depth map of your face as well - that is what defeats a simple attempt at unlocking with photos.
Now, the really interesting thing to research is if a silicone molded face mask could be used to fool the iPhone into unlocking. Photos or videos of the subject in multiple angles should be enough to create a decent enough 3D face copy.
https://9to5mac.com/2019/12/16/3d-mask/amp/
Muscle movement is also now necessary so it’s pretty difficult to circumvent
Did Pixel phones really have a frontal lidar?
Predictably, I never bought a Pixel 5 or 6 or 7.
It had 2xIR cameras, flood illuminator and a dot project for that purpose. Soli was a gimmick on top of that, so it would enable that hardware above when you were reaching with your hand for the phone.
In my case it was a gimmick because I don't see much difference between face unlock times when I reach for the phone and the most useful feature for me (swiping to change music) was working also when my windshield had wipers working.
I dream of a Pixel with normal face unlock (like in Pixel 4, not the crippled on in Pixel 7) but without Soli.
I can't believe that they ditched it after just one generation, now I'm stuck. And only reason to upgrade would be a Pixel that has photos >12mpix (not just the sensor).
6 was rumored to have it, but it was never delivered.
6 and 7 are equivalent hardware-wise for face unlock: neither has the sensors to do it in a highly secure manner. 7’s face unlock therefore doesn’t give you access to the most sensitive stuff, like bank accounts, requiring supplemental, secure authentication, such as fingerprint.
[0] https://www.androidauthority.com/face-unlock-android-4-0-ice...
[1] https://www.androidauthority.com/android-jelly-bean-face-unl...
[2] https://source.android.com/docs/security/features/biometric/...
There WAS a rumor about Pixel 6, but it doesn't have any special face unlocking camera. Pixel 7 does support face unlock without special hardware with caveat that it's less secure.
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.
I smell a fair hint of victim blaming here.
Why is that a bad thing? You should absolutely blame and hold the victim responsible and accountable for their part.
Also, this is an interesting discussion in general. If someone forgets to lock their door and a thief gets in and robs them, do you think it's fair to "blame" the person who forgot to lock their door? Or do you think that maybe we should recognize that 100% of the blame should be on you know, the person doing the robbing?
No, but let's say they've bought from a manufacturer who is not most well known for their lock mechanisms, wouldn't it be the user's responsibility to find a better alternative? You're to be held accountable for your part.
You're making the assumption that the average person thinks Google employs the “most well known software developers on the planet” – that's your subjective take, not anything close to common knowledge
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 they can afford.
Security issues like this can be life or death, and security researchers must sometimes -force- companies to treat them as such.
Has iOS had a Lock Screen bypass in recent history?
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.
https://cellebrite.com/en/cas-sales-inquiry/
Zerodium brokers sales of iOS FCP Zero Click for $2m. I expect they sell to people like Cellebrite who can make a profit selling expensive unlocks and keeping the vuln secret.
https://www.zerodium.com/program.html
All phones are security shit shows. It is just a game of how well known this months exploits are and how much someone has to gain by targeting you.
Disclosing on time is a way to force companies to fix the bugs, and to get a major social capital boost that can be used to get a return on the time investment.
Personally I love when companies try to call my bluff. Great chance to educate the public on why they should not be trusted.
Here's another example of a critical vulnerability in GCP that Google sat on for 9 months: https://github.com/irsl/gcp-dhcp-takeover-code-exec
Meanwhile, the Google engineers, who were skeptical to begin with, show some signs of impatience, which you become acutely aware of, and get even more nervous. While you're shaking and pressing too hard, you ultimately stab through your hand and now there is blood everywhere. You try to hide it at first and play it off but blood is getting all over everything and a few drops hit the floor. You try with the needle some more but the blood is too slippery and you accidentally wipe some across your forehead to top it off.
It's been 25 minutes at this point and 2 of them decide it's not worth their time any more and leave, which you also notice, and begin to realize your chance is slipping away and you're spiraling internally.
Eventually, someone produces a bandaid, but your hands are shaking too much and they have to pitifully put it on for you. While contemplating if you are actually a grownup or just a large child, you realize you started sweating a lot and you forgot to put on deodorant because you're traveling and left it at home. You smell your own awful fear creeping up through the neck of your hoodie, hoping that the guy who is fixing you up doesn't notice.
Crazy intrusive thoughts start to cross your mind as you pick up the needle again, but a woman snaps you out of it with "would this work?" holding up an earring. You kick yourself for not thinking of it earlier when you actually noticed her earrings during earlier chit chat. "I'll try not to get blood on it," you chuckle, but no one really laughs beyond a murmur.
In seconds, you pop the sim out and swap it, quickly demo the vulnerability speaking faster than Eminem spitting Rap God. Everyone is quiet for an eternity (1.5) seconds as pressure builds, until the engineer who handed you the earring says "holy shit" and runs off without her earring. Those in the small crowd turn to each other to discuss, taking the pressure off you as you go totally cold from the sweat that you now realize has trickled all the way down your leg.
The rest of the day you are high as ever, like the feeling of headiness after eating an extremely spicy order of hot wings or curry.
It's also possible that the code is too complex to understand fully which is a requirement for a correct operation. Bugs happen, but I've seen way too many cases where complexity and lack of understanding led to surprisingly bad outcomes.
The login process should have the highest amount of scrutiny.
Even if you did somehow get that much code regularly externally audited, there are piles of random binary blobs with root access supplied by cell carriers and chip vendors Google blindly includes in the vendor partition and a backdoor or bug in any one of them can burn it all down.
I abandoned the project, and stopped using smartphones entirely.
The only sane engineering effort that gives me hope for a trustworthy mobile device at this point is Betrusted. https://betrusted.io/
Lovely. My Pixel 4 got it's last update in Oct.
In this case though, you would hope Google release an extra patch for the Pixel 4, they knew this bug was there and a fix was in the pipeline.
For context Project Zero used to have a strict 90 day disclosure policy, but updated it to "90+30" a year or so ago to give people more time to patch. Google took at least five months to resolve this issue, and it's possible they took longer than that because we don't know when the first report was actually made.
Basically it seems like their bureaucracy is structured so that no one has an incentive to actually address this. Everyone at the company acted like they would rather this issue not even exist, rather that address a critical flaw that makes locking essentially not work on the Pixel.
This gives us a look under the cover of what's important at Google, and it seems like security is a clear subdivision of marketing in this case.
Yes, that's how you start thinking after reading Yasha Levine's Surveillance Valley.
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?
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.
Instead, you should sell the exploit on the exploit dealers sites. This is easily worth $300-500k
But not now. And you have the 'privilege' of being dicked around with people googling you.
If these companies try to cheap people out of what bounties they offer, then they need reminded that they're not the only game in town that'll pay for exploits.
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-...
Do we need to remind everyone that Google made a bug fifty years ago, too?
(This happened again with Ventura).
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).
Oh, the exceptional safety of object oriented programming!
Even the fix they implemented is poor: The child is STILL blind-firing a dismiss event, but they just told the lock screen to ignore dismiss events from the PUK entry window. Instead, the fix should have been to stop blind-firing events at whatever happens to be in-focus. They've added more complexity rather than fixing the poor design.
Since the author effectively tells you how to do it, all you need to do is find a pixel 4 or older and you’re golden.
Fragmentation has it's issues but centralisation is way worse.
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
Much more lukrative to sell your exploit on the black market.
Besides the whole "can't install user software" issue.
Bugs are inevitable and so the difference is support duration and speed.
What seems to matter more is how many auditors are actually digging in and how aggressively secure coding practices are applied. It certainly doesn’t seem like there’s a big difference between the two in terms of security but Android has more people using old software because their manufacturer didn’t want to ship an update.
“many eyes make all bugs shallow” should have always been seen as horse shit. It has the same level of evidence as other linuxy "truisms" like "worse is better" and "everything as text or a file is best"
Heartbleed and shellshock sat right in public eye for quite some time, but it turns out nobody was watching.
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 a photo than Android.
For anything security related, like banking etc. I use iPhone.
Of course your mileage may vary.
> all you need to do is find a pixel 4 or older and you’re golden
Its worse, it works on most Android phones without the latest security patch, not just Google phones.