73 comments

[ 5.1 ms ] story [ 136 ms ] thread
Am I right in that these were fixed (at least in iOS), some time ago?

https://nvd.nist.gov/vuln/detail/CVE-2022-42856

https://nvd.nist.gov/vuln/detail/CVE-2021-30900

Google’s threat group wouldn’t be blogging about it if it wasn’t fixed, with rare exceptions.
This reminds of a great thought experiment [1]

If you discover an exploitable flaw in pacemakers, do you:

- disclose it immediately? This may lead to an increased number of attacks on pacemakers

- disclose it to manufacturers, and wait for them to patch things before dicslosing?

- if manufacturers are too slow to fix this, or flat out refuse to do anything, do you still disclose?

I'd hate to be on the team that needs to make the disclosure decisions and figuring out whether the fallout is worse than just keeping the knowledge hidden.

Of course, it's not a pacemaker-level in this particular case, but every time I see exploits and their disclosure, I'm reminded of this.

[1] Well, sadly it's not really a thought experiment: https://www.mnemonic.io/resources/blog/uncovering-vulnerabil...

IANAL...but for pacemakers, I'd be tempted to mail the details to the legal department(s) of the manufacturer(s). Registered mail. With a little note about how you received legal advice on your proper course of action in this situation...from a law firm notorious for suing medical device manufacturers.
Not to downplay your thought experiment but Vulnerability disclosure has been debated to death in the infosec community, ad nasuem. Seems like someone always challenges it when it comes up in the press on Twitter where it seems there will never be a hard answer here that will satisfy everyone.

The consensus and IMO best solution is follow the standard of disclosing and then waiting a reasonable amount of time before telling the world. But there will always be exceptions to the rule where threat models are different or the tech/business environment is different than fast moving software… like old school medical companies with slow moving fixes for medical devices. The latter seems like it has more responsibility to wait but public pressure on them to move but they also typically have teams of lawyers who are disconnected from infosec/tech reality.

I'm fine with waiting if the org in question is making progress toward fixing things. It probably takes more than 90 days to do a proper FDA review for a pacemaker fix, and if the update requires surgery after that it could be years. But they need to show reasonable effort to fix all the issues.
Project Zero has a fairly strict 90 day disclosure timeline, in part to avoid having this discussion for the majority of issues. 90 days passes, issue disclosed.

But they did recently withhold four disclosures due to the seriousness of the issues: https://googleprojectzero.blogspot.com/2023/03/multiple-inte... and not for anything as life-threatening as a pacemaker. It seems that brings the total number of policy exceptions to six.

I think one of the keys here is working out your policy in advance, so you've got a robust set of criteria to work from when you need to evaluate a specific case.

(comment deleted)
> Google’s threat group wouldn’t be blogging about it if it wasn’t fixed, with rare exceptions

Well, there was that incident with project zero vs Microsoft a while back...

Lets hope TAG is better than PZ

Are you talking about that incident when Google folks decided to make information about a vulnerability public so people can protect themselves while Microsoft were dragging their feet working on a fix?
The argument for disclosure prior to patch is stronger in the TAG case (active exploitation) than in the normal PZ case, not weaker.
A hardware exploit on one browser and a web based exploit are not even on the same level.

Instead of lumping all of Android, just name the brands with hardware issues. IMO its clickbait. I don't use both the phones listed and the web browser listed. But hey, they got me to click. I'm already getting desensitized.

> Instead of lumping all of Android, just name the brands with hardware issues

"Pixel, Samsung, Xiaomi, Oppo and others". So, roughly 90-99% of the Android market

Am I correct that this does not apply to Qualcomm?

That would mean it's limited to some Samsumg phones and random Chinese chipset, but Samsung is pretty good at swift security updates so I am confused why this one wasn't deployed on time.

Is there any indication if iOS’s Lockdown Mode[0] would have stopped these exploit chains?

[0] https://support.apple.com/en-us/HT212650

Yes (from the Google blog post linked elsewhere in the thread):

> CVE-2022-42856, a WebKit remote code execution exploiting a type confusion issue within the JIT compiler (0-day at time of exploitation).

Lockdown mode disables the Webkit JIT.

It's worth mentioning that most of security measures are also possible in the Chromium engine in case you're running that.

I use Bromite (Chromium fork) on my phone which has the option to run with JIT disabled by default, which would've been how Lockdown Mode would stop this exploit. Very rarely do I click the permissions popup to enable it again, mostly for games and demos requiring WASM or depending on heavy Javascript.

From the https://blog.google/threat-analysis-group/spyware-vendors-us...

> In November 2022, TAG discovered exploit chains with 0-days affecting Android and iOS that were delivered via bit.ly links sent over SMS to users located in Italy, Malaysia and Kazakhstan. When clicked, the links redirected visitors to pages hosting exploits for either Android or iOS then redirected them to legitimate websites such as the page to track shipments for Italian-based shipment and logistics company BRT or a popular Malaysian news website.

You can harden your iPhone/iOS from a cyberattack with Lockdown Mode[0]. It blocks those clickable links and removes many other attack vectors https://support.apple.com/en-gb/guide/iphone/iph049680987/io... However, I'm unsure if an attacker could bypass Lockdown Mode with additional bugs on iOS.

[0] https://support.apple.com/en-sg/HT212650

Think i clicked a fake video on twitter going to a bit.ly domain not long ago
This is another one of those cases that seems to be completely nullified by keeping JS off by default and whitelisting it only on sites you really trust.

But of course the biggest spyware company in the world relies on the same to track its users.

It's amusing to see the Google sympathisers attempt to deflect observations of the truth. You can't brainwash everyone, and the more you try, the more we'll resist.
(comment deleted)
[flagged]
Who cares if there’s a marketing component to it? P0’s efforts make the Internet more secure for everyone. ETA: They also need to draw attention sometimes to slow actors in addressing the fixes.
No, the official policy is that that team is to poke at anything that's used together with Google, which is ~everything. It started as a result of someone using a security bug in other software to gain privileged access to Google.

You have a phone. People use the same phone together with a Google service and a security-related bug in the phone could be used to e.g. steal your Google password, therefore the phone's software is in-scope, no matter who made it or what it runs.

I see the sense of it, but it's weird to me too. What's not used together with Google? That's such a wide scope. But it's not a matter of security or marketing, the weirdness is in the wide usage. Kudos to Google for working on it.

Exactly. A few months (or was it a year?) ago they had a 0-day on iOS that was fixed and made a huge stink about it and it all just read like marketing for a Pixel. It's a wide net that I'm still glad they do...just weird.

IT does make me wonder...what...don't..they report? Why wouldn't they hold a few smaller items back, focus a little more on iOS exploits? It's just a "Be aware of the source" thought. Still a net positive.

They find plenty of bugs in their own devices too. And it's not like they aren't responsibly disclosing to Apple.

But I'd be curious how strictly their 90 day disclosure policy applies to Google products, and if they are more willing to grant some leeway when a fix isn't pushed in time...

"Hi, maps team, you still haven't fixed foo and time is runnuing out. You may recall that Project Zero was founded because [name of founder] was livid about a security bug. Do you want to fix this RSN, or would you prefer to discuss it with him?"
They've been known to actually go public on Google stuff when other Google groups didn't get their shit together on time.
First, you seem to be confused. This is TAG, not Project Zero. TAG tracks government-backed attacks in the wild. It's not theoretical vulnerability research, it is about actual humans being hacked by authoritarian governments right now.

What would you have them do? Ignore the iOS vulnerabilities and leave the iOS users unprotected? That'd be a great look...

Second, this is a really bizarre complaint given this very submission is reporting on both Android and iOS. Even if there really was security research being done with the specific goal of negative marketing on competing products (a claim you make with no evidence, and continue to double down on with no evidence), this submission would be a very bad example of that.

> When clicked, the links redirected visitors to pages hosting exploits for either Android or iOS then redirected them to legitimate websites such as the page to track shipments for Italian-based shipment and logistics company BRT or a popular Malaysian news website.

So at least this is not a 0-click exploit

I'm an Android Pixel (5a) user, how does this affect me...

> The Android exploit chain targeted users on phones with an ARM GPU

according to Wikipedia, my Pixel 5a has an Adreno 620 GPU made by Qualcomm so looks like I'm safe there. Curious to know which phones use the ARM GPU, not sure if this is a complete list but I found this[0] on an ARM website. Looks like Pixel 6 and 7 are affected since they use the Tensor chip which are ARM64 based.

> running Chrome versions prior to 106.

Current Chrome for Android version on my phone is 111.0.5563.116. The earliest version of Chrome for Android version 106 I can find is late Sept 2022[1], so not super long ago but it was at least fixed back in Sept.

> Note, Pixel devices with the 2023-01-05 security update are protected against both exploit chains in this blog.

My last security update was 2023-03-05 (and I mentioned my Chrome version above) so I'm protected

> Chrome users updated to at least version 108.0.5359 are also protected.

So which is it? affects users of Chrome prior to 106 yet you need to be on Chrome 108 to be protected? This is a bit confusing. Looks like Chrome for Android v108.0.5359.x was released late November 2022[2].

Just needed to do that for peace of mind. I understand that Google wouldn't be posting this if they hadn't at released a fix for this and handled their Pixel phones.

I really wish there was some kind of database where I can look up a phone model and see a list of exploits and whether they have been patched or not, at least when they are hardware and/or OS related.

0. https://developer.arm.com/Tools%20and%20Software/Arm%20Mobil...

1. https://chromereleases.googleblog.com/2022/09/chrome-for-and...

2. https://chromereleases.googleblog.com/2022/11/chrome-for-and...

It could be that Chrome 106 on OS 2023-01-05 are protected, or just Chrome 108 on any OS is protected.

Or it could be sloppy reporting.

Without reading more than the comment chain, the fix could be backported to a more recent 106.x but existing 106 releases are still vulnerable (sloppy reporting).
> Just needed to do that for peace of mind. I understand that Google wouldn't be posting this if they hadn't at released a fix for this and handled their Pixel phones.

Google is a large organisation. Project Zero at least is quite content to give other Google projects the usual amount of time and then publicise an unfixed bug. No favours.

this is not from pzero
That's correct, it isn't, but the parent comment suggested Google would always have fixed stuff before it's announced by Google and that assumes a more unified organisation, a single controlling mind or else a conspiracy and that's not how it works.
> Curious to know which phones use the ARM GPU, not sure if this is a complete list but I found this[0] on an ARM website. Looks like Pixel 6 and 7 are affected since they use the Tensor chip which are ARM64 based.

Probably just sloppy writing. In this write up, the bug doesn't seem to be specific to a particular GPU model. It's basically a buffer overflow in Chrome's OpenGL ES code: https://googleprojectzero.github.io/0days-in-the-wild//0day-...

[flagged]
So,

Safe in Chrome since November 2022

Safe in Ios since November 2021

My recollection of the Android universe is that not all updates are equally available/supported leaving devices out of date. Is this still the case, or has the provider/devices/OS ecosystem improved? Also, what is the install rate of these updates? Just because an update is available does not mean that it is deployed.
On Android, Chrome updates without a device restart, unlike WebKit on iOS, and updates are faster to roll out.
Yes! As someone using both iOS and Android I cannot believe how Apple still requires a lengthy update process for those critical security updates. On my Pixel phone, installing the update is no slower than a regular restart. Users care about how long the downtime is for software updates. Make it faster, Apple.
Slower to update, but fixed 12 months earlier. Pick you poison...
This is convincing me that iOS users should enable Lockdown Mode, irrespective of whom they may be.
Yes.

100%. Do it, don't look back. Disable it on a per-website basis if needed, but... largely, I simply accept that I don't need to do those things I can't do with it on.

I've been running Lockdown on my iOS devices since before iOS 16 came out (I installed the betas to play with it). The only actual annoyances I've found in practical, regular, daily use:

- Lots of websites use webfonts for icons. Those don't render, and you get empty "No font glyph" boxes instead for various arrows and icons. It's not a big deal in regular use.

- If someone sends you an animated gif as a MMS message (maybe iMessage too), it won't actually animate. Nothing of value is lost.

- The latest from "that guy" won't work, because there's no WebGL support for Javascript animations of watches, bicycles, cameras, etc. Given that the JS is non-obfuscated, I don't mind disabling Lockdown for his site.

- Some websites still use image formats that don't render, but this is far better than it was even six months ago when Lockdown was fresh and new.

Otherwise... I've eliminated an awful lot of actively exploited interfaces for almost no loss in functionality.

> Otherwise... I've eliminated an awful lot of actively exploited interfaces for almost no loss in functionality.

Cool. That's good to hear, thanks for sharing your experience!

This is my experience exactly. I’ll add to the list of inconveniences:

- hyperlinks in iMessage/SMS aren’t clickable (but they can still be copied/pasted)

- installed apps that use JavaScript in their interfaces can have the same issues as websites (but you can turn Lockdown off for apps as well, if needed)

Overall worthwhile. Something about these “inconveniences” also gives me a sort of psychological disconnection from my phone that I personally find to be very healthy. Similar to how I felt limiting myself to F-Droid in my Android days.

Why is the comment section looking like a commercial for lockdown mode?

Even apple admits an iPhone in lock down mode is no longer a normal iPhone. Besides, a low-level exploit like the Android one would bypass it.

> Why is the comment section looking like a commercial for lockdown mode?

I fail to see how my comment could be interpreted as a commercial for Lockdown Mode. Unfortunately, we are living at times where everyone now carries a device in their pocket with a reliable Internet connection, a microphone and a camera; and such devices have demonstrated consistently to be vulnerable to nefarious actors.

> location and install .IPA files

??? Did they mean APK file?

IPA files are the iOS version of APK, I think.
This is the real threat of these large AI models. They will revolutionize the ability to find vulnerabilities.

Especially if we achieve AGI.

If we have AGI capable of finding vulnerabilities, then we can just ask the AGI to design a system so secure that even the AGI cannot find any vulnerabilities.
Some vulnerabilities have their own supply chain and incentives.
It will be an interesting race...

I do think that it'll be easier to find vulnerabilities than to design systems that are provably secure. It's like evaluating a function f(x) vs finding the values of x for which f(x) = 0.

They will revolutionize the ability to find and fix vulnerabilities.

Threat actors can already afford expensive security researchers today. It removes some of the asymmetry.

i worry more about GPT-assisted social engineering.
Writing programs to automatically find bugs is a pursuit almost as old as compilers, and the models used to do that in modern static/symbolic analysis tools are much more sophisticated than an LLM's next-token generator.
[flagged]
n-days. you mean "known and disclosed issues which we choose not to make fixes available to 80% of our clients so we can sell more disposable pocket computers."
damn some of these are bugs fixed in 2021. there's easy money to be made just exploiting published mobile phone vulnerabilities! they won't be abandoned and won't be patched! ... who thought splitting ownership and consequences of not updating software was a good idea?

being a black hat is almost too tempting today.

> who thought splitting ownership and consequences of not updating software was a good idea?

You can't because companies refuse to let customers own and control their devices. Because we can't control them, we can't patch them up. I have a 15 year-old PC that's still running today. It's fully patched up because its vendor gives me enough control to do so.

There should be laws that ban device manufacturers from building or bundling software. Something like Bell Laboratories' breakup, but applied industry-wide.

Captain obvious strikes again.
> These vendors are enabling the proliferation of dangerous hacking tools, arming governments that would not be able to develop these capabilities in-house.

I wonder what this means? Why does it matter if the nation couldn't make the tool themselves?

I might be reading into it. But is there an idea that technological sophistication itself imbues morals? And these unsophisticated nations are amoral?

Or maybe even a might is right mindset?

I'm surely reading too much into this but for whatever reason it stood out to me.

This might not be clear if you don’t normally have any interaction with this kind of “policy” friendly language but it’s making a point that it’s falling into the hands of particularly authoritarian governments who use it to target political enemies, journalists and human rights types and that they certainly didn’t have that capability domestically until someone packaged it up and sold it to them.

They seem to be acknowledging some parallels to this kind of scenario as to the nuclear proliferation problem and that many governments aren’t ok with irresponsible sellers who will put these things in the hands of anyone with money.