I’ll see if I can find the citation in the Platform Security document when I get home.
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.
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 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.
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.
[1] I got one 2 weeks ago. More details in https://news.ycombinator.com/item?id=43361556
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.
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
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.