Blasting Past WebP - An analysis of the NSO BLASTPASS iMessage exploit
googleprojectzero.blogspot.com
googleprojectzero.blogspot.com
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.
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.
"Proof by analogy is fraud" - Bjarne Stroustrup
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 ?
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.
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.
Many edge cases covered, like not being able to add configuration profile, are fixes to insecure defaults IMO.
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.
My experience with software procured by the government is that it's not winning any awards for best software.
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?
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.
But I don't even buy into the cargo cult cargo cult https://www.righto.com/2025/01/its-time-to-abandon-cargo-cul...
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.
No, I agree very much with parent here. I think compile time safety and rust fanatism has been oversold, but let’s face it this is the perfect use case, a match made in heaven.
Decoding in C/C++ has a Dunning Kruger deceitful appeal. People think they can do it, but time and time again, we find critical holes, even when written by 10x wizard Nobel laureate engineers.
At the same time, decoding needs to be crazy performant. So, this is the moment to shine for languages like Rust. I am 100% in support of this.
(you can sometimes get this to allow you to upload and execute server-side scripting pages too)
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
Going forward, the bedrock of both the OSS package and the platform [Core]Foundation.framework will be swift-foundation. This is distinct from SCF, which was a novel Swift wrapper around CoreFoundation.
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.
Also, I really thought there was an option to somehow restrict media in messages, but I can't seem to find docs for that.
It's not clear how much or little of the message is processed, but it's clear attacker controlled data lands on my device.
> an option to somehow restrict media in messages
"LockdownMode", which removes attachments, but also turns off JIT in your browser, and removes the ability to install configuration profiles, among other things.
For some reason apple has a security setting that restricts iMessage media, but to opt into that, you also have to make your web browser useless and have GPS stripped from your photos, idk, apparently "enable" toggles are expensive and they could only afford a single one for like 10 unrelated security features.
Harden your iPhone from a cyberattack with Lockdown Mode https://support.apple.com/en-gb/guide/iphone/iph049680987/io...
The poster two above me couldn't find the setting because they looked in iMessage settings for an iMessage security feature, not for lockdown.
And I would turn on the imessage security feature in a heartbeat if it didn't break my browser, and a custom font I have to install via a configuration profile.
I feel like these are both good counter examples to "adding options obviously means people won't use it"
1) the server needs to have your contact list, in a form where it can query if user X is in user Y's contacts, in order to do filtering.
1a) If you really meant mutual contacts, the server needs to process contact lists from both parties together. If you are ok with getting a media message from someone who doesn't have you in their contacts but you have them in yours, this one is skipped.
1b) The server needs to know who the message is from and who it is to at the same time.
2) If you're ok with a text message, but not a media message, the server needs to know the difference between text and media messages.
3) I'm not familiar with the details of iMessage, but often messengers use a pattern where a media message is really a link to a media file on some blob server, optionally with some text. If you want the server to remove the link to the file, but allow the text, the server would need to be able to see and process that.
Again, I'm not familiar with how iMessage operates, and some of these may already be aspects of the service, but they're not strict requirements of a messenger service, and the less the server knows about messages and contacts, etc, the more privacy users have from the service.
To do it and enable side loading you need to do two resets to enable developer mode. I am able to enable a configuration profile also without a problem. It was installed and enabled pre-lockdown and re-enabled in lockdown mode. I just enabled location services for camera and it correctly gps tagged my photo.
The only pain points I have are if someone texts me something other than a picture which is a lockdown feature. For some reason usps tracking webpage fails on all browsers except on Firefox/Firefox focus browser. A few heavily tracked apps or shopping websites don’t like it but tolerate it. Pain: You cannot search your iMessages. I can turn lockdown off on a per app basis excluding iMessage also but have not needed to.
Do you also think apple shouldn't have bothered building blastdoor sandboxing, since all the code running in the sandbox should just be flawless code with no security issues anyway? Is ASLR not worth it since the core problem is that there are memory safety bugs, and so we should instead just write it all in rust and not do ASLR or such?
I'm not saying we shouldn't fix security issues, just suggesting a defense in depth mechanism that in practice seems like it'd make most people a lot safer.
Static analyzers are nice to have, but they can't warn of every issue out there.
I am skeptical inventing any kind of WebP was a good idea, but I know the inventor and he got mad at me last time I said that, so I won't.
The lesson I hope was learned is that nobody should be writing new parsers in an unsafe language. WebP is old enough that it was defensible at the time but everyone should have a “no new C/C++” policy for internet-facing code.
It's not better enough than JPEG to be worth existing.
Also HEIF actually has useful features, it supports HDR!
AVIF is certainly better though. I only feel positively about AVIF and JPEGXL.
> Google's OSS-Fuzz project has fuzzed hundreds of open source libraries for many years now, including libwebp and many other image decoding libraries. It's possible to look in full detail at the code coverage for OSS-Fuzz projects, and it's clear that lossless support for WebP was being fuzzed extensively… In fact one of the first things that Google did after the WebP 0day was fixed was to release a new fuzzer specifically for the Huffman routines in WebP. I tried running this fuzzer for a bit (with a bit of backporting required due to API changes) and it predictably did not find CVE-2023-4863… This bug also shows that we have an over-reliance on fuzzing for security assurance of complex parser code. Fuzzing is great, but we know that there are many serious security issues that aren't easy to fuzz.
So perhaps it’s not so simple as throwing a fuzzer at it.
You do highlight an important difference between the mindset of an attacker and a defender. The attacker only needs to be right once, and then they can move onto the next phase of the attack. That’s why they don’t bother “understanding it properly” beyond the perspective of attacking it. A medieval siege unit understands the weak points of castle walls, and how to operate a catapult, but they don’t care about the intricacies of stone masonry beyond what’s necessary for knocking down a wall.
You hire team A of excellent security people to build you an impenetrable barrier. They do a sterling job and are appropriately rewarded.
Then you realise oops, the new feature we're very proud of can't work with that impenetrable barrier. Hey, Jim, we need the feature to work ASAP, figure out a way to do that without removing the expensive barrier. And so of course Jim cuts a hole in it.
[1] I got one 2 weeks ago. More details in https://news.ycombinator.com/item?id=43361556
I’ll see if I can find the citation in the Platform Security document when I get home.
Post-boot communication with the host processor on Qualcomm-baseband iPhones (iPhone 12-16 non-E) is the usual Qualcomm QMI/QMUX over PCIe (CommCenter uses libPCITransport to send messages).
The Platform Security document just says "On devices with cellular access, a cellular baseband subsystem performs additional secure booting using signed software and keys verified by the baseband processor" and "Each network processor is on its own isolated PCIe bus. An Input/ Output Memory Management Unit (IOMMU) on each PCIe bus further limits the network processor’s DMA access to only memory and resources containing its network packets and control structures."
The application processor has an IOMMU and the kernel uses it to restrict what the Broadcom chip has access to, and the linked article series discusses exploiting the IOMMU. There is more detail in the Project Zero write-up than Apple's own PDF.
The actual solution here is to remove the insecure Broadcom chip entirely, which is what Apple ultimately did. PCI-e and MMIO are quite risky, but ultimately necessary for performance. I think PinePhone series talks to their Broadcom chip over USB, which is a lot more secure, but the performance is worse.
Maybe you're thinking of the "Operation Triangulation" exploit chain, which used write access to a bizarre mapped area that seems to relate to cache debugging, in order to patch the page table.
> Lastly, in the final blog post we’ll explore the iPhone’s host isolation mechanisms, research the ways in which the Wi-Fi chip interacts with the host, and develop a fully-fledged exploit allowing attackers to gain complete control over the iOS kernel over-the-air, requiring no user interaction.
Which is referring to this link: https://googleprojectzero.blogspot.com/2017/10/over-air-vol-...
That link is the one I am summarizing:
> Sufficient isolation for DMA-capable components can be achieved by partitioning the visible memory space available to the peripheral using a dedicated hardware component - an I/O Memory Management Unit (IOMMU).
Apple uses Qualcomm chips for cellular modems, and they use Broadcom for Wi-Fi.
edit: I might have linked the original post incorrectly, there are many volumes and parts
The ancient 2017 WiFi article - I see now; I thought you were referring to the OP's NSO group exploit.
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!
One thing I just noticed this last week after upgrading to 18.x is that lockdown mode also disables RCS. I found I couldn't enable RCS, so turned lockdown mode off, found RCS now worked, then turned lockdown back on.
I can live without RCS mode.
For me, the one real annoyance of lockdown mode is that it disables 2G connectivity. Oh well, I guess one can carry a second 2G capable feature phone.
The real point being that it still has wider coverage in remote parts (of the UK), and draws less power.
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