from Hacker News

Blasting Past WebP - An analysis of the NSO BLASTPASS iMessage exploit

by el_duderino on 3/27/25, 12:49 PM with 124 comments

• by nneonneo on 3/27/25, 9:04 PM

  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.

• by botanical on 3/27/25, 2:45 PM

  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.

• by nxobject on 3/27/25, 6:30 PM

  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.

• by ipython on 3/27/25, 3:26 PM

  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?

• by danilonc on 3/27/25, 10:04 PM

  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?

  https://support.apple.com/en-us/105120

• by bawolff on 3/27/25, 10:46 PM

  > 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.

• by cedws on 3/27/25, 1:17 PM

  It’s always codecs.

  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.

• by qingcharles on 3/28/25, 6:30 PM

  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)

• by lukeh on 3/28/25, 12:35 AM

  Just FYI to the article, more recent versions of CF are available as part of swift-corelibs-foundation.

• by TheDong on 3/27/25, 2:40 PM

  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.