Memory Integrity Enforcement Changes the Game on iOS
For journalists, lawyers, activists, politicians, executives, and other high-profile figures, the most relevant new feature from Apple's latest product launch wasn't highly advertised at all. Rather, it was announced in a September 9th post on the Apple Security Research blog.
Posted by Apple Security Engineering and Architecture (SEAR)
Memory Integrity Enforcement (MIE) is a security enhancement present in the the A19 System-on-Chip (SoC) series (iPhone 17, iPhone Air) which combines existing memory safety defenses in iOS with ARM's Memory Tagging Extension (MTE).
What is MTE?
MTE is an SoC hardware feature originally built by ARM as a debugging tool for app developers. Apps need to store data in your phone or computer's memory (RAM), and they reserve this space in RAM through a process called memory allocation. Unfortunately, these allocations are often not validated, and apps can inadvertently (or maliciously) access memory outside of what they've been allocated, through a variety of methods.
MTE is essentially a system which informs the developer and the operating system when this happens. When MTE is in use, every memory allocation is tagged with a secret. Then, the hardware ensures that every future request from an app to access that memory allocation is only granted if the request contains that same secret.
If the request doesn't contain the secret, for example because it came from an app other than the one that made the allocation in the first place, the app making the request is crashed and the event is logged.
The goal behind this was to allow developers to identify memory corruption bugs in their apps immediately as they occur. Without MTE, memory corruption can often occur silently in the background.
Microsoft and Google have both previously reported that 70% of all security vulnerabilities in their products stem from memory safety problems. Many of the high-profile vulnerabilities we have seen over the years, like Heartbleed in 2014 or the exploit in sudo published in 2020, are caused by a lack of memory safety as well.
Because of this, security researchers quickly realized that MTE could be used as an always-on tool to monitor and stop these security problems, not just as a debugging tool. The Google Pixel has been using MTE in some capacity since the Pixel 8 (more on this later).
Apple refers to the latest iteration of MTE (version 4) built in to the A19 SoC as "Enhanced MTE" or EMTE. However, for the purposes of this article we will just refer to it as MTE going forward.
Apple MTE/MIE vs. Android
Apple says they use MIE to protect "key attack surfaces — including the kernel and over 70 userland processes" — in their operating system. They also have made MIE available as an opt-in feature for app developers, meaning it is very likely the apps you use which need the highest levels of security (like Signal, or web browsers) will likely enable it soon.
This is a step above the typical configuration for MTE on Android, which also extends MTE as an opt-in feature to app developers, but uses it less substantially across the system. However, Android users in Google's Advanced Protection Program get MTE enabled on all apps on their device, and you can enable stricter MTE usage with USB debugging tools on any supported Android hardware as well.
(Update: Google's documentation actually claims MTE is automatically enabled only for "supported apps" when enrolled in the Advanced Protection Program)
The Android-based GrapheneOS also uses MTE to a far greater extent than stock Android or iOS here. GrapheneOS uses MTE in the system kernel, default system components, and their Vanadium web browser. They also let you easily enable MTE for any app with a settings toggle.
Why isn't MTE enabled everywhere?
MTE comes in two modes: synchronous and asynchronous. Synchronous mode is optimized for protection over performance, and is the only mode that AOSP claims can act "as a security mitigation" when enabled. Asynchronous mode is a higher performance option that can detect memory safety bugs, but will not necessarily crash the application immediately, and does not record some information about the memory being improperly accessed.
GrapheneOS enables MTE on the kernel in synchronous mode. For userland apps, they use synchronous mode for writes to memory, but asynchronous mode for reads. AOSP refers to this as asymmetric mode. GrapheneOS claims this provides a balance of good security with performance, but it is still not as robust as purely operating in synchronous mode.
iOS uses synchronous mode exclusively in areas where they use MTE. According to Apple:
In [asynchronous] mode, memory corruption doesn’t immediately raise an exception, leaving a race window open for attackers. We would not implement such a mechanism. We believe memory safety protections need to be strictly synchronous, on by default, and working continuously.
However, even though Apple has made synchronous MTE more efficient than the current implementation we see on Android phones, the performance impact of enabling synchronous MTE also appears to be the reason Apple has enabled MTE so selectively, compared to the broader approach taken in the Android world.
Additionally, MTE makes memory safety bugs much more visible to users. Because ordinarily memory corruption bugs will fail silently and are difficult for developers to notice in the first place, many apps on your device may regularly make memory unsafe calls without you noticing and without them having an impact on your system.
MTE does not create new bugs in apps where they don't already exist, but the likelihood that an existing bug causes more of a problem for the person using the app increases when MTE is enabled. For this reason, many users would be unlikely to put up with broadly enabled MTE right now, but hopefully this will become less of an issue over time as developers improve their apps, thanks to their new ability to debug with MTE themselves.
This is perhaps even more of an issue on iOS, where many apps have historically been developed in the memory unsafe Objective C programming language, than Android, which has historically used (the memory safe) Java. However, as most recent apps are now programmed in Swift across the Apple ecosystem, which is a memory safe programming language, this problem will also decrease over time.
How Memory Safety Impacts Mercenary Spyware
On mobile devices, all of this is of particular relevance to people targeted by mercenary spyware.
Because of how locked down most mobile devices are, there are very rarely single exploits that allow an attacker to completely compromise a device. Instead, what we often see are attackers chaining many smaller exploits together. If they are able to get even a small foothold in a vulnerable application, they can use that newfound slightly more privileged access to exploit another application, and so on and so on, until they eventually exploit their way to the highest levels of your operating system.
The high prevalence of memory safety problems (remember, 70%!) means many of the "smaller" exploits in these chains are memory corruption bugs. Bugs which could potentially be stopped by MTE.
In their research, Apple shared 6 real-world exploit chains that have been observed by their security researchers in the past, and how they fared against this new security system:
Some exploits were not prevented by these memory safety features. MTE is not a silver bullet and can't stop exploits unrelated to memory safety of course, and it also cannot prevent every type of memory safety bug, although Apple notes the ones it can't defend against are very rare, and even rarer can they be successfully used in an exploit chain.
However, across the board all of these exploit chains did rely on a memory safety exploit at some point, which was stopped by MTE (or their existing secure memory allocators in software, which are available on older devices without MTE). It's very likely that the majority of exploit chains currently in the wild or discovered in the past rely on similar memory safety bugs at some point as well.
The important thing to remember is that generally only one link in these exploit chains needs to fail in order for the entire system exploit to fail. As Apple's team puts it:
Inevitably, attackers must face MIE at a stage where their capabilities are still very limited, leaving few viable avenues for exploitation. This leads to fragile chains where breaking just one step is often enough to invalidate the entire exploit strategy. When that happens, most of the chain’s components can’t be reused, and the attackers have to restart exploit development with entirely new bugs.
As a result, the protections MTE gives against malware and spyware (like Pegasus) that rely on these exploit chains is enormous, by reducing the probability of a successful chain of attacks dramatically.
MTE/MIE vs. Lockdown Mode
A sentiment I have seen often among privacy advocates is that the current Lockdown Mode feature on Apple's operating systems provides comparable protections to MTE which (a previous iteration) has featured in the Google Pixel and other operating systems for years now.
Lockdown Mode is also very effective at preventing these exploit chains, but the approach that it takes is very different. Ultimately, Lockdown Mode works by reducing your attack surface dramatically, disabling apps and features you're unlikely to need in the name of security.
Imagine for example if there were a memory safety exploit in iMessage's link preview generator, which could be exploited by an attacker sending you a message with a link. By disabling link previews entirely in Lockdown Mode, that exploit is effectively stopped in its tracks.
However, that exploit could now also be blocked by MIE, and it would happen without needing to disable link previews, because MIE is always-on.
Even more importantly, if an exploit attempt happens and is blocked by MIE, that event can be very quickly detected by you, the operating system, or Apple. MTE would function as it's designed to and crash the app being exploited, and log that crash and details. This in turn will make it more likely you will receive a threat notification about the exploit, and that you will be notified quicker than you otherwise might. If the exploit is blocked simply because you didn't use link previews in the first place due to Lockdown Mode, that can be harder to spot after the fact.
If you are concerned about this type of threat, and you have to choose between Lockdown Mode and MIE, you want MIE every time.
Of course for the highest levels of security, these features should work in tandem (defense in depth) to dramatically reduce the likelihood of an exploit.
One thing Apple has not announced, but I hope they do soon, is a feature where Lockdown Mode enables MTE across your system and apps to a much broader degree. As previously discussed, MTE is only enabled selectively outside the kernel on iOS for performance and stability reasons.
However, Lockdown Mode users are far more likely to accept app crashes and performance drawbacks caused by MTE in the name of improved security. Enabling MTE (albeit asynchronous) more broadly is the default for Advanced Protection Program users on Android, so hopefully Apple takes a page from Google's book and improves Lockdown Mode in a similar way. Per-app toggles a la GrapheneOS would be even better.
Who It's For
I think this is an exciting step forward for iPhone users, and certainly the only thing I've personally been excited about when it comes to Apple's latest product launch.
While MTE is a hardware feature that's exclusive to the iPhone 17 series and iPhone Air for now, some of the other improvements Apple includes in "Memory Integrity Enforcement" are implemented in software and accessible to older devices.
Most casual users are not exploited by Pegasus and the like, and mobile devices already provide a very high level of malware protection compared to traditional operating systems. If you aren't publishing content or are likely to be targeted, MIE will improve your security posture when you upgrade, but it's not necessarily a reason to rush out and buy a new phone.
However, this improvement provides actual, significant value to people who do face these threats. And the likelihood that you could face these threats should not be understated either.
In some regions exploits are very broadly deployed on the internet, to target people looking for political activism resources. And journalists, lawyers, and politicians are all regularly targeted by mercenary spyware as well.
The exploit chains used by mercenary spyware are also the same as the ones used by commercial spyware and data hacking kits, like Cellebrite and GrayKey. These tools are often in the hands of low-level law enforcement employees or even outside of government, and are regularly abused.
If these threats could cause you significant harm, this may well be a great reason to upgrade your phone.
Subscriber Discussion