[HN Gopher] Spyware vendors use 0-days and n-days against Androi...
___________________________________________________________________
Spyware vendors use 0-days and n-days against Android, iOS and
Chrome
Author : satoshiiii
Score : 171 points
Date : 2023-03-29 12:20 UTC (10 hours ago)
(HTM) web link (blog.google)
(TXT) w3m dump (blog.google)
| sbuccini wrote:
| Can we change the link to the official blog post, which has more
| details? https://blog.google/threat-analysis-group/spyware-
| vendors-us...
| sieabahlpark wrote:
| How will the poor authors of the bleepingcomputers website eat
| and feed their families if we rob them of their ad money for
| blogspam?
| dang wrote:
| Yes. Changed from
| https://www.bleepingcomputer.com/news/security/google-finds-...
| now. Thanks!
| ocal5 wrote:
| So,
|
| Safe in Chrome since November 2022
|
| Safe in Ios since November 2021
| dylan604 wrote:
| 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.
| lern_too_spel wrote:
| On Android, Chrome updates without a device restart, unlike
| WebKit on iOS, and updates are faster to roll out.
| kccqzy wrote:
| 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.
| userbinator wrote:
| 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.
| userbinator wrote:
| 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.
| CubsFan1060 wrote:
| 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
| dmix wrote:
| Google's threat group wouldn't be blogging about it if it
| wasn't fixed, with rare exceptions.
| illiarian wrote:
| 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...
| andrewaylett wrote:
| 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.
| bell-cot wrote:
| 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.
| [deleted]
| dmix wrote:
| 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.
| kramerger wrote:
| > 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
| rs_rs_rs_rs_rs wrote:
| 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?
| tptacek wrote:
| The argument for disclosure prior to patch is stronger in
| the TAG case (active exploitation) than in the normal PZ
| case, not weaker.
| ar9av wrote:
| [flagged]
| agloe_dreams wrote:
| [flagged]
| jsnell wrote:
| 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.
| prdonahue wrote:
| 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.
| Arnt wrote:
| 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.
| agloe_dreams wrote:
| 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.
| chatmasta wrote:
| 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...
| Arnt wrote:
| "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?"
| Hizonner wrote:
| They've been known to actually go public on Google stuff
| when other Google groups didn't get their shit together
| on time.
| neodypsis wrote:
| This is convincing me that iOS users should enable Lockdown Mode,
| irrespective of whom they may be.
| kramerger wrote:
| 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.
| neodypsis wrote:
| > 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 on their pocket
| with a reliable Internet connection, a microphone and a
| camera; and such devices have demonstrated consistently to be
| vulnerable to nefarious actors.
| Syonyk wrote:
| 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.
| neodypsis wrote:
| > 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!
| a_worried_user wrote:
| [dead]
| hospitalJail wrote:
| 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.
| illiarian wrote:
| > 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
| kramerger wrote:
| 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.
| bobse wrote:
| [flagged]
| varenc wrote:
| Is there any indication if iOS's Lockdown Mode[0] would have
| stopped these exploit chains?
|
| [0] https://support.apple.com/en-us/HT212650
| Gaelan wrote:
| 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.
| jeroenhd wrote:
| 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.
| kvetching wrote:
| This is the real threat of these large AI models. They will
| revolutionize the ability to find vulnerabilities.
|
| Especially if we achieve AGI.
| tptacek wrote:
| 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.
| kibwen wrote:
| 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.
| walterbell wrote:
| Some vulnerabilities have their own supply chain and
| incentives.
| KeplerBoy wrote:
| i worry more about GPT-assisted social engineering.
| lima wrote:
| 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.
| Hizonner wrote:
| [flagged]
| flanbiscuit wrote:
| > 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...
| tialaramex wrote:
| > 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.
| wccrawford wrote:
| 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.
| 3np wrote:
| 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).
| eunos wrote:
| > location and install .IPA files
|
| ??? Did they mean APK file?
| mig39 wrote:
| IPA files are the iOS version of APK, I think.
| a_worried_user wrote:
| [dead]
| [deleted]
| nixcraft wrote:
| 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
| ikekkdcjkfke wrote:
| Think i clicked a fake video on twitter going to a bit.ly
| domain not long ago
___________________________________________________________________
(page generated 2023-03-29 23:01 UTC)