tyingq · 3 years ago

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.

Semaphor · 3 years ago

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.

izacus · 3 years ago

Thing is, most phone manufacturers will customize the lockscreen quite a bit, so it's possible (but not necessary!) it affects others.

alanning · 3 years ago

One of the commenters on the blog post stated that the bypass did not work on their Samsung device.

Apreche · 3 years ago

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.

ballenf · 3 years ago

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.

qwertox · 3 years ago

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.

bluocms · 3 years ago

And this is something I come up on the spot. Engineers should think about like their life depends on it, this is a major security flaw.

Even more robust would be to switch that flag off by using the password or derived password from biometrics.

system2 · 3 years ago

It is android.

EspadaV9 · 3 years ago

Could try checking out https://grapheneos.org/, it looks like they are supporting the Pixel 4 for a little longer.

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.

x0x0 · 3 years ago

Same. Absolutely unbelievable that they sat on this to avoid having to fix it.

lupire · 3 years ago

Don't worry, your phone has already has other vulns.

perlgeek · 3 years ago

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.

dgl · 3 years ago

In the write-up search for the bit that says "and one time I forgot to reboot the phone".

tl;dr: It's not an encryption bypass, it bypasses the lock screen once the phone has been unlocked once.

tyingq · 3 years ago

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.

chrisfosterelli · 3 years ago

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.

ngm___ · 3 years ago

  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!

urthor · 3 years ago

I forget which Pixel generation.

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.

notyourday · 3 years ago

There's exactly one drop everything and get it fixed ASAP bug at Google - something broke the ad platform.

robertwt7 · 3 years ago

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.

lrvick · 3 years ago

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.

cle · 3 years ago

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.

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

pstation · 3 years ago

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.

lrvick · 3 years ago

I tell companies 90 days. When they ignore me I go public at 90 days, consequences be damned.

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...

sschueller · 3 years ago

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.

ApolloFortyNine · 3 years ago

Who knows how many bugs live in iOS as well. Security through obscurity (iOS is closed source) isn't usually considered that great a strategy.

Besides the whole "can't install user software" issue.

sgt · 3 years ago

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.

IceWreck · 3 years ago

Bugs happen in iOS too.

> 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.

Cthulhu_ · 3 years ago

> I wish closing things as "this is a duplicate" essentially required disclosure of the original (dupe) report.

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.

acdha · 3 years ago

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.

rkagerer · 3 years ago

Yeah for purposes of the reward it should only be allowed to be considered a dupe if it duplicates a disclosed bug.

ZiiS · 3 years ago

Everyone who reports a undisclosed bug should get a share of the bounty; this incentivizes them to stick to the embargo.

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.

bawolff · 3 years ago

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.

j0hnyl · 3 years ago

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.

thrtythreeforty · 3 years ago

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.

whizzter · 3 years ago

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).

CapsAdmin · 3 years ago

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.

albertzeyer · 3 years ago

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.

s4i · 3 years ago

Applies to YouTube too.

htrp · 3 years ago

and Facebook... and every other company too cheap to pay for support.

DonHopkins · 3 years ago

Well there just went my chances of getting anything fixed at Twitter or Facebook...

mschuster91 · 3 years ago

Yes, that is the entire point why this is so nasty.

Tepix · 3 years ago

Why do you think so?

Liquid_Fire · 3 years ago

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.

MPSimmons · 3 years ago

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

vitiral · 3 years ago

Delete this comment and write a bug, you could get $100k

metalforever · 3 years ago

Yeah I’ve seen this too.

jquery · 3 years ago

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…

GiorgioG · 3 years ago

I can't tell you how often I still see operating system level rotation bugs from iOS on my iPhone/iPad. Complexity kills.

pfortuny · 3 years ago

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.

lrvick · 3 years ago

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/

krajzeg · 3 years ago

Agreed. The fixed logic, at least judging by the commit message, still feels very shaky on correctness grounds ("if we are dismissing something that doesn't seem to be right, ignore it").

Since they're rewriting code and changing method signatures anyway, I would prefer they got rid of the notion of "currently visible screen" and made sure that all dismiss() calls have a unique pointer or token pointing to what 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.

joezydeco · 3 years ago

Am I reading this right? This reads like the presence of a UI element holds the unlock state of the phone?

oneplane · 3 years ago

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

zitterbewegung · 3 years ago

Google invests a great amount of money in their project zero team but does anyone know if they have a specific red team that is dedicated for Android ?

dshpala · 3 years ago

And of course fix includes magic SecurityMode.Invalid value, which makes dismiss() behave like it did before.

I'd look very hard at places that use SecurityMode.Invalid.

bsder · 3 years ago

Yeah, I suspect this fix isn't going to hold for very long at all now that everybody knows to look at it.

If Google isn't readying a more extensive fix right now, they're going to get pwned shortly.

lupire · 3 years ago

There's nothing OOP-specific about this bug. The bug is in too-wide variable scoping, insufficient OO really.

onychomys · 3 years ago

Maybe having morals is worth $230k to the author.

lupire · 3 years ago

Why? Pixel is stock android and also customization, so it needs attention to both.

Gasp0de · 3 years ago

As it says in the blog post (and is confirmed somewhere in the comments here) this is not pixel specific.

jonpalmisc · 3 years ago

I also keep one on my keyring and I get poked in the finger/thigh by it all the time; it’s super annoying! Still keep it though since I regularly have to pop my SIM in and out..

jaywalk · 3 years ago

Why do you need to pop out your SIM so often? Is that an Android thing, or are you actually swapping your SIM all the time?

jagged-chisel · 3 years ago

Surely you can find something more recent than five years.

pvg · 3 years ago

More important not to come here trying to goad other users into some pointless flamewar.

_kbh_ · 3 years ago

LEO already have access to locked phones via stuff like GrayKey.

https://www.grayshift.com/graykey/

sebzim4500 · 3 years ago

Sounds like this only affects phones that have been unlocked since the last restart, so unless they have kept them plugged it is unlikely that this attack would be successful.

Semaphor · 3 years ago

That actually sounds plausible. It’s a pretty simple explanation that would explain all the issues in the post.

sofixa · 3 years ago

For what it's worth, all the famous either unlocking or remote hacking sagas (like Pegasus) have mostly been around iPhones. Which either indicates that Androids are so trivially hacked that nobody is even talking about it (sounds a bit doubtful, IMO, hopefully), or that the majority of "targets" have been using iPhones. It has certainly been the case with all the hacked journalists I remember.

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?

duxup · 3 years ago

I suspect pressure to backdoor something or similar requests in the US are often (not always) one off adventures that collectively look like something larger, rather than say a policy where someone goes to companies and make general requests continuously like some regulator going about his business.

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.

Gasp0de · 3 years ago

No. "No security updates after X" means no security updates after X. Of course you can install an up-to-date OS, e.g. LineageOS works on the Pixel 4.

davidmurdoch · 3 years ago

Please publish a blog full of these based-on-a-true-story behind-the scenes tech-drama fiction stories!

mmun · 3 years ago

This is the exact vibe I got reading that part.

michaelbuckbee · 3 years ago

Security researchers (like the one here) don't want harm to come to people from their actions. If they announced the live bug before it was patched a lot of people and organizations might have been adversely by this before the fix was applied.

2OEH8eoCRo0 · 3 years ago

Linux?

chimprich · 3 years ago

Considering it's probably the world's most used OS, it's laughable. They churn out new recommendations constantly only to deprecate it again and think of some new tedious convoluted approaches a short time later. I think it's a combination of poor judgment and Google's toxic internal incentives to design crazy new stuff.

beeboop · 3 years ago

It's entirely possible it came from a channel that wasn't eligible, or from a google employee, or own of their own security testers, etc.

IceWreck · 3 years ago

Google could not reproduce it the first time so presumably they didnt pay up.

Daniel_sk · 3 years ago

What specific device do you have?

jascination · 3 years ago

Are you able to set a new pin or fingerprint from that state?

Anderkent · 3 years ago

roll to disbelieve. i think someone was pulling your leg

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

rippercushions · 3 years ago

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

julianlam · 3 years ago

Did this self-reported hardware engineer from Google tell you WHY his colleagues don't use a Pixel?

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.

strix_varius · 3 years ago

I'm... not sure that I would take a random person* in a T-Mobile store at their word when they claimed that they were "actually working in the hardware division at Google."

thejman5200 · 3 years ago

I have a Pixel 6 because I bought it through Verizon when they offered a 5/month rebate for 36 months = 180 dollars off. This was at the beginning of this year so before the Pixel 7 released. I assume they offerred the rebate because they had a whole lot in stock that nobody bought, but everyone in my family got a Pixel because of it.

solardev · 3 years ago

What don't you like about the Pixels? I just switched to an iPhone this year and really regret it (the UX is horrible) and miss my Pixel.

goodness · 3 years ago

The main reason for this is just fucking iMessage.

It's not even just that iMessage segregates non-iPhone messages by color. It screws up video and group texts.

idk1 · 3 years ago

Could it have been a sales technique? Perhaps to sell you an iPhone. Perhaps the iPhones they were trying to sell have a higher commission and margin than the Android phones.

chasil · 3 years ago

Modern carriers are migrating to VoLTE, and LineageOS is unable to implement this outside of a few devices, meaning that many phones have been dropped from the latest release.

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).

rroot · 3 years ago

In met a guy once that pulled my aside once and told me he was an alien.

advisedwang · 3 years ago

Or more charitably, by the terms of the program he wasn't eligable for anything, but they gave him seventy thousand dollars out of goodwill and the spirit of the program.

tempestn · 3 years ago

I agree that it appears to have been the disclosure threat that resulted in the bounty, but I don't agree (if I'm reading you correctly) that the OP acted unethically. It sounds credible to me that he was just doing everything he could to get the bug fixed.

Sophira · 3 years ago

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

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

hadlock · 3 years ago

It would not surprise me if in some cases, google runs the exploit up the tree to the NSA to see if they're actively using this for matters of national security, then slow-walk the patch to release. Given how easy the exploit is (no software needed, no special equipment beyond a paper-clip), would not surprise me if this has been in wide use for several years now by various groups.

saalweachter · 3 years ago

"Miscellaneous income".

scarmig · 3 years ago

Turmoil isn't a good description of Google right now, though. It's far from healthy, but it has avoided mass layoffs so far, and the bug was filed in June.

djmips · 3 years ago

Maybe the new one was encoded in the fix.

ruined · 3 years ago

if your patch level is less than 2022-11-05 you are affected :D

stardenburden · 3 years ago

On my pixel 4a there's a "critical security" update available for download. (Current patch level is one month old)

I will try to exploit before and after downloading.

stardenburden · 3 years ago

It doesn't get decrypted. The data is still safe after a reboot. That's presumably why the phone hangs for the author after a reboot. Although some comments have said Android itself loads (and I guess also the launcher) but they can't really do anything

capableweb · 3 years ago

> Given a high level of false positives, it's probably not uncommon AT ALL that sometimes it takes a couple of bug reports before something is reproducible or generates a high enough alert/credibility status, as seemed to have happened here.

This case was not the case of eventually the same reports being taken seriously. None of them were, until the author met people working at Google in person at some event, and him 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.

vanderZwan · 3 years ago

If you are that makes two of us, my partner just asked me why I shouted "what the hell?!" when I read that.

hadlock · 3 years ago

This only applies to phones who remain continuously powered on and still retain the decryption key in memory. It's possible you turn on your old, unused phone, unlock it (putting the key in memory), and plug it in for years but the number of phones in this state are probably vanishingly small.

quantumsequoia · 3 years ago

If you want a stable bug-free phone, oneplus is not the phone for you. Ever since they merged oxygenos and color os, oneplus phones are laden with bugs.

I was planning to switch from oneplus to pixel for this reason.

Miraste · 3 years ago

I wouldn't worry about missing out on battery life. Every Google phone has had pretty sad runtime since the very first Nexus. It would seem they don't care.

hojjat12000 · 3 years ago

Oneplus used to be good. But the experience and the OS is not the same. If you want Dex. Why not Samsung? I have a Pixel 6 (which I regret trading my Onplus6t for) and my next phone probably will be a samsung. The new ones are pretty stable and not as bloated as they used to be.

vbezhenar · 3 years ago

Buy iPhone. I'm switching from iPhone to Pixel because iPhone bans some apps which are essential for me. Android is just so bad. The day Apple allow side loading, I'll switch back.

bredren · 3 years ago

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

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

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

alphabettsy · 3 years ago

That’s pretty frustrating, I have a Pixel 4 that I quite like.

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?

woojoo666 · 3 years ago

Another way to look at it is, since the bug is from a race condition, modeling your program after functional programming would minimize these bugs

im3w1l · 3 years ago

I think the root issue is one of which state is the default one. In Android the logged-in state is the default one, and the logged-out state is constructed by taking the logged-in state and essentially hiding it behind a modal.

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.

gwillen · 3 years ago

Do you have any writing I can read about your classification? This sounds extremely interesting and useful. (I have some related thoughts, but not 20 years' worth and largely not recorded.)

appleflaxen · 3 years ago

I would like to subscribe to your newsletter.

jbverschoor · 3 years ago

So you migrate to Apple

rerx · 3 years ago

There is LineageOS now, https://wiki.lineageos.org/devices/sargo/

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.

codethief · 3 years ago

Or install GrapheneOS? Pixel 3a support is being phased out slowly but surely but currently it's still getting all security patches.

EDIT: I stand corrected, they stopped support in September. :(

pm215 · 3 years ago

Dunno whether you'll read this, but as a fellow 3a owner I just discovered that there is a September update image on the google website: https://developers.google.com/android/ota#sargo -- I guess maybe this will appear as an OTA update eventually? On the other hand it still doesn't have a fix for this bug, so the situation isn't really any different :-(

mqus · 3 years ago

This is also the point that stands out to me the most. This is hypocritical and pretty close to negligent, if they set such high standards for other companies they investigate but can't own up to it themselves.

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.

tamirzb · 3 years ago

If you follow published reports of Android vulnerabilities you'll see that taking longer than 90 days for a fix is actually not that rare. I myself had a similar experience a couple of times.

zaphirplane · 3 years ago

I am surprised there is an assumption that android fixes will get to users within 30 days