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

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

[flagged]

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.

Simply rebuilding software for limited distribution makes it more secure.

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.

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

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

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

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.

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

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

>Good compression for web images

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

>alpha channel

Share an example from your website. I really want to see what it looks like

Only if they implement jpegxl decoders in C/C++. I would really hope that isn't the case.

Seems like they agree: https://github.com/mozilla/standards-positions/pull/1064

>Alpha channels in a lossy image?

Why?

>Animated lossy image?

It's called a video

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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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