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

161–170 of 259 posts

Re: Memory Integrity Enforcement

#161

Post by vayup »

strcat wrote: post #98
tptacek wrote: post #22

Earlier quoted context omitted.

Even with Android MTE, one of the workarounds was probabilistic attacks on the small tag size, which imply multiple tries. One of the big distinctions here is uniform synchronous enforcement, so writes trap immediately and not on the next context switch.

It's typically used in synchronous or asymmetric mode on Android. The asymmetric mode preserves nearly the same performance as asymmetric while only having writes remain asynchronous. It's enforced once there's a read or system call. Synchronous is more important in the kernel due to how many holes there are for bypassing it, which is why GrapheneOS is using it as synchronous in the kernel and asymmetric in userspace…

In theory, it is a 1/15 chance of successful attack. Which is a terribly low success rate of attack prevention.

In practice, it is 15/16 chance of detection of the exploit attempt. Which is an extraordinarily high rate of detection, which will lead to a fix by Apple.

Net net, huge win. But I agree they come across as overstating the prevention aspect.

Re: Memory Integrity Enforcement

#162

Post by axoltl »

LeakedCanary wrote: post #159

> ... 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?

I believe they mean the source region's tag, rather than the destination.

Re: Memory Integrity Enforcement

#163

Post by userbinator »

aloha2436 wrote: post #133
bergfest wrote: post #52

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.

> MIE will make sure we can never take back our freedom. Is the implication here that making phones more secure is... bad? Because it makes jailbreaks harder to develop?

Yes, absolutely.

Just like any weapon, "security" is only good if it's in your control. When the noose is around your neck, you'd better hope it easily breaks.

Re: Memory Integrity Enforcement

#164

Post by freakynit »

vayup wrote: post #160

> ...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. S…

Four bits provide too few possibilities. Since memory allocations happen millions of times per minute, the chance of collisions grows very quickly, even with periodic reseeding.

Re: Memory Integrity Enforcement

#165

Post by transpute »

acdha wrote: post #82
transpute wrote: post #13

Earlier quoted context omitted.

Recent discussion on 90-day embargo for security updates, https://news.ycombinator.com/item?id=45158523

That’s potentially substantial but I note that Graphene specifically rejected the framing: https://xcancel.com/GrapheneOS/status/1964757878910136346

Yes, they said it was worse, i.e. affected all Android, not only AOSP, https://news.ycombinator.com/item?id=45161011

Re: Memory Integrity Enforcement

#166

Post by saagarjha »

strcat wrote: post #107
saagarjha wrote: post #92

Earlier quoted context omitted.

> It hasn’t been a meaningful attack deterrent because attackers keep finding PAC bypasses. Correction: it forces attackers to find PAC bypasses. They are not infinite.

Hijacking control flow like this is not a hard requirement of exploitation. Vulnerabilities in a specific software release are not infinite in general so that doesn't mean much.

Memory safety issues, or ROP gadgets, and the like are basically infinite

Re: Memory Integrity Enforcement

#167

Post by jahooligan »

"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

Re: Memory Integrity Enforcement

#168

Post by jahooligan »

randyrand wrote: post #68

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

absolutely. it is awful lawyer twinkie talk. but the fact that we get such a detailed artile press release on MIE new aphl tech it speaks to its validity and confidence which is plainly great for all of us.

Re: Memory Integrity Enforcement

#169

Post by zarzavat »

pizlonator wrote: post #55
achierius wrote: post #50

Earlier quoted context omitted.

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.

I get that. That’s why I’m adding the caveat that this doesn’t protect you against attackers that are in a position to try multiple times

Detection is 14/15ths of the battle. Forcing attackers to produce a brand new exploit chain every few weeks massively increases attack cost which could make it uneconomical except for national security targets.

Re: Memory Integrity Enforcement

#170

Post by VogonPoetry »

pizlonator wrote: post #71
bri3d wrote: post #65

Earlier quoted context omitted.

Why would you need CHERI if you have working mitigations that don't demand a second bus? I think it's two halves of the same coin and Apple chose the second half of the coin. The two systems are largely orthogonal; I think if Apple chose to go from one to the other it will be a generational change rather than an incremental one. The advantage of MTE/MIE is you can do it incrementally by just changing the high bits th…

CHERI is deterministic. That’s strictly better, in theory. (Not sure it’s practically better. You could make an argument that it’s not.)

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!) have an IPC channel might be affected by the timing.

There is a section in the technical reports that talks about garbage collection.

I don't think CHERI is currently being used with different privileged threads in the same address space.

Post reply on HN