A fun and interesting read. But it is frustrating to hear that such a major security bug was ignored until a happenstance meeting with Google engineers.
It read like the payment came only when disclosure was imminent. Google basically extorted themselves into paying it to encourage pushing disclosure out a couple months.
Yeah, they tried to set up a call to dissuade him but he stood by his decision. Then only 3 days before the disclosure deadline they decided to pay out.
Not testing it right now, but my understanding is, that the issue is technically for every device, but the specific condition (putting the lockscreen on top of the secure screen stack right before `.dismiss()`-ing) is a Pixel software bug.
Very interesting. To summarise, I think the issue is that the phone gets itself into a state of waiting for a locked SIM to release itself before it unlocks the phone - the problem being the attacker could have their own pre-locked SIM they can hotswap in that of course they know the code for, and this will erroneously also unlock the phone.
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.
I was also thinking they should only dismiss by ID instead of type.
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.
I think an even better approach would be to have the concept of fixed tiers of locking combined with evicting the decryption key for any Lock Screen above the basic PIN.
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.
I'd go for one screen with a queue of prioritized unlocking tasks which need to be completed successfully one after the other. These tasks could get the chance to hand over a fragment which the screen embeds and presents to the user, in order to properly modularize the tasks.
I was thinking that if I would have to code this, at least once this issue would cross my mind, the question of "what happens when there are multiple screens stacked" and how it should get handled properly. This is what meetings are there for, to discuss such issues.
It almost sounds intentional, but at the very least like a very sluggish approach to security.
I was under the impression that decrypting storage actually requires the passcode of the phone, but this bug makes it look like the device is able to decrypt itself without any external input.
Does anybody know more context about this? What's the point of encryption if the device can just essentially backdoor decrypt itself?
It seems to me this bug appears when a phone is booted, unlocked (and decrypted) once, and then locked again, but the decryption key still stays in memory.
This is virtually always the case with these kinds of vulnerabilities on smartphones. Security researchers often say whether an attack or vulnerability is possible "before/after first unlock" in reference to the fact that the security is a totally different story if the phone has been unlocked/decrypted since last boot.
It didn't work on a fresh reboot, so presumably, it functioned like you're describing. But, when he swapped the sim live, without the reboot, the phone was already running with the key in memory.
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?
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.
> You’re telling me that android keeps keys in memory for its entire uptime?
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...?
If you fully hibernate to disk where it encrypts the memory snapshot to your FDE key, then you are good to go but that is not locking that is turning the computer off.
"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 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.
On Linux this is adressed by systemd-homed, which encrypts at least your home partition in sleep mode. Attackers could still try to manipulate the rootfs & hope the user doesn't detect it before using the device again.
As long as that secondary disk uses a different FDE key and you manually unmount it. This is easily done with LUKS on Linux but YMMV on other operating systems
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.
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).
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.
> If you receive a phone call while locked presumably the phone can still access the address book to display the contact name and photo?
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.
Do you have any more details about how that works on iphone? It seems very hard to believe, given the complexity and diversity of background apps on iphones, some of which access huge data that would be impossible in system memory (e.g. offline GPS/navigation apps). For example, Google Photos can send the full photo library on the phone, even if large, to the cloud while the device is locked.
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.
Nonsense. If that was true then things like backups and cloud sync couldn't happen when the device is locked. But of course they do, meaning the keys are still sitting there freely accessed by the CPU, along with all the data on disk.
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.
The passcode is required to get access to anything the first time you start the phone, for the reason you mention, and after that the password is retained in the trusted execution environment. This way apps can continue to function in the background while the phone is locked and you can unlock with alternative methods like fingerprints or face recognition.
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.
i was surprised to read this part too. assuming that the author's version of the events are accurate here, my best guess is that the device had not fully powered down, and was in either a low-power/hibernate or find-my-phone mode, where portions of the security subsystem were still powered, hence the device-unlock PIN was still cached. i don't otherwise see how else a fingerprint alone would allow for the device to be unlocked on cold boot.
of course this detail doesn't take away from the rest of the report - great find xdavidhu!
Doesn’t seem like a full unlock, see the next paragraph: “After accepting my finger, it got stuck on a weird “Pixel is starting…” message, and stayed there until I rebooted it again.”
I can't believe this is not a "drop everything and get it fixed ASAP" bug. This makes me think there's probably tons of other similar bugs out there being exploited right now even with disclosure.
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.
> This was a serious feature deficit viz a viz the relevant iPhone at the time.
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.
Incidentally, I said to myself I would buy a Pixel 5 if it had Soli as well because it would show that Google was becoming serious about supporting features for more than 1 generation.
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).
Pixel is on generation 7. Only two supported face unlock: 4 and 7.
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.
Android introduced face unlocking in 2011[0]. It used the regular front camera and hence had no depth information, which makes it vulnerable to photos[1]. It was removed in Android 10, when a new face authentication interface[2] was added. Face unlocking without specialized hardware such as what iPhones have is not secure.
I'm not really sure what you're talking about - the only generation that had LIDAR was Pixels 4/4XL and those shipped with face unlock.
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.
yeah right? after the article mentioned that he waited 2 months, I was already shocked, then he mentioned 3 months, and so on.. sometimes it's just annoying to report something really important and still you don't get enough attention.
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.
What a weird argument. So if the law enforcement of your country uses this technique to unlock your phone without your permission(or you know, some criminal does that), that's your fault for using a Pixel phone? You should have known better than you know, buying a phone from one of the largest software houses on the planet?
So let me rephrase my question - what part of the blame should be assigned to the victim here, if their "fault" was buying a phone made and marketed by one of the largest and most well known software developers on the planet?
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?
> 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?
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 that there's not any significantly better phone options, but no I would not place 100% of the blame on the robber. When we're talking about possessions, theft is a reasonably foreseeable consequence and not an outrageous action, so the owner can get a small slice of blame.
iOS has had many flaws this bad or worse, so what would you have people use?
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.
There have been MANY such attacks against the iPhone (and every other device), most of them against the biometrics mechanisms, which tend to be pretty weak as a matter of first principles. Add to that the persistent hints/rumors/claims of gray market unlock/rooting kits available to large entities. Phones just aren't that secure, though they're much more so than they were a decade ago. Security vs. physical access is an extremely hard nut to crack, it's only been in the last few years that we genuinely thought it was even possible.
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.
But it’s a fundamentally different type of security bug: these biometrics bypasses require knowing something about the user (lift a fingerprint, picture of a face, etc).
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.
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.
I disagree with this. There isn't a consumer-level alternative to the security provided by a pixel if you want to use a cell phone right now. I guess you can argue that the iphone is better, but without a specific threat model to discuss, it's like arguing mountain dew is not healthy so you should drink dr. pepper.
An alternative would be to go show a bunch of journalists that you can unlock their phone and have this all over the news. You get your name /really/ out there for holding Google accountable for security negligence and ignoring a very reasonable 90 day window. The exposure could lead to millions in security consulting contract work over time if played right.
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.
I suspect if he started the conversation with a 90 day disclosure window they would have offered him $100k immediately to extend the deadline. Of course, you'd have to consult a lawyer to make sure you don't technically cross the line into blackmail.
I've seen multiple instances of Google failing to correctly triage critical security issues. I can only conclude from these organizational failures that Google leadership doesn't really take security seriously.
This was kind of my experience with reporting a bug to Google as well. Some years ago I managed to upload a SWF file to "google.com" which allowed me to do an XSS and access anyone's gmail, contacts, etc. I reported it and they just initially never responded and I had to constantly follow up. It was seemingly a simple bug to fix but it took them a couple months and they eventually only paid $500. Being able to exfiltrate data out of someone's gmail account always seemed high priority to me but I guess not lol.
Glad he got rewarded. Feels like this could have played out differently, if it had hit his disclosure deadline we might have been reading about him going to prison, such is the febrile nature of the legal situation around vulnerabilities.
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.
You've invented a quantitative measurement (100x) for something that is qualitative. This unravels discussion and turns away those who may otherwise support your assertion.
The number of long-running bugs which have been found in popular open source projects suggests that “many eyes make all bugs shallow” should be remembered as an amusing bit of 90s trivia like Swatch Internet Time.
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.
If something isn't being actively attacked, penetrated, scoured over, delved into, fuzzed, and poked at by MULTIPLE EXPERTS IN THE FIELD, you should assume it has several completely bypassing security vulnerabilities.
“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.
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 a photo than Android.
For anything security related, like banking etc. I use iPhone.
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 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.
I’ve run into this with other vendors and really wished it’d get you CCed on updates so you didn’t have to ask for status periodically. It definitely doesn’t give a good impression when things drag out for aeons.
What's crazy is that it's 100% in the vendor's interest to keep this person happy, who they know can cause massive damage to their system, completely legally. The only leverage they have is the reporter's greed to get a bounty.
I suppose the risk is people could 'game' the system.
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.
I agree, but just to play devil's advocate if I discover a bug, disclose it, then tell all my friends to also file a report before it is filed they'd have to honor multiple bounties.
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.
You'd probably violate the agreement so you and everyone else technically wouldn't qualify and would be committing fraud. That said there are other options, such as splitting the reward for a vulnerability amongst those who report it (even the dupes). This would incentivize people not to disclose the vulnerabilities while keeping the payouts static.
Do you mean each new person should get a new bounty, or all reporters should split the bounty? The latter does not really incentivize much, but the former incentivizes reporters to collude with other reporters (i.e. you find a bug, tell your 40 friends to report the same bug, you get a kickback from all your friends who also reported it. $$$$).
The latter does incentivize everyone who stumbles across the bug to not disclose it. At the same time, it's sad for the original researcher whose bounty gets smaller with every new person stumbling across it.
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.
> Everyone who reports an undisclosed bug should get a share of the bounty; this incentivizes them to stick to the embargo.
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.
I mean you all share the fixed bounty amount. You could only game the system if you expected other people had already found the bug. However this would be risky as it is fairly easy to detect and penalize. The common case is still you only get one reporter per bug.
Surely in this case, the second report must have added some details, since they weren't fixing the original report and i assume android doesn't just sit on lock bypasses.
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'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.
> 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.
> 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.
Ah, that's a nice hack to avoid having to pay your bounties! First report: "can't reproduce, sorry." Subsequent reports: "duplicate, sorry." Then fix on whatever schedule you feel isn't too blatant.
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, 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.
Reporting and investigation matters. Perhaps the initial report was only on the bypass of the lock-screen but the initial report only ran into the decrypted phone state so it was dismissed as not being exploitable (see other comments), whilst the second report actually got inside an active phone (And then was also written up in a simple, concise and reproducible way).
Just trying to rationalize, but if the "external researcher" was hired by Google to find security issues, google might have a requirement to fix the bug at its own pace.
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.
You can read in the conversation that Google was not able to reproduce it the first time the bug was submitted:
> 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.
Yeah I agree with that one. They set up a call and he stood by his decision to disclose it on oct 15th. Then 3 days before the disclosure deadline they rewarded him.
I was surprised that hotswapping SIMs works, I thought it was not supported.
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.
> I mentally noted that this was weird and that this might have some security implications so I should look at it later.
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 :)
Every once in a blue moon when I pick up my locked iPhone (which auto-locks in just 30 seconds) and engage the home button just as the screen comes alive from the gyro sensing movement, it unlocks on its own. It just flashes the PIN dialog and slides right onto the home screen. I don't use Touch ID, and never stored my print with it even once to test the feature/hardware. It's been happening ever since iOS 11, with both my 1st gen. iPhone SE and my current iPhone 8.
I reported it years ago but the report was ignored and closed, possibly because I could not provide a reliable/reproducible procedure for triggering it.
This sounds like a UI race condition and actually gives me more confidence in the iPhone (unlike the Pixel, the unlock state isn’t tied to UI elements).
Unless of course you can do this long after it locks…
Given how much engineers make at Google after a long interview process to supposedly only get the best people, how significant the login system is to security, how "industry standard" the Google process is, it's not a bug that should have ever made it live. The bug fix show that the issue was clearly a case of a set of people not communicating well, code reviews being lax, and a general lack of understanding of how Android works.
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.
It looks like (not an expert) they did not use a state machine there. Those kind of behaviors are better detected with them. But I am just thinking out loud.
I have spent a lot of time in the Android codebase building security/privacy focused ROMs. It was a very dark rabbit hole and in the end I realized the 240GB of messy blobs and source code can never be understood or audited by anyone.
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/
474 comments
[ 2.6 ms ] story [ 398 ms ] thread*Edit: ̶H̶o̶w̶ ̶t̶o̶ ̶s̶t̶r̶i̶k̶e̶t̶h̶r̶o̶u̶g̶h̶?̶ - cheers
̶t̶e̶s̶t̶
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?
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.
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.
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."
From https://discussions.apple.com/thread/253568420
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.
of course this detail doesn't take away from the rest of the report - great find xdavidhu!
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
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...
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.
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.
> 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.
(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.)
https://news.ycombinator.com/newsguidelines.html
> "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.
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 :)
Unless of course you can do this long after it locks…
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/