Live data from Hacker News

Memory Integrity Enforcement

security.apple.com

41–50 of 259 posts

Re: Memory Integrity Enforcement

#41

Earlier quoted context omitted.

I hate this comic because it is profoundly lazy , and I hate it when people hand-wave away meaningful security advances with it. Hitting people with wrenches leaves marks that can be shown to the media and truth & reconciliation commissions. Wetwork and black-bagging dissidents leaves records: training, operational, evidence after the fact. And it hardly scales – no matter what the powers at be want you to think, I t…

OK sure, but you don't really need to scale, just find the one guy with $500,000,000 in BTC that you want and hit him.

Again, lazy!

Yes: if you have half of a billion dollars in BTC, sure – you're a victim to the wrench, be it private or public. If you're a terrorist mastermind, you're likely going to Gitmo and will be placed in several stress positions by mean people until you say what they want to hear.

Extreme high-value targets always have been, and always will be, vulnerable to directed attacks. But these improvements are deeply significant for everyone who is not a high-value target – like me, and (possibly) you!

In my lifetime, the government has gone from "the feds can get a warrant to record me speaking, in my own voice, to anyone I dial over my phone" to "oh, he's using (e2e encrypted platform) – that's a massive amount more work if we can even break it". That means the spectrum of people who can be targeted is significantly lower than it used to be.

Spec-fiction example: consider what the NSA could do today, with whisper.cpp & no e2e encrypted calls.

Re: Memory Integrity Enforcement

#43

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…

Bingo. None of this is for users. Apple somehow managed to put on a marketing mask of user respect when they’re at least as user abusive as anyone else.

https://www.theguardian.com/news/2022/jan/17/two-female-acti...

Re: Memory Integrity Enforcement

#44

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…

If you like using debuggers, don't worry, MTE gives you a lot more chances to use them since it finds a lot more crashes. It doesn't stop you writing to memory though, as long as it's the correct type.

PAC may stop you from changing values - or at least you'd have to run code in the process to change them.

Re: Memory Integrity Enforcement

#45
post #29

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.

The problem with PowerPC AS tagging was that it relied entirely on the trap instruction. If you could control execution at all, you could skip the trap instruction and it did nothing. This implementation, by my reading, essentially adds a synchronous trap instruction after every single load and store, which builds a real security boundary (even compared to Android MTE, where reads would trap but writes were only checked at the next context switch).

Re: Memory Integrity Enforcement

#46
post #42

How does this compare to CHERI?

https://saaramar.github.io/memory_safety_blogpost_2022/ is a nice article which goes into this topic for MTE in the past.

And of note, the Apple implementation basically forces the invariants documented in the author's talk:

* use synchronous exceptions (“precise-mode”), which means the faulted instruction cannot retire and cause damage

* re-tag allocations on free

Re: Memory Integrity Enforcement

#47
post #38

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

Apple has been working on this for years. It's not like they started thinking about memory tagging when Daniel decided to turn it on in GrapheneOS.

Re: Memory Integrity Enforcement

#48
> 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 ;)

Re: Memory Integrity Enforcement

#50

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

The other 15/16 attempts would crash though, and a bug that unstable is not practically usable in production, both because it would be obvious to the user / send diagnostics upstream and because when you stack a few of those 15/16s together it's actually going to take quite a while to get lucky.
Post reply on HN