Except that iMessage is a perpetual source of security concerns. Once that becomes unsupported, you’ll likely have exploitable code, where the exploit is publicly and widely known (but patched on newer versions).
iMessage is a "perpetual source of security concerns" because it is a remotely triggerable target. That's it.
If everyone is using message service X, then we'll start seeing more attacks on X.
The exploits we've seen over the last few years haven't been in iMessage the app, they've been in a host of different things. The most recent security brouhaha was apparently in the webp library[1] that also effected chrome, webkit, Firefox, every electron app, and I assume every app on android, iOS, macOS, that uses system image decoders, etc. But if you want a specific target then you aren't going to use something like a random webpage or phishing email if you have something that you can guarantee will go to only one device that you know is exploitable, and you can guarantee how it will be handled - i.e. the builtin system messaging apps.
[1] and even here the attack didn't happen from iMessage
I don't know if you're specifically referring to X, the artist formerly known as Twitter, but regardless, no; iMessage runs with unique privileges and capabilities that are not available to ordinary messaging services.
Sorry I forgot the most recent musk idiocy. X was a stand in for any other functionally always on and receiving service, messaging platforms are the primary example.
I'm actually now curious whether the various awful web notification standards allow images?
I think all the reports just say "iMessage" and don't specifically note sms vs iMessage specifically. It's entirely possible that there a carrier side restrictions on allowed image formats, and of course these attackers don't want people to see their exploits and definitionally using sms would allow just that.
But also, in answer to the question: yes, every messaging app on Mac or iOS that could display webp was susceptible to this exploit. If they use ImageIO then the OS update fixes them, if they use their own copy of libwebp they are exploitable until they ship an updated version.
For the recent WebP exploit, IIRC no preview render was even required to trigger it; simply receiving the message was sufficient. The exploit was triggered by a code path in Blastdoor that headlessly rendered the malicious WebP that was embedded within a Passkit attachment.
(But I can't find a source for this atm. I remember reading it somewhere, but maybe I'm confusing it with a previous Blastdoor exploit.)
> For the recent WebP exploit, IIRC no preview render was even required to trigger it; simply receiving the message was sufficient.
It was triggered because the system shows a preview of the image by default.
Devices that had Lockdown Mode enabled no longer show preview images, so were not effected.
>Lockdown Mode is an extreme protection feature for iPhone. Its protections include safer wireless connectivity defaults, media handling, media sharing defaults, sandboxing, and network security optimizations.
> On September 7, 2023, Apple released emergency security updates to fix a buffer overflow vulnerability (CVE-2023-41064) impacting macOS, iOS, iPadOS, and watchOS products that was used in a zero-click exploitation chain by the NSO Group. Shortly after, on September 11, 2023, Google released an update to fix a buffer overflow vulnerability (CVE-2023-4863) in Google Chrome, which was reported by Apple’s Security Engineering and Architecture (SEAR) and Citizen Lab. Both vulnerabilities were nearly identical and listed as actively exploited, leading to confusion across the security community.
Note: Citizen Lab urges all at-risk users to enable Lockdown mode as this has been confirmed by Apple’s Security Engineering and Architecture team that Lockdown Mode blocks this particular attack.
The attack was apparently via PassKit - a separate process entirely, because messages is explicitly hardened (the whole "blastdoor" (tm) thing is to deal with that). I'm not sure what the actual passkit APIs look like but in principle any app that would take an attacker provided image and send that to whatever process handles those passkit things would get the second order part of the attack. But of course some attacker trying to, for example, extract the messages from Signal or suchlike could start from code execution in the signal process.
If everyone is using message service X, then we'll start seeing more attacks on X.
The exploits we've seen over the last few years haven't been in iMessage the app, they've been in a host of different things. The most recent security brouhaha was apparently in the webp library[1] that also effected chrome, webkit, Firefox, every electron app, and I assume every app on android, iOS, macOS, that uses system image decoders, etc. But if you want a specific target then you aren't going to use something like a random webpage or phishing email if you have something that you can guarantee will go to only one device that you know is exploitable, and you can guarantee how it will be handled - i.e. the builtin system messaging apps.
[1] and even here the attack didn't happen from iMessage