This exploit is just wild. There are just so many little tricks connected together - using multiple image files with unexpected formats, aligning heap chunks to sit on easily-predicted and manipulable addresses, deserializing a huge object graph from image metadata, the usual NSExpression insanity, PAC bypass via unsigned pointers to function-pointer-containing structures, etc. etc. I thought the last exploit (where they built an entire virtual CPU out of image decompression commands: https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...) was crazy, but that involved a lot fewer "tricks" than this exploit.
Many of these tricks are non-public, meaning that NSO would have had to spend a huge amount of time and effort researching every single one of these. They probably have many more tricks they know about and haven't used. And, Apple could patch every one of them in a future update and roll back all of that work.
There's a good reason why these exploits are expensive and only sent to a limited number of high-value targets. NSO this time around also worked to "protect their IP" using encryption to hide part of their exploit chain, presumably in a bid to avoid losing yet more of their precious zero-days to researchers.
What they're doing is pretty gross (particularly the whole spying-on-journalists bit), but you have to admit the level of technological sophistication and persistence here is pretty impressive.
A strange choice of words. It's like saying “cannibalism is pretty gross, but the chef outdid himself on those slices”.
Moreover, even if it's complex from the technical point of view, morally it's dead simple: hired programmer is the same as dirty grunt with a gun, and the leader delivering speeches, and the rocket engine scientist, and the data processing clerk, and everyone in between. They all serve the Order they believe in, the king of this world.
> using multiple image files with unexpected formats,
Unexpected ? You mean your jpeg file is not a jpeg. Why not throw an error message then ? Why does (iMessage) it have to open every byte thrown at it ?
NSO Group are a terrorist group for hire. This 0-click, 0-day exploit was found targeting civil society. Any one can pay to target journalists, NGOs, politicians. This is why open-source is paramount to security, and having code out in the open.
Supposedly NSOs products are classed as restricted weapons exports by the Israeli government, and all sales have to be approved by the Ministry of Defense, so they have their own share of the blame when it falls into the wrong hands.
Your conclusion is not connected to the first. Open source software has had many issues over the years and reading the technical details in this post should make it clear that there’s no magic solution to an adversary with this level of resources.
Well, people are going to be targeted anyway. It's better to keep a trail of who is doing what, and that's the purpose of all those offensive cyber startups.
Do they make it easier for actors to perform those activities? Not sure. I was never shopping for 0-day exploits. And some argue it's similar to gun laws in US, if it's easier to buy firearms, someone is more likely to use it. I just don't buy this comparison.
At this point, I think Apple's platform security teams have to seriously [edit: by default] start mitigating attachment exploits in ways that affect UX – _not_ rendering message previews, or blacklisting formats by defaults. Given Apple's pro-privacy messaging – and acceptance of things like Signal auto delete – think Apple's user base might now be comfortable with taking hits to UX in the name of security.
Lockdown mode does this. Preventing weird attachment types entirely. Preventing most of the “edge case” things. Like you also can’t be added to an icloud album, or install new configuration profiles.
Although it’s a bit extreme. It disables almost all web-fonts which breaks a lot of websites. (It’s easy to toggle this, but you have to do so per-site) It’s really not designed for the average user.
I'm sure nobody would think of targeting the national security apparatus of the USG with such an exploit to gain access to... I dunno, their Signal messages?
One of the members of that group was accessing it from Moscow to meet with Putin.
Our adversaries don't have to hack anything at all, they don't even seem to have to ask nicely. There's zero chance that Putin doesn't let China know anything they want about the Trump admin, and Putin himself seems to get to dictate our country's policy now.
This has been the case among republicans for decades, and Mitch McConnell himself (and 6 others) spent the 4th of July 2018 in Moscow for christ's sake.
Would Lockdown Mode mitigate any part of this exploit chain?
If so, which aspects would it block? The Apple support page mentions that most message attachment types are blocked, *except* for certain images, videos, and audio. Given this, would Lockdown Mode have prevented this exploit?
> The closest thing to a specification for the PKPass format appears to be the Wallet Developer Guide, and whilst it doesn't explicitly state that the .png files should actually be Portable Network Graphics images, that's presumably the intention.
Lol, that got a chuckle out of me.
Amazing write up by google project zero as always.
I don’t always buy into the $safelanguage cargo cult but come on, it’s apparent that memory unsafe languages are not appropriate for this purpose and desperately need replacing.
There always been an issue here with files reporting to be one thing but being another.
Trusting the file extension is amateur to say the least.
‘Magic strings’ in the header of the file is the usual way, but even then, you can’t really trust it.
What we really need is some way to guarantee that the contents are in a valid format as defined by the header, and haven’t been tampered with and signed as such, and embeds that in the file itself. Then I can take the contents of the file after the header, hash it and compare it with the embedded sig.
Back porting this to standard formats though would be a nightmare.
One of the tricks mentioned in here -- changing the extension to bypass a check -- works great on a ton of sites. Many sites won't let you upload a .gif file, but don't actually check the contents of the file, so just rename your .gif to a .jpg and voilà!
(you can sometimes get this to allow you to upload and execute server-side scripting pages too)
They're newer, but they aren't at all similar to what ships on Apple's OSes anymore. These days, the layers have flipped, and CoreFoundation is becoming a wrapper around swift-foundation.
CF functions toll-free bridge the CF types to their Foundation counterparts and invoke the corresponding Objective-C API, which is either implemented directly in Swift, or is a wrapper around the Swift function.
I'm sure it's still a work-in-progress, but their definitive goal is for the OSS swift-foundation codebase to be the same as what ships in their OSes, which was never the case with swift-corelibs-foundation.
It feels so ridiculous to me that a total stranger can send an iMessage message to me, including some attachment, and my phone will process that message in the kernel.
How hard would it be for apple to have a setting of "Only receive messages from mutual contacts", and require the stranger to first "request to be added to contacts" (a message which is tightly controlled, and obviously doesn't include a pdf file or webp or whatever), and have the apple imessage server drop all other messages from them until I accept.
Signal has "message requests". iMessage doesn't have "message requests", and receives messages in a unique path which goes through the kernel.
Like, sure the attacker could hit my Mom with a wrench and iMessage me a PDF exploit that way, but I feel like requiring physical access to one of my contact's phones raises the bar significantly over the current state of affairs.
It’s not being processed in the kernel - BlastDoor is a heavily-sandboxed user process. This attack chains together a bunch of exploits - including an encrypted BlastDoor sandbox bypass - in order to gain full control over a device.
That doesn't solve the core problem that untrusted data from an external source can compromise the system. Any person in your contacts can suffer from an exploit that lets an attacker target you. You don't want data from them to be whitelisted.
Signal has "message requests". iMessage doesn't have "message requests", and receives messages in a unique path which goes through the kernel.
Signal's message request, notably, also shows me the requester's avatar image. I don't know if that hits the kernel but it certainly hits code that as a category has suffered lots of security issues over the years. Which is to say: There's room for improvement all over!
Here in Argentina it's somewhat common to recibe social engineering attacks to steal the WhatsApp account. When they success, they send money request to all the contacts [1]. So once you add your Mom, they only need to convince her to give them access to her account, not the physical device.
Semi-relatedly: How does this look like for Whatsapp and Telegram? Can a stranger send me an attachment? Never saw this happen, I always receive short messages from scammers like "Hello" w/o attachments, but I wonder if this is possible.
> It feels so ridiculous to me that a total stranger can send an iMessage message to me, including some attachment, and my phone will process that message in the kernel.
ridiculous ?
Some good years ago, maybe. Since then, it is business as usual.
As long as the majority believes that Apple is secure, nothing to see here. /s
[+] [-] nneonneo|1 year ago|reply
Many of these tricks are non-public, meaning that NSO would have had to spend a huge amount of time and effort researching every single one of these. They probably have many more tricks they know about and haven't used. And, Apple could patch every one of them in a future update and roll back all of that work.
There's a good reason why these exploits are expensive and only sent to a limited number of high-value targets. NSO this time around also worked to "protect their IP" using encryption to hide part of their exploit chain, presumably in a bid to avoid losing yet more of their precious zero-days to researchers.
What they're doing is pretty gross (particularly the whole spying-on-journalists bit), but you have to admit the level of technological sophistication and persistence here is pretty impressive.
[+] [-] ogurechny|1 year ago|reply
Moreover, even if it's complex from the technical point of view, morally it's dead simple: hired programmer is the same as dirty grunt with a gun, and the leader delivering speeches, and the rocket engine scientist, and the data processing clerk, and everyone in between. They all serve the Order they believe in, the king of this world.
[+] [-] hulitu|1 year ago|reply
Unexpected ? You mean your jpeg file is not a jpeg. Why not throw an error message then ? Why does (iMessage) it have to open every byte thrown at it ?
[+] [-] botanical|1 year ago|reply
[+] [-] jsheard|1 year ago|reply
[+] [-] acdha|1 year ago|reply
[+] [-] myth_drannon|1 year ago|reply
Do they make it easier for actors to perform those activities? Not sure. I was never shopping for 0-day exploits. And some argue it's similar to gun laws in US, if it's easier to buy firearms, someone is more likely to use it. I just don't buy this comparison.
[+] [-] bri3d|1 year ago|reply
[+] [-] nxobject|1 year ago|reply
[+] [-] snailmailman|1 year ago|reply
Although it’s a bit extreme. It disables almost all web-fonts which breaks a lot of websites. (It’s easy to toggle this, but you have to do so per-site) It’s really not designed for the average user.
[+] [-] ipython|1 year ago|reply
[+] [-] mrguyorama|1 year ago|reply
Our adversaries don't have to hack anything at all, they don't even seem to have to ask nicely. There's zero chance that Putin doesn't let China know anything they want about the Trump admin, and Putin himself seems to get to dictate our country's policy now.
This has been the case among republicans for decades, and Mitch McConnell himself (and 6 others) spent the 4th of July 2018 in Moscow for christ's sake.
[+] [-] nxobject|1 year ago|reply
[+] [-] danilonc|1 year ago|reply
If so, which aspects would it block? The Apple support page mentions that most message attachment types are blocked, *except* for certain images, videos, and audio. Given this, would Lockdown Mode have prevented this exploit?
https://support.apple.com/en-us/105120
[+] [-] processunknown|1 year ago|reply
[+] [-] bawolff|1 year ago|reply
Lol, that got a chuckle out of me.
Amazing write up by google project zero as always.
[+] [-] cedws|1 year ago|reply
I don’t always buy into the $safelanguage cargo cult but come on, it’s apparent that memory unsafe languages are not appropriate for this purpose and desperately need replacing.
[+] [-] 01HNNWZ0MV43FF|1 year ago|reply
But I don't even buy into the cargo cult cargo cult https://www.righto.com/2025/01/its-time-to-abandon-cargo-cul...
[+] [-] junto|1 year ago|reply
Trusting the file extension is amateur to say the least.
‘Magic strings’ in the header of the file is the usual way, but even then, you can’t really trust it.
What we really need is some way to guarantee that the contents are in a valid format as defined by the header, and haven’t been tampered with and signed as such, and embeds that in the file itself. Then I can take the contents of the file after the header, hash it and compare it with the embedded sig.
Back porting this to standard formats though would be a nightmare.
[+] [-] unit149|1 year ago|reply
[deleted]
[+] [-] oguz-ismail|1 year ago|reply
[deleted]
[+] [-] qingcharles|1 year ago|reply
(you can sometimes get this to allow you to upload and execute server-side scripting pages too)
[+] [-] lukeh|1 year ago|reply
[+] [-] favorited|1 year ago|reply
CF functions toll-free bridge the CF types to their Foundation counterparts and invoke the corresponding Objective-C API, which is either implemented directly in Swift, or is a wrapper around the Swift function.
An Apple employee on the Foundation team posted an example of how calling `CFCalendarCreateWithIdentifier` works here: https://forums.swift.org/t/swift-foundation-now-available/73...
I'm sure it's still a work-in-progress, but their definitive goal is for the OSS swift-foundation codebase to be the same as what ships in their OSes, which was never the case with swift-corelibs-foundation.
Edit: I found a conference talk by some Apple folks that goes into more detail https://www.youtube.com/watch?v=wn6C_XEv1Mo
[+] [-] TheDong|1 year ago|reply
How hard would it be for apple to have a setting of "Only receive messages from mutual contacts", and require the stranger to first "request to be added to contacts" (a message which is tightly controlled, and obviously doesn't include a pdf file or webp or whatever), and have the apple imessage server drop all other messages from them until I accept.
Signal has "message requests". iMessage doesn't have "message requests", and receives messages in a unique path which goes through the kernel.
Like, sure the attacker could hit my Mom with a wrench and iMessage me a PDF exploit that way, but I feel like requiring physical access to one of my contact's phones raises the bar significantly over the current state of affairs.
[+] [-] nneonneo|1 year ago|reply
[+] [-] conradev|1 year ago|reply
[+] [-] kevin_thibedeau|1 year ago|reply
[+] [-] Scramblejams|1 year ago|reply
Signal's message request, notably, also shows me the requester's avatar image. I don't know if that hits the kernel but it certainly hits code that as a category has suffered lots of security issues over the years. Which is to say: There's room for improvement all over!
[+] [-] gus_massa|1 year ago|reply
[1] I got one 2 weeks ago. More details in https://news.ycombinator.com/item?id=43361556
[+] [-] yjftsjthsd-h|1 year ago|reply
Also, I really thought there was an option to somehow restrict media in messages, but I can't seem to find docs for that.
[+] [-] jakub_g|1 year ago|reply
[+] [-] saagarjha|1 year ago|reply
[+] [-] yapyap|1 year ago|reply
[+] [-] hulitu|1 year ago|reply
ridiculous ?
Some good years ago, maybe. Since then, it is business as usual.
As long as the majority believes that Apple is secure, nothing to see here. /s
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] raquelledger330|1 year ago|reply
[deleted]