HN Reader

517

250

Both approaches revealed the same conclusion: Memory Integrity Enforcement vastly reduces the exploitation strategies available to attackers. Though memory corruption bugs are usually interchangeable, MIE cut off so many exploit steps at a fundamental level that it was not possible to restore the chains by swapping in new bugs. Even with substantial effort, we could not rebuild any of these chains to work around MIE. The few memory corruption effects that remained are unreliable and don’t give attackers sufficient momentum to successfully exploit these bugs.

This is great, and a bit of a buried lede. Some of the economics of mercenary spyware depend on chains with interchangeable parts, and countermeasures targeting that property directly are interesting.

4 months agoby tptacek

> We believe memory safety protections need to be strictly synchronous, on by default, and working continuously.

FWIW, I presume this is "from experience"--rather than, from first principles, which is how it comes off--as this is NOT how their early kernel memory protections worked ;P. In 2015, with iOS 9, Apple released Kernel Patch Protection (KPP), which would verify that the kernel hadn't been modified asynchronously--and not even all that often, as I presume it was an expensive check--and panic if it detected corruption.

https://raw.githubusercontent.com/jakeajames/rootlessJB/mast...

> First let’s consider our worst enemy since iOS 9: KPP (Kernel Patch Protection). KPP keeps checking the kernel for changes every few minutes, when device isn’t busy.

> That “check every now and then” thing doesn’t sound too good for a security measure, and in fact a full bypass was released by Luca Todesco and it involves a design flaw. KPP does not prevent kernel patching; it just keeps checking for it and if one is caught, panics the kernel. However, since we can still patch, that opens up an opportunity for race conditions. If we do things fast enough and then revert, KPP won’t know anything ;)

4 months agoby saurik

> There has never been a successful, widespread malware attack against iPhone. The only system-level iOS attacks we observe in the wild come from mercenary spyware ... to target a very small number of specific individuals and their devices. Although the vast majority of users will never be targeted in this way..

Correct me if I'm wrong, but the spyware that has been developed certainly could be applied at scale at the push of a button with basic modification. They just have chosen not to at this time. I feel like this paragraph is drawing a bigger distinction than actually exists.

4 months agoby randyrand

This is really impressive.

It’s my understanding that this won’t protect you in the case where the attacker has a chance to try multiple times.

The approach would be something like: go out of bounds far enough to skip the directly adjacent object, or do a use after free with a lot of grooming, so that you get a a chance of getting a matching tag. The probability of getting a matching tag is 1/16.

But this post doesn’t provide enough details for me to be super confident about what I’m saying. Time will tell! If this is successful then the remaining exploit chains will have to rely on logic bugs, which would be super painful for the bad guys

4 months agoby pizlonator

> In 2018, we were the first in the industry to deploy Pointer Authentication Codes (PAC) in the A12 Bionic chip, to protect code flow integrity in the presence of memory corruption. The strong success of this defensive mechanism in increasing exploitation complexity left no doubt that the deep integration of software and hardware security would be key to addressing some of our greatest security challenges.

There have been multiple full-chain attacks since the introduction of PAC. It hasn’t been a meaningful attack deterrent because attackers keep finding PAC bypasses. This should give you pause as to how secure EMTE actually is.

4 months agoby philodeon

I think hackers are not ready for the idea that unhackable hardware might actually be here. Hardware that will never have an exploit found someday, never be jailbroken, never have piracy, outside of maybe nation-state attacks.

Xbox One, 2012? Never hacked.

Nintendo Switch 2, 2025? According to reverse engineers... flawlessly secure microkernel and secure monitor built over the Switch 1 generation. Meanwhile NVIDIA's boot code is formally verified this time, written in the same language (ADA SPARK) used for nuclear reactors and airplanes, on a custom RISC-V chip.

iPhone? iOS 17 and 18 have never been jailbroken; now we introduce MIE.

4 months agoby gjsman-1000

I'm sure Apple/ARM model is vastly more sophisticated, but skimming thru made me think of the Burroughs large system memory tagging architecture: https://en.wikipedia.org/wiki/Burroughs_large_systems_descri...

4 months agoby EvanAnderson

> ...attackers must not be able to predict tag values that the system will choose. We address this issue by frequently re-seeding the underlying pseudo-random generator used to select new tags.

This point could use more explanation. The fundamental problem here is the low entropy of the tags (only 4 bits). An attacker who randomly guesses the tags has 1/16 chance of success. That is not fixed by reseeding the PRNG. So I am not sure what they mean.

4 months agoby vayup

With EU chat control, the state will be on my device, having access to everything they want, decide what I can and cannot do. Once Google forces WEI on us, the whole web will get locked down. And secure boot and now MIE will make sure we can never take back our freedom.

4 months agoby bergfest

This is by far the best selling point of the new series of devices.

4 months agoby eptcyka

>Google took a great first step last year when they offered MTE to those who opt in to their program for at-risk users. But even for users who turn it on, the effectiveness of MTE on Android is limited by the lack of deep integration with the operating system that distinguishes Memory Integrity Enforcement and its use of EMTE on Apple silicon.

>With the introduction of the iPhone 17 lineup and iPhone Air, we’re excited to deliver Memory Integrity Enforcement: the industry’s first ever, comprehensive, always-on memory-safety protection covering key attack surfaces — including the kernel and over 70 userland processes — built on the Enhanced Memory Tagging Extension (EMTE) and supported by secure typed allocators and tag confidentiality protections.

Of course it is a little disappointing not to see GrapheneOS's efforts in implementing [1] and raising awareness [2] recognised by others but it is very encouraging to see Apple making a serious effort on this. Hopefully it spurs Google on to do the same in Pixel OS. It should also inspire confidence that GrapheneOS are generally among the leaders in creating a system that defends the device owner against unknown threats.

[1] https://grapheneos.org/releases#2023103000 [2] https://xcancel.com/GrapheneOS/status/1716946325277909087#m

4 months agoby ysnp

Full title is "Memory Integrity Enforcement: A complete vision for memory safety in Apple devices"

4 months agoby mrpippy

"There has never been a successful, widespread malware attack against iPhone. ..."

b your iphones BEEN pwned for YEARS and it was done in minutes LOL. gtfoh

with help from ChatGPT: Apple claims “never been a successful iPhone malware attack” Reality: WireLurker, Masque, XcodeGhost, YiSpecter, jailbreak 0-days, Pegasus/Predator/Reign 0-clicks.

iPhones pwned for yrs — by kids in pajamas

4 months agoby jahooligan

> ... With Enhanced MTE, we instead specify that accessing non-tagged memory from a tagged memory region requires knowing that region’s tag, ...

I got a bit confused when reading this. What does it mean to "know the tag" if the memory region is untagged?

4 months agoby LeakedCanary

>The presence of EMTE leaves Spectre V1 as one of the last avenues available to attackers to help guide their attacks, so we designed a completely novel mitigation that limits the effective reach of Spectre V1 leaks — at virtually zero CPU cost — and forces attackers to contend with type segregation. This mitigation makes it impractical for attackers to use Spectre V1, as they would typically need 25 or more V1 sequences to reach more than 95 percent exploitability rate — unless one of these sequences is related to the bug being exploited, following similar reasoning as our kalloc_type analysis.

Did they ever explain what that mitigation does?

4 months agoby pandalicious

> Arm published the Memory Tagging Extension (MTE) specification in 2019 as a tool for hardware to help find memory corruption bugs. MTE is, at its core, a memory tagging and tag-checking system, where every memory allocation is tagged with a secret; the hardware guarantees that later requests to access memory are granted only if the request contains the correct secret. If the secrets don’t match, the app crashes, and the event is logged. This allows developers to identify memory corruption bugs immediately as they occur.

4 months agoby cassepipe

Is this only available on iPhone 17 for now?

4 months agoby whitepoplar

How does this compare to CHERI?

4 months agoby brcmthrowaway

This is the opposite of fun computing. This is commercial computing who's only use case it making sure that people can send/receive money through their computers securely. I love being able to peek/poke inside and look at my processes ram, or patch the memory of an executable. All this sounds pretty impossible on Apple's locked down systems.

They're not so much general purpose computers anymore as they are locked down bank terminals.

4 months agoby superkuh

This looks amazing, I cannot wait to see how attackers pivot.

4 months agoby rs_rs_rs_rs_rs

This is great, since Oracle introduced SPARC ADI, into Solaris and their Linux SPARC workloads that I keep looking forward to "C Machines" becoming a common way to fix C language issues.

Unfortunately, like in many other cases, Intel botched their MPX design, only evolutions of MTE and CHERI are around.

4 months agoby pjmlp

The tagging mechanism reminds me of generational indices like https://floooh.github.io/2018/06/17/handles-vs-pointers.html, but I’m a bit out of my depth

4 months agoby rudedogg

1988 called and wants it memory tagging back https://www.devever.net/~hl/ppcas !

But yeah this was support for a the longest time by IBM basically. It's nice to see it's getting more widespread.

4 months agoby rdtsc

I wonder if these protections will apply to macOS as well.

4 months agoby akyuu

Is MTE restricted to the newest (17) iPhone models or does it work on the older ones too?

4 months agoby HackerNewt-doms

If we are checking every pointer at runtime how isn't this dog slow?

4 months agoby brcmthrowaway

More like Manufacturer Integrity Enforcement the way Apple makes things.

What’s the real benefit for regular/power users?

4 months agoby cmxch

Whether you like it or not, we are in an echo chamber. We will all benefit more rapidly once we figure out how to explain to an everyday Joe Blow why this technology is necessary in their daily life to get them hyped to upgrade their cracked XR/XS/11 barely hanging onto life support.

4 months agoby apaprocki

Meanwhile, Google is doing all it can to weaken Android safety by withholding images and patches, also by failing to fully segregate applications from each other. The evidence is linked below:

(1) AOSP isn't dead, but Google just landed a huge blow to custom ROM developers: https://www.androidauthority.com/google-not-killing-aosp-356...

(2) Privacy-Focused GrapheneOS Warns Google Is Locking Down Android: https://cyberinsider.com/privacy-focused-grapheneos-warns-go...

(3) GrapheneOS exposes Google's empty promises on Android security updates: https://piunikaweb.com/2025/09/08/grapheneos-google-security...

4 months agoby OutOfHere