Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Integrity Enforcement

security.apple.com

Post reply on HN
Print view View original

241–250 of 259 posts

Re: Memory Integrity Enforcement

#241

Post by superkuh »

snowwrestler wrote: post #205
superkuh wrote: post #30

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 dow…

It’s a shame you’re getting downvoted because I think you’re correct, and this is a perfectly valid opinion to hold. I would respond by saying that sometimes I actually want a locked-down bank terminal (when I’m banking for example), and I appreciate the opportunity to buy one. Computing hardware in general is way less expensive and more abundant than it used to be, so there are still many options in the marketplace…

>sometimes I actually want a locked-down bank terminal (when I’m banking for example), and I appreciate the opportunity to buy one.

Yep, it's a valid use case. It's just not a general purpose computer. And it's a complete refutation of the ideals of Apple when it started out (see, 1984 commercial).

Re: Memory Integrity Enforcement

#242

Post by labcomputer »

Findecanor wrote: post #199
VogonPoetry wrote: post #170

Earlier quoted context omitted.

This is on the verge of pedantry - CHERI determinism isn't strictly true, garbage collecting abandoned descriptors is currently done asynchronously. Malicious code could attempt to reuse an abandoned descriptor before it is "disappeared". I think it might be possible to construct a synthetic situation where two threads operating with perhaps different privilege in the same address space (something CHERI can support!)…

I suspect that the parent poster was referring to MTE's memory protection being probabilistic. There are only 16 tag values for an attacker to guess. You can combine MTE and PAC, but PAC is also only probabilistic. With CHERI, there is nothing to guess. You either have a capability or you don't.

Right, but the problem with CHERI is that you may (probabilistically) continue to have that capability even after you shouldn't. That's the problem.

That's because the capability (tagged pointer) itself is what gives you the right to access memory. So you have to find all the capabilities pointing to a segment of memory and invalidate them. Remember, capabilities are meant to be copied.

Early work on CHERI (CHERIvoke) proposed a stop-the-world barrier to revoke capabilities by doing a full scan of the program's memory (ouch!) to find and invalidate any stale capabilities. Because that is so expensive, the scan is only performed after a certain threshold amount of memory has been freed. That threshold introduces a security / battery life trade-off.

That was followed by "Cornucopia", which proposed a concurrent in-kernel scan (with some per-page flags to reduce the number of pages scanned) followed by a shorter stop-the-world. In 2024 (just last year), "Reloaded" was proposed, which add still more MMU hardware to nearly eliminate pauses, at the cost of 10% more memory traffic.

Unfortunately, the time between free and revocation introduces a short-but-not-zero window for UAF bugs/attacks. This time gap is even explicitly acknowledged in the Reloaded paper! Moreover, the Reloaded revocation algo requires blocking all threads of an application to ensure no dead capabilities are hidden in registers.

In contrast, with MTE, you just change the memory's tag on free, which immediately causes all formerly-valid pointers to the memory granule to become invalid. That's why you would want both: They're complementary.

* MTE gives truly instantaneous invalidation with zero battery impact, but only probabilistic spatial protections from attackers.

* CHERI gives deterministic spatial protection with eventually-consistent temporal invalidation semantics.

Re: Memory Integrity Enforcement

#243

Post by jrtc27 »

labcomputer wrote: post #242
Findecanor wrote: post #199

Earlier quoted context omitted.

I suspect that the parent poster was referring to MTE's memory protection being probabilistic. There are only 16 tag values for an attacker to guess. You can combine MTE and PAC, but PAC is also only probabilistic. With CHERI, there is nothing to guess. You either have a capability or you don't.

Right, but the problem with CHERI is that you may (probabilistically) continue to have that capability even after you shouldn't. That's the problem. That's because the capability (tagged pointer) itself is what gives you the right to access memory. So you have to find all the capabilities pointing to a segment of memory and invalidate them. Remember, capabilities are meant to be copied. Early work on CHERI (CHERIvoke…

> Unfortunately, the time between free and revocation introduces a short-but-not-zero window for UAF bugs/attacks. This time gap is even explicitly acknowledged in the Reloaded paper!

Yes, revocation is batched and asynchronous. This does mean that capabilities remain valid beyond the language-level lifetime of the allocation. However, that does not mean that, within that window, we have not dealt with any UAF attacks. The vast majority of UAF attacks do not care about the fact that the memory has been freed, but rather that the memory has since been repurposed for something else (whether the allocator's own internal metadata or some other new allocation). Cornucopia (both versions) ensures that this does not happen until the next revocation pass; that is, it "quarantines" the memory. Effectively, when you call free, it's "as if" the free were deferred until revocation time. Therefore, if your capability is still valid, that memory is still only in use by you, and so the vast majority of attacks no longer work. This protects you against UAF in a similar way to how making free a no-op protects against most attacks. This is not all attacks, very occasionally the bug is a result of something like undefined behaviour that follows, but I don't know if we've found even one real-world instance of a UAF that this approach isn't going to catch. I'm sure they exist, but the nuance is crucial here to be able to reason about the security of various models.

But yes, MTE+CHERI are complementary in this regard. We have drafted ideas for using MTE with CHERI, which would (a) let you immediately prevent access (noting though that the capability would remain valid for a while, still) (b) let you recycle memory with different MTE colours before needing to quarantine the memory (hoping that, by the time you run out of colours for that memory region, a revocation pass has reclaimed some of them). That is, in theory it both gives stronger protection and better performance. I say in theory because this is just a sketch of ideas, nobody has yet explored that research.

I also note that MTE does not fix the undefined behaviour problem; it will only trap when it sees a memory access, but vulnerabilities introduced due to compilers exploiting undefined behaviour for optimisation purposes may not perform a memory access with the pointer before it's too late.

Re: Memory Integrity Enforcement

#244

Post by ignoramous »

saagarjha wrote: post #182
ignoramous wrote: post #142

Earlier quoted context omitted.

Unfortunate Daniel Berlin did not push Google to invest in MTE for security specifically, like Apple has done now with EMTE (MTE v4?). I mean, AOSP is investing heavily in rewriting core components like Binder IPC in Rust for memory safety instead... They also haven't resurrected the per-app toggle to disable JIT in ART for Java/Kotlin apps (like DVM's android:vmSafeMode)... especially after having delivered on-devic…

Google did invest in MTE. In fact you linked to some of their investments that ended up trickling down to Android. The problem is actually shipping this is hard and Google was not able to do it. No, "some in the security community" being loud does not mean it is ready to ship. Google identified several problems that they were not able to solve and thus did not ship it generally.

> Google identified several problems that they were not able to solve and thus did not ship it generally.

My lament is, Google did not push it through when it mattered as Apple here has (assuming FEAT_MTE4 is them solving similar problems to productize MTE for security).

> "some in the security community" being loud

Think the GrapheneOS authors deserve more respect. They aren't merely "loud", they shipped features that AOSP later incorporated.

Re: Memory Integrity Enforcement

#245

Post by saagarjha »

ignoramous wrote: post #237
saagarjha wrote: post #187

Earlier quoted context omitted.

Apple has implemented synchronous MTE with almost neutral overhead and also mitigated Spectre v1 using a novel technique that I haven't heard of before (which, alas, they don't really go into detail here); what's more, they plan to ship this to (hundreds of) millions of devices. I think these are significant improvements of the state of the art.

> also mitigated Spectre v1 using a novel technique that I haven't heard of before Unsure about iOS, but back then, Webkit published their initial mitigations (like: Index masking, Pointer poisoning): https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-...

Yeah, this is what they came up with in the wake of those being released. They have a performance impact though.

Re: Memory Integrity Enforcement

#246

Post by saagarjha »

pizlonator wrote: post #207
saagarjha wrote: post #186

Earlier quoted context omitted.

1/16 is a miserable rate for commercial spyware; it would be very difficult to sell this kind of product for a remote 0- or 1-click attack.

It’s miserable today because you’d be competing with others selling deterministic attacks. But what if the only thing available to purchase is 1/16 or 1/256? Then maybe it’s not so miserable

I trust that people will find a way to make deterministic attacks, I just think they will charge through the nose for it.

Re: Memory Integrity Enforcement

#247

Post by saagarjha »

ignoramous wrote: post #244
saagarjha wrote: post #182

Earlier quoted context omitted.

Google did invest in MTE. In fact you linked to some of their investments that ended up trickling down to Android. The problem is actually shipping this is hard and Google was not able to do it. No, "some in the security community" being loud does not mean it is ready to ship. Google identified several problems that they were not able to solve and thus did not ship it generally.

> Google identified several problems that they were not able to solve and thus did not ship it generally. My lament is, Google did not push it through when it mattered as Apple here has (assuming FEAT_MTE4 is them solving similar problems to productize MTE for security). > "some in the security community" being loud Think the GrapheneOS authors deserve more respect. They aren't merely "loud", they shipped features th…

No, FEAT_MTE4 is just part of it. There's a bunch of implementation work that goes on top of it to make it perform well for consumer devices.

Re: Memory Integrity Enforcement

#248

Post by saagarjha »

superkuh wrote: post #240
saagarjha wrote: post #97

Earlier quoted context omitted.

You disable mitigations for those processes.

So what stops malware from disabling the mitigations? This is the same issue that Firefox had re: requiring all add-ons to be approved and cryptographically signed by them. If it were possible to disable it it'd be useless. So 99.999% of firefox executables simply cannot run anything not first signed by Moz.

Currently you can't disable these if you don't have developer mode turned on

Re: Memory Integrity Enforcement

#249

Post by strcat »

ghostpepper wrote: post #113
strcat wrote: post #103

Earlier quoted context omitted.

> Apple and Google have access to similar or more information than you do, they just don't publish it for similar reasons. If that's the case, then many of their public statements about this are extraordinarily dishonest. There are widespread exploits targeting Safari, Chrome, iOS and Android. These are not only rare attacks targeting people heavily sought out by governments, etc. They do not have nearly as much visi…

Can you be more specific on what you consider "widespread" vs "rare"?

There are widely available tools for exploiting iPhones. These are available to low level law enforcement, border guards, etc. They're often abused. The same goes for remote exploits. Apple and Google have succeeded in making the exploits expensive, but not much success in stopping them for more than short periods of time. Perhaps they'll start having more success, but so far they haven't. Making the cost of developing the exploits more expensive does not change that the usage is widespread in many dozens of countries. The remote exploits are not only used in targeted attacks against a tiny subset of people. They're often broadly deployed on publicly accessible websites.

Re: Memory Integrity Enforcement

#250

Post by strcat »

saagarjha wrote: post #190
strcat wrote: post #140

Earlier quoted context omitted.

We have regular contact with many people at Google in that space and nearly no contact with anyone at Apple as a whole. Sometimes people we know go to work at Apple and become nearly radio silent about anything technical. It's often external parties finding exploits being used in the wild and reporting it to Apple and Google. Citizen Lab, Amnesty International, etc. We regularly receive info from people working at or…

Disclaimer: I have never worked with the team on the Apple side. My impression is that Apple's threat intelligence effort is similar in quality to Google's. Of course external parties also help but Apple also independently finds chains sometimes.

> My impression is that Apple's threat intelligence effort is similar in quality to Google's.

We have a lot of direct experience with Google not having much of a clue about how their own devices are being exploited in the wild. The overall approach does not provide as much insight as it's marketed as doing.

Post reply on HN