alt.hn

3/27/2025 at 12:49:44 PM

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

 https://googleprojectzero.blogspot.com/2025/03/blasting-past-webp.html

by el_duderino

3/27/2025 at 9:04:28 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 nneonneo

3/27/2025 at 11:33:45 PM

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.

by ogurechny

3/28/2025 at 12:49:54 AM

> It's like saying [...]

"Proof by analogy is fraud" - Bjarne Stroustrup

by heavensteeth

3/28/2025 at 5:39:49 AM

people do like true crime shows so that's that

by areyourllySorry

3/28/2025 at 2:10:00 PM

“True crime” is just fashionable slang for “pulp fiction” and “tabloid journalism”, so there's nothing new here.

by ogurechny

3/28/2025 at 10:20:38 AM

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

by hulitu

3/27/2025 at 2:45:20 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 botanical

3/27/2025 at 2:49:34 PM

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.

by jsheard

3/27/2025 at 3:10:33 PM

[flagged]

by adhamsalama

3/27/2025 at 3:16:48 PM

[flagged]

by fartfeatures

3/27/2025 at 3:45:21 PM

This is a bad argument. Even the most authoritarian and vile government atrocities come wrapped in veils of excuses, plausible deniability, etc etc. It’s one of the more creative government exercises in everything from reeducation camps, dubious sterilization programs, false flags, anti-terrorism, settling, and even justifying your ideology with bogus science like racial biology. You sprinkle doubt and narrative for your own approval ratings, for other nations, the media, etc. Even if your goal is genocide. Not even saying that’s Netanyahus goal, just refuting this simplistic Disney villain classification of genocide.

by klabb3

3/27/2025 at 3:52:01 PM

If I must guess what Netanyahus goal is, it's to stay out of prison. By any means.

by actionfromafar

3/27/2025 at 3:38:16 PM

Does it matter much (except in a technical, judicial way) what exactly they are pursuing? The facts on the ground are horrible.

by actionfromafar

3/27/2025 at 3:21:06 PM

Having a policy directed at genocide does not mean not exercising restraints for various reasons, including the reason of having a certain level of deniability around the goal.

Your argument is grounded in conflating two unrelated propositions.

by dragonwriter

3/27/2025 at 3:31:19 PM

[flagged]

by adhamsalama

3/27/2025 at 4:38:02 PM

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.

by acdha

3/27/2025 at 2:55:59 PM

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.

by myth_drannon

3/27/2025 at 4:33:09 PM

How does one of these points relate to the other in any capacity?

by bri3d

3/27/2025 at 6:30:38 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 nxobject

3/27/2025 at 6:38:34 PM

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.

by snailmailman

3/27/2025 at 8:48:53 PM

I think lockdown mode is fine for most people. Yes, some websites are broken because they assume their font always loads, but I've never really felt bothered by issues like that. Then again, I've never really used iCloud, so maybe I'm missing out on something there.

Many edge cases covered, like not being able to add configuration profile, are fixes to insecure defaults IMO.

by jeroenhd

3/27/2025 at 3:26:19 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 ipython

3/27/2025 at 5:48:33 PM

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.

by mrguyorama

3/27/2025 at 6:28:32 PM

Essentially relying on COTS software with likely exploit bounties targeting dozens of high-value targets other than the USG – what could go wrong?

by nxobject

3/27/2025 at 8:30:33 PM

Do you think special custom software, developed under government contract, would be any more secure?

My experience with software procured by the government is that it's not winning any awards for best software.

by michaelt

3/28/2025 at 3:57:03 AM

I think it's more so that those aren't as readily available as signal to get at the exploits, and it would be on gov provided devices not on everyday phones that people install just whatever on and then decide to set up a chat group and talk about blowing up brown people whimsically.

by EasyMark

3/28/2025 at 2:18:48 PM

Simply rebuilding software for limited distribution makes it more secure.

by outer_web

3/27/2025 at 10:04:27 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 danilonc

3/28/2025 at 1:43:36 AM

Do they even specify which types are blocked?

by processunknown

3/27/2025 at 10:46:08 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 bawolff

3/27/2025 at 1:17:36 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 cedws

3/27/2025 at 4:36:04 PM

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.

by junto

3/27/2025 at 5:03:28 PM

So an attacker should sign their malicious webp or jpeg files beforehand? That doesn’t help at all.

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.

by klabb3

3/27/2025 at 2:29:33 PM

[dead]

by unit149

3/27/2025 at 1:20:11 PM

[flagged]

by oguz-ismail

3/27/2025 at 1:48:50 PM

JPEG-XL is the future everything else is forced/shilled to the extreme without considering its merits. Don't even get me started how some website will show a URL to a JPEG and when you try to save it, it tries to save a WebP.

WebP suffers from excessive generation loss for a modern codec.

https://www.youtube.com/watch?v=qc2DvJpXh-A

by greenavocado

3/27/2025 at 2:31:32 PM

I find it curious how the AVIF deterioration resembles an old physical photograph. I wonder why that is. Do you know of more comparisons like this? I’d like to observe the effect further but don’t have the availability right now to pursue it.

by latexr

3/27/2025 at 2:37:32 PM

It looks like a straight-up bug in chroma quantization. libaom has never had good chroma RDO tuning.

by derf_

3/27/2025 at 8:50:53 PM

JPEG-XL works in even fewer programs than WebP does, though, which is almost impressive given WebP's reputation.

by jeroenhd

3/27/2025 at 2:01:41 PM

Yeah but Google goes out of their way to kill jpeg-xl, they really deserve to lose chrome

by dev1ycan

3/27/2025 at 1:32:05 PM

https://github.com/google/wuffs <-- DSL created explicitly for wrangling fileformats safely

by actionfromafar

3/27/2025 at 3:02:36 PM

And - https://github.com/google/wuffs/blob/main/doc/std/image-deco... with a webp implementation.

by yjftsjthsd-h

3/27/2025 at 5:04:27 PM

From after this exploit was found.

by tedunangst

3/27/2025 at 5:23:22 PM

Oh, you're right; I managed to miss that the vuln was from 2023. I do wonder how widely used the wuffs version is now that it exists, though.

by yjftsjthsd-h

3/27/2025 at 6:12:38 PM

wuffs has the same story as rlbox in firefox. They made the tool, they proved it could work with one library, and then proceeded to ignore it for all the other libraries.

https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...

by tedunangst

3/27/2025 at 7:26:39 PM

I wouldn't be surprised if some security team at Apple was cooking up a bespoke DSL as well – NIH seems to happen once in a while.

by nxobject

3/27/2025 at 9:18:24 PM

They have some kind of safe dialect of C that they use for iBoot. Also they're increasingly using Swift for things.

by pcwalton

3/27/2025 at 1:40:57 PM

Thank you, I spent a few minutes failing to google this.

by jonatron

3/27/2025 at 3:33:54 PM

I always do that, sometimes I succeed, sometimes I fail! :-D

by actionfromafar

3/27/2025 at 1:50:44 PM

Written in C? Unless I'm missing something this isn't better than other unsafe options

by internetter

3/27/2025 at 1:55:36 PM

From the Wuffs readme:

> Wuffs the Language is safe with respect to buffer overflows, integer arithmetic overflows and null pointer dereferences. A key difference between Wuffs and other memory-safe languages is that all such checks are done at compile time, not at run time. If it compiles, it is safe, with respect to those three bug classes.

> […]

> Wuffs code is hermetic and can only compute (e.g. convert "compressed bytes" to "decompressed bytes"). It cannot make any syscalls (e.g. it has no ambient authority to read your files), implying that it cannot allocate or free memory (and is therefore trivially safe against things like memory leaks, use-after-frees and double-frees).

by codetrotter

3/27/2025 at 2:23:02 PM

Good compression for web images. I converted the images on my website to webp and saw a huge reduction in filesizes with virtually no loss in quality, but it still keeps an alpha channel unlike jpg

by voidUpdate

3/27/2025 at 3:32:36 PM

[flagged]

by oguz-ismail

3/27/2025 at 3:59:54 PM

> Storage is cheap, bandwidth is cheap, so who cares?

This is a ridiculous assertion.

They're both cheap in the commercial sense, but neither cheap nor infinite in the UX sense. Time and space matter in the real world.

Google wouldn't have created WebP if there was no tangible, measurable cost benefit to using it over some alternative. Same goes for H.264 or HEVC or AV1, at scale bandwidth and storage are far from cheap. See the article on the FP today about Google's double-digit EXAbyte storage clusters with 50TB/s read volume each as a real-world example, there's nothing cheap about that.

by web007

3/27/2025 at 3:39:01 PM

Depending on where you are and what mobile data plan you have, bandwidth is not always cheap. And I don't see the problem in trying to reduce the amount of data sent, which is one of the reasons I don't fill my website with megabytes of javascript libraries

by voidUpdate

3/27/2025 at 3:40:48 PM

> Storage is cheap, bandwidth is cheap, so who cares?

That may be true sometimes, but it isn't true all the time. Even if it's "cheap", smaller files load faster.

by yjftsjthsd-h

3/27/2025 at 1:24:44 PM

Alpha channels in a lossy image? Animated lossy image?

Regardless, things like this really help explain the hesitation behind adopting jpegxl.

I'm a big fan of AVIF files though.

by adzm

3/27/2025 at 1:29:53 PM

>Alpha channels in a lossy image?

Why?

>Animated lossy image?

It's called a video

by oguz-ismail

3/27/2025 at 1:33:45 PM

There are loads of uses for alpha channels. Anything you want layered with other graphics without being surrounded by an ugly black square...

There are loads of uses for lossy images. Pretty much any image is probably best transmitted lossy, because the saved ram, CPU, bandwidth, load time is huge compared to the usually unnoticeable quality degregation.

So it stands to reason there are lots of uses for lossy alpha images.

by londons_explore

3/27/2025 at 1:39:40 PM

>usually unnoticeable quality degregation

Dunno I think it'd be too messy

by oguz-ismail

3/27/2025 at 1:29:52 PM

No serious alternative? Apple could easily make a safe image handling library in Swift.

by dlachausse

3/27/2025 at 2:00:02 PM

Swift is underrated, I wish it had more traction outside Apples ecosystem.

Easy to learn, fast and memory safe without a GC.

by ChocolateGod

3/27/2025 at 5:32:19 PM

Automatic reference counting is a form of GC, and optimized versions of it end up very similar to tracing GC: https://web.eecs.umich.edu/~weimerw/2012-4610/reading/bacon-...

(except that ARC can't handle cyclic graphs)

by necubi

3/27/2025 at 7:35:07 PM

And it's more deterministic without random pauses.

by IshKebab

3/27/2025 at 10:23:11 PM

The reference counting also causes pauses when freeing large object graphs. Fully concurrent GC does not cause any pauses and it's more efficient. It also has less memory overhead per object.

by pebal

3/28/2025 at 2:26:21 AM

What GC doesn't cause any pauses?

I know of some who claim to be "pauseless", but it's b.s. marketing. They also tend to be memory hogs that don't play well with other processes in low memory environments with the kind of allocation behavior seen in UI applications.

And of course, the issue is not only stop-the-world pauses (though those are especially bad), but any pause in any thread period. A RC system lets you have consistent, predictable performance and often can be completely eliminated through static analysis.

by Aloisius

3/28/2025 at 3:10:38 AM

Here you have a GC engine that is completely pauseless: https://github.com/pebal/sgcl

It is available as a C++ library, so you can easily compare its performance to the reference counting.

by pebal

3/28/2025 at 8:24:35 AM

That's why I said random pauses.

RAII can also cause pauses when freeing large object graphs. It's not unique to RC. However in practice it's usually much less of an issue than GC pauses. It's only been an issue for me once in my entire career.

by IshKebab

3/29/2025 at 7:52:39 AM

In C++ one can combine RAII with allocators in order to avoid calling alloc/frees in latency critical paths.

by il-b

3/27/2025 at 3:01:42 PM

It’s very slowly starting to get a bit of traction outside of Apple now that the language has filled many gaps and Foundation is being re-written to be Swift-first and open source. I expect growth of adoption to continue to be slow for the time being though.

by cosmic_cheese

3/28/2025 at 6:30:23 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 qingcharles

3/28/2025 at 12:35:18 AM

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

by lukeh

3/28/2025 at 1:14:17 AM

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.

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

by favorited

3/28/2025 at 7:49:08 AM

swift-foundation will never be the code that ships on the OS, mostly because they always have some private bits they won't expose. Come back when URL bookmarks are part of the open source dump.

by saagarjha

3/28/2025 at 9:30:58 PM

Of course the entire binary will never be the same, but the implementation of (for example) DateComponents.swift in OSS swift-foundation will be the same implementation that is used to build the OS library.

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.

by favorited

3/30/2025 at 6:29:24 AM

The code in CoreFoundation.framework was basically built out of that repo, though.

by saagarjha

3/28/2025 at 8:44:44 AM

Sure, but that’s not relevant in the timeline of the OP.

by lukeh

3/27/2025 at 2:40:28 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.

by TheDong

3/27/2025 at 3:18:59 PM

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.

by nneonneo

3/27/2025 at 4:11:18 PM

And this is one of many reasons why analyses like this provide so much value. It's fascinating that the actual sandbox bypass in this case is so carefully protected. If that sandbox bypass code could be decrypted and reverse-engineered, it could point to the actual vulnerability being exploited, which could then be fixed.

by JoshTriplett

3/27/2025 at 6:41:09 PM

I can already guess without looking that the sandbox is excellent except that oops there's a few edge cases that were MUST FIX, so, we had to cut a small hole in it. The people who understand how difficult this is to do properly built the actual sandbox which will be fine, the ragged hole cut in it (and exploited) was implemented by somebody for whom the sandbox is just another annoying thing they need to work around to get their job done and they don't care that they made it worthless.

by tialaramex

3/27/2025 at 9:49:13 PM

I’m sure they care that they spent all that time working around an annoying thing — they don’t want to waste time finding a new workaround when this one is patched. And they’d like to re-use it in other exploit chains, so why not obfuscate it to the best of their ability?

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.

by chatmasta

3/28/2025 at 12:59:19 AM

Maybe I was unclear, I think the exploited hole was cut by the vendor.

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.

by tialaramex

3/28/2025 at 7:37:06 AM

What makes you think this? Typically this has not been the case.

by saagarjha

3/27/2025 at 4:04:13 PM

A total stranger can send radio waves at you and your phone will process them on a processor close to the kernel: https://googleprojectzero.blogspot.com/2017/09/over-air-vol-...

by conradev

3/27/2025 at 6:30:02 PM

I’m pretty sure that the modem on modern iPhones can only access a small memory address range and that this is cryptographically enforced by the Secure Enclave. So an exploit in modemland doesn’t allow reading unencrypted info (since everything today is encrypted at the application level).

I’ll see if I can find the citation in the Platform Security document when I get home.

by ls612

3/27/2025 at 7:45:59 PM

The Secure Enclave is nowhere between the AP and the Broadcom chip.

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.

by conradev

3/27/2025 at 8:36:43 PM

Qualcomm, not Broadcom, and the linked article series doesn't discuss the IOMMU at all - it's not related to this exploit as far as anybody knows.

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.

by bri3d

3/27/2025 at 10:47:13 PM

No, it should be there. From the link:

> 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

by conradev

3/27/2025 at 11:02:14 PM

Oh!

The ancient 2017 WiFi article - I see now; I thought you were referring to the OP's NSO group exploit.

by bri3d

3/27/2025 at 11:53:05 PM

These changes I’m describing occurred after 2017, likely at least in part due to this vulnerability.

by ls612

3/28/2025 at 7:41:44 AM

No.

by saagarjha

3/27/2025 at 7:14:28 PM

I don't think there's anything cryptographic about the baseband communication on an iPhone, or that they're connected through the Secure Enclave. I think they're just PCIe endpoints with IOMMU (which is fine as long as the IOMMU is configured correctly). My understanding is that for most iPhones, a repair shop can replace the baseband hardware itself without the phone noticing, which also suggests that there's no pairing or hardware trust model / key exchange between the AP and baseband.

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

by bri3d

3/27/2025 at 5:40:58 PM

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!

by Scramblejams

3/28/2025 at 10:43:23 AM

That avatar thing is exploitable on discord, at least. Don't recall the specifics, just keywords.

by genewitch

3/29/2025 at 9:40:39 AM

You might be thinking of the minor Cloudflare exploit where the attacker can send you a message, then see on which Cloudflare PoP their profile image got cached.

by immibis

3/27/2025 at 3:04:46 PM

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.

by kevin_thibedeau

3/27/2025 at 3:16:03 PM

I want to respond to the strongest interpretation of your comment, but no matter how I read it, all I'm getting is "defense in depth is meaningless".

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.

by TheDong

3/27/2025 at 4:10:09 PM

This is all a fuckup by the responsible vendor Apple who isn't comprehensively using commercial static analyzers that can easily detect this sort of buffer overflow. They both have billions in cash to pay for dedicated engineering teams to do this work.

by kevin_thibedeau

3/27/2025 at 6:22:38 PM

But the initial security issue was in libwebp, which is made by Google, and surely Google had already fuzzed it and run all the available static analyzers in the world.

Static analyzers are nice to have, but they can't warn of every issue out there.

by galad87

3/27/2025 at 8:30:47 PM

The initial security design failure was inventing lossless WebP, which is a completely different format from lossy WebP, which means the library has double the code for double the attack surface.

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.

by astrange

3/28/2025 at 7:43:35 AM

Maybe because going "I think WebP was a bad idea" when its implementation has the same bugs in it that every other image parser has is not a very useful comment to make.

by saagarjha

3/28/2025 at 2:23:37 PM

I think there’s a stronger form of the argument: image formats are expensive to create and secure, and that should have factored into WebP adoption given its marginal benefits.

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.

by acdha

3/28/2025 at 7:16:05 PM

Yes, I think we’re going to see this moving forward. The tools are in place to make this possible.

by saagarjha

3/28/2025 at 7:08:08 PM

No, it's a bad idea because they based it on a video codec and then released a much better video codec a year later but couldn't update it.

It's not better enough than JPEG to be worth existing.

by astrange

3/28/2025 at 7:14:09 PM

The same could be said for half the formats Apple ships: HEIF/HEVC, for example. Or even LZFSE: who asked for an algorithm that compresses worse, slower?

by saagarjha

3/28/2025 at 7:55:33 PM

It could but HEVC is actually an open standard, whereas WebP is a proprietary codec they bought and then released with no community feedback. (That's why the next VPx codec was better.)

Also HEIF actually has useful features, it supports HDR!

AVIF is certainly better though. I only feel positively about AVIF and JPEGXL.

by astrange

3/28/2025 at 2:49:08 AM

The Isosceles blog post[0] on the initial webp exploit, linked by the article, says:

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

[0] https://blog.isosceles.com/the-webp-0day/

by ikmckenz

3/27/2025 at 5:30:10 PM

Are you saying it's bad that Apple's using an open source solution, or that Clang Static Analyzer (built into Xcode) is bad specifically? https://www.youtube.com/watch?v=jajgCfkLNdk

by CharlesW

3/27/2025 at 3:48:17 PM

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.

[1] I got one 2 weeks ago. More details in https://news.ycombinator.com/item?id=43361556

by gus_massa

3/27/2025 at 2:58:53 PM

I wonder if "Filter messages from unknown senders" ( https://support.apple.com/guide/iphone/block-filter-and-repo... ) skips any processing.

Also, I really thought there was an option to somehow restrict media in messages, but I can't seem to find docs for that.

by yjftsjthsd-h

3/27/2025 at 3:20:46 PM

I believe enabling lockdown mode disables media previews in messages to prevent exactly these kinds of attacks, among other mitigations.

by aeontech

3/27/2025 at 3:07:51 PM

I'd feel much safer if the message was filtered at the server, not on my device.

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.

by TheDong

3/27/2025 at 5:44:05 PM

If the message is filtered at the server, it adds a lot of requirements you might not actually want:

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.

by toast0

3/27/2025 at 6:56:04 PM

I have been running lockdown mode for a while now and it can be painful for shopping but usable. You can disable it on a per site basis in Safari. Stolen device protection mode on also.

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.

by instagib

3/27/2025 at 3:41:12 PM

If Apple advertised a toggle that protects you completely but let the users decide the mitigations, it would severely damage its standing as a secure phone when it would inevitability get exploited. (Targeted) Apple users are usually not technical.

by larfus

3/27/2025 at 4:03:00 PM

You're saying that having "enable full lockdown mode", but _also_ having a toggle in iMessage settings for "Disable automatic display of media attachments" would be less secure?

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"

by TheDong

3/27/2025 at 7:46:05 PM

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.

by jakub_g

3/28/2025 at 7:44:43 AM

Sure, they can just send you an image. People who are scamming you aren't trying to burn 0 days.

by saagarjha

3/28/2025 at 7:35:59 AM

That's Lockdown mode. Also the message is not processed in the kernel.

by saagarjha

3/28/2025 at 10:27:05 AM

I've been using an iphone in lockdown mode for a while now, simply to disable a number of the poor security design choices Apple made.

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.

by dfawcus

3/28/2025 at 10:32:48 AM

Note that 2G is generally considered to be insecure (hence why it's disabled).

by saagarjha

3/28/2025 at 9:03:54 PM

Insecure how? The fact that someone could listen in to the phone call is (to me) largely irrelevant.

The real point being that it still has wider coverage in remote parts (of the UK), and draws less power.

by dfawcus

3/30/2025 at 6:30:48 AM

I don’t think most people would agree with your risk profile.

by saagarjha

3/27/2025 at 3:13:40 PM

I mean yeah but the real problem is ACE through iMessage

by yapyap

3/28/2025 at 9:40:06 AM

> 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

by hulitu

3/29/2025 at 3:43:14 PM

[dead]

by raquelledger330