Hacker News Reader

Comment by TheDong | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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

Oh!

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

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

No.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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?

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.

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/

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

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!

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

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.

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

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.

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

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.

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.

About Lockdown Mode https://support.apple.com/en-gb/105120

Harden your iPhone from a cyberattack with Lockdown Mode https://support.apple.com/en-gb/guide/iphone/iph049680987/io...

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"

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.

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

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

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.

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

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.

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

I mean yeah but the real problem is ACE through iMessage

> 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

Reply on news.ycombinator.com