CVE Trends is warning us that over the past week the latest Apple vulnerability has racked up nearly 6 million audience interactions on Twitter.
CVE-2022-22620: 6M
CVE-2022-24086: 3.2M
CVE-2021-44521: 2.9M
Very interesting to see such a long tail instead of the usual up and down audience curve. Anyone have a guess why this vulnerability is getting so much more audience?
Apple, per usual, is very tight-lipped about their emergency security patch, which has been credited to an anonymous researcher.
Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited. Description: A use after free issue was addressed with improved memory management.
Alleged so far is that this marks a 0-day in Apple devices (exploited in the wild before the patch was released), easily hacked by clicking on just one link (1-click) or perhaps even less (0-click through waterholes, cross-site scripting, man-in-the-middle, captive portal, etc). It would be hard to allege anything higher risk, and that is surely generating attention.
It’s also probably safe to say that a 15.3.1 minor release just two weeks after ten major security fixes are announced in the 15.3 release (including in-the-wild 0-day patch of CVE-2022-22587 — code execution with kernel privileges)… all means this patch is even more unusually important.
Worth noting is that malware researchers are pulling the “UPDATE NOW” alarm, and CISA is similarly saying “we’ve added one more” the next day after publishing their latest “Known Exploited Vulnerabilities Catalog”.
…evidence that threat actors are actively exploiting the vulnerability… remediation due date: 2/25/2022 [only two weeks from Apple’s patch release]
Highly unusual to have a critical patch announcement dropped almost immediately on top of a critical patch announcement, forcing everyone in the US government to patch Apple devices basically right now instead of whatever else they have to think about. It doesn’t get any more serious than this one.
As a laugh I also have to give credit where due, as The Register apparently published on this vulnerability all the waaaay back in 1970!
Leave it to a vulnerability reporting site to have an obvious integrity flaw sitting out in the open like that.
And as another laugh, that Register article cites a ex-Google guy now a Microsoft browser program manager throwing stones from inside his glass house
Imagine, if you can, a world where installing an alternative browser as your default actually had a chance of protecting you from [a software company’s] shocking underinvestment in security
Indeed. Chrome on Google and Edge on Microsoft should be your last choice, given what we know about WebKit on Apple having issues. Another Google guy cited by The Register wants you to worry about Apple based on the following analysis:
Apple’s average repair time for iOS bugs is more or less the same and Google’s average repair time for Android – 70 and 72 days respectively. …”WebKit is the outlier in this analysis, with the longest number of days to release a patch at 73 days,” wrote Project Zero researcher Ryan Schoen.
“Outlier” seems rather strongly worded when looking at a spread of 70, 72 and 73. Confusingly, Ryan here is being represented as saying because Chrome is patched on a 30 day average then iOS should have its Webkit patched faster. That’s like comparing bananas and Apples.
Instead perhaps look at Project Zero Day like this:
Average Fix Time:
Android (72 days) versus iOS (70 days)
Chrome (30 days) versus Webkit (73 days)
The answer to why Webkit is slower than Chrome is really just a matter of how program managers are pushing releases, which Google admits in their analysis of Microsoft.
For Microsoft, we suspect that the high time to fix and Microsoft’s reliance on the grace period are consequences of the monthly cadence of Microsoft’s “patch Tuesday” updates, which can make it more difficult for development teams to meet a disclosure deadline. We hope that Microsoft might consider implementing a more frequent patch cadence for security issues, or finding ways to further streamline their internal processes to land and ship code quicker.
Related is the fact that Google security telling Google engineering to fix things faster under Google’s dubious business model is fundamentally different than when Google’s security team admits they don’t get how Microsoft and Apple do business (hint: it doesn’t involve *cough* anymore *cough* screwing customers with terrible safety).
And one big reason more people don’t flip to a Chrome security team’s ivory tower thinking of over-privileged control with its constant and rapid-release mentality is because of an old (perhaps wise and considerate) sentiment that you shouldn’t need to constantly fix things if you try to design them for some degree of stability that serves the needs of others.
This is expressed simply in the Linux community as a sliding spectrum from “daily” builds to “long term support” (LTS). Sometimes LTS will have an urgent patch, yet for most of the time it skips all the daily nonsense such as patches for patches that were just patched.
Of course I am not saying here that it’s somehow inherently right to — *gasp* — expect one month to go by without having to absorb cost of an update, but there does exist a world where you CAN’T update faster due to many environmental conditions well-known to scientists who care a lot about predictability and stability (e.g. launching exploratory missions into uncontrolled spaces).
