9 ms·
Memory Integrity Enforcement
- eptcyka 1y agoThis is by far the best selling point of the new series of devices.
- mrpippy 1y agoFull title is "Memory Integrity Enforcement: A complete vision for memory safety in Apple devices"
- tptacek 1y agoBoth 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.
- leoc 1y agoIn terms of Apple Kremlinology, should this be seen a step towards full capability-based memory safety like CHERI ( https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_RISC_Instructions https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_R... ) or more as Apple signaling that it thinks it can get by without something like CHERI?
- bri3d 1y agoIMO it's the latter; CHERI requires a lot of heavy lifting at the compile-and-link layer that restricts application code behaviors, and an enormous change to the microarchitecture. On the other hand, heap-cookies / tag secrets can be delegated to the allocator at runtime in something like MIE / MTE, and existing component-level building blocks like the SPTM can provide some of the guarantees without needing a whole parallel memory architecture for capabilities like CHERI demands.
- jrtc27 1y agoTo reiterate what I've said elsewhere, CHERI does not need a whole parallel memory architecture, there is just one that gets a slight extension over a non-CHERI/MTE system to include tags. But that is the same story as MTE, which also needs to propagate the tags in the memory system (and in fact, more tags, since we just need one bit per 16 bytes, whereas MTE needs 4 bits per 16 bytes in the common scheme).
- mschuster91 1y ago> CHERI requires a lot of heavy lifting at the compile-and-link layer that restricts application code behaviors, and an enormous change to the microarchitecture. Well, Apple already routinely forces developers to recompile their applications so if Apple wants to introduce something needing a compiler / toolchain update they can do that easily. And they also control the entire SoC from start to finish and unlike pretty much everyone else also hold an ARM Architecture License so they can go and change whatever they want in the hardware side as well.
- checker659 1y ago> compile-and-link layer Not to mention the dynamic linker.
- jrtc27 1y agoYeah you need a compiler, linker and OS. That's true of any security technology. CHERI may be more significant in that regard because it's a bigger rethink than just stuffing some extra metadata into the existing types, but it's not at all intractable. We, a research group, maintain CheriBSD, a "full-fat" port of FreeBSD to CHERI (Morello and CHERI-RISC-V), so to a big tech organisation it's a small investment. The cost to tech companies is not making it work, it's often much more boring business factors.
- chalst 1y agoHomepage here: https://www.cheribsd.org/ which strangely doesn’t seem to link here: https://github.com/CTSRD-CHERI/cheribsd
- pizlonator 1y agoMTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit ptr for the MTE tag) They also imply a very different system architecture.
- quotemstr 1y ago> MTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit ptr for the MTE tag) Why would you need MTE if you have CHERI?
- pizlonator 1y agoNot saying you’d want both. Just answering why MTE isn’t a path to CHERI But here’s a reason to do both: CHERI’s UAF story isn’t great. Adding MTE means you get a probabilistic story at least
- quotemstr 1y agoSome progress on UAF though! https://dl.acm.org/doi/10.1145/3703595.3705878 https://dl.acm.org/doi/10.1145/3703595.3705878
- bri3d 1y agoTrue! On the flip side, MTE sucks at intra-object corruption: if I get access to a heap object with pointers, MTE doesn't affect me, I can go ahead and write to that object because I own the tag. Overall my _personal_ opinion is that CHERI is a huge win at a huge cost, while MTE is a huge win at a low cost. But, there are definitely vulnerability classes that each system excels at.
- pizlonator 1y agoI think the intra object issue might be niche enough to not matter. And CHERI fixes it only optionally, if you accept having to change a lot more code
- commandersaki 1y agoRIP Vigilant Labs Okay a bit drastic, I don’t really know if this will affect them.
- tptacek 1y agoI think they're going to print money hats, but we'll see. Remember: there isn't a realistic ceiling on what NATO-friendly intelligence and law enforcement agencies will pay for this technology; it competes with human intelligence, which is nosebleed expensive.
- ignoramous 1y ago> This is great ... That's Apple and here is Google (who have been at memory safety since the early Chrome/Android days): Google folks were responsible for pushing on Hardware MTE ... It originally came from the folks who also did work on ASAN, syzkaller, etc ... with the help and support of folks in Android ... ARM/etc as well. I was the director for the teams that created/pushed on it ... So I'm very familiar with the tradeoffs. ... Put another way - the goal was to make it possible to use have the equivalent of ASAN be flipped on and off when you want it. Keeping it on all the time as a security mitigation was a secondary possibility, and has issues besides memory overhead. For example, you will suddenly cause tons of user-visible crashes. But not even consistently. You will crash on phones with MTE, but not without it (which is most of them). This is probably not the experience you want for a user. For a developer, you would now have to force everyone to test on MTE enabled phones when there are ~1mn of them. This is not likely to make developers happy. Are there security exploits it will mitigate? Yes, they will crash instead of be exploitable. Are there harmless bugs it will catch? Yes. ... As an aside - It's also not obvious it's the best choice for run-time mitigation. https://news.ycombinator.com/item?id=39671337 https://news.ycombinator.com/item?id=39671337 Google Security (ex: TAG & Project Zero) do so much to tackle CSVs but with MTE the mothership dropped the ball so hard.
- tptacek 1y agoThis is a Daniel Berlin post explaining why Google didn't originally enable MTE full-time on Android. It explicitly acknowledges that keeping MTE enforcement enabled for everyone would block vulnerabilities.
- ignoramous 1y agoUnfortunate 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-device "Isolated compilation" but (from what I can tell) only for OS (Java/Kotlin) components. AOSP's security posture is frustrating (as Google seemingly solely decides what's good and what's bad and imposes that decision on each of their 3bn users & ~1m developers, despite some in the security community, like Daniel Micay, urging them to reconsider). The steps Apple has been taking (in both empowering the developers and locking down its own OS) in response to Celebgate and Pegasus hacks has been commendable.
- OutOfHere 1y agoMeanwhile, 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-3566882/ 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-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-patch-backlash/ https://piunikaweb.com/2025/09/08/grapheneos-google-security...
- acdha 1y agoLook, I’m an iOS user but this seems like flame-bait to me without any technical details. I’ve seen a lot of Google blog posts about security improvements over the years so that seems like a very sweeping assertion if you’re not going to support it.
- transpute 1y agoRecent discussion on 90-day embargo for security updates, https://news.ycombinator.com/item?id=45158523 https://news.ycombinator.com/item?id=45158523
- acdha 1y agoThat’s potentially substantial but I note that Graphene specifically rejected the framing: https://xcancel.com/GrapheneOS/status/1964757878910136346 https://xcancel.com/GrapheneOS/status/1964757878910136346
- transpute 1y agoYes, they said it was worse, i.e. affected all Android, not only AOSP, https://news.ycombinator.com/item?id=45161011 https://news.ycombinator.com/item?id=45161011
- rs_rs_rs_rs_rs 1y agoThis looks amazing, I cannot wait to see how attackers pivot.
- _diyar 1y agohttps://xkcd.com/538/ https://xkcd.com/538/
- 5f3cfa1a 1y agoI 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 think history shows there are more Hugh Thompsons than Oskar Dirlewangers, even if it takes a few years to recognize what they've done. If we improve security enough that our adversaries are _forced_ to break out the wrenches, that's a very meaningful improvement!
- kridsdale3 1y agoOK 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.
- 5f3cfa1a 1y agoAgain, 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.
- EvanAnderson 1y agoI'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_descriptors https://en.wikipedia.org/wiki/Burroughs_large_systems_descri...
- gjsman-1000 1y agoI 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.
- Avamander 1y agoSaying "never" is too bold. But it's definitely getting immensely difficult. There are still plenty of other flaws besides memory unsafety to exploit. I doubt that we'll see like a formally proven mainstream OS for a long time.
- wbl 1y agoThose flaws get harder the more restricted devices are.
- bigyabai 1y agoDepends. If "restriction" means "complexity" then you may end up with scenarios like the BlastDoor vulns (eg. FORCEDENTRY).
- MBCook 1y agoTrue. But if developing an exploit takes 15 years and the average life of the device is five then to some degree that is effectively perfect.
- jgalt212 1y ago> iPhone? iOS 17 and 18 have never been jailbroken; now we introduce MIE. So far as you know. There's a reason they call them zero-day vulnerabilities.
- 1y ago
- whitepoplar 1y agoIs this only available on iPhone 17 for now?
- circuit 1y agoAvailable on all the models announced today: air and 17/17 pro (a19 chip and above)
- kridsdale3 1y agoPresumably future M5 model Macs and iPads.
- MBCook 1y agoI hope so too, but I could see it being in the M6 instead. The 202X M-series don’t always have the same core revisions as the A-series. Sometimes they’re based on the cores from 202X-1. Given how nice a feature it is I certainly hope it’s in the M5.
- deleted 1y ago[deleted]
- rudedogg 1y agoThe tagging mechanism reminds me of generational indices like https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html, but I’m a bit out of my depth
- brcmthrowaway 1y agoIf we are checking every pointer at runtime how isn't this dog slow?
- deleted 1y ago[deleted]
- hyperhello 1y agoThe chip does it by itself, in parallel to its other operations.
- riscvsupreme 1y ago[flagged]
- brcmthrowaway 1y agoHow does this compare to CHERI?
- bri3d 1y agoSubstantially less complex and therefore likely to be substantially easier to actually use. CHERI-Morello uses 129-bit capability objects to tag operations, has a parallel capability stack, capability pointers, and requires microarchitectural support for a tag storage memory. Basically with CHERI-Morello, your memory operations also need to provide a pointer to a capability object stored in the capability store. Everything that touches memory points to your capability, which tells the processor _what_ you can do with memory and the bounds of the memory you can touch. The capability store is literally a separate bus and memory that isn't accessible by programs, so there are no secrets: even if you leak the pointer to a capability, it doesn't matter, because it's not in a place that "user code" can ever touch. This is fine in theory, but it's incredibly expensive in practice. MIE is a much simpler notion that seems to use N-bit (maybe 4?) tags to protect heap allocations, and uses the SPTM to protect tag space from kernel compromise. If it's exactly as in the article: heap allocations get a tag. Any load/store operation to the heap needs to provide the tag that was used for their allocation in the pointer. The tag store used by the kernel allocator is protected by SPTM so you can't just dump the tags. If you combine MIE, SPTM, and PAC, you get close-ish to CHERI, but with independent building blocks. It's less robust, but also a less granular system with less overhead. MIE is both probabilistic (N-bits of entropy) and protected by a slightly weaker hardware protection (SPTM, which to my understanding is a bus firewall, vs. a separate bus). It also only protects heap allocations, although existing mitigations protect the stack and execution flow. Going off of the VERY limited information in the post, my naive read is that the biggest vulnerability here will be tag collision. If you try enough times with enough heap spray, or can groom the heap repeatedly, you can probably collide a tag with however many bits of entropy are present in the system. But, because the model is synchronous, you will bus fault every time before that, unlike MTE, so you'll get caught, which is a big problem for nation-state attackers.
- leoc 1y agoSomething I'm not clear about: is CHERI free and clear in patent terms, or do people have their hands out grasping for an MPEG-like licensing bonanza? If it's the latter then that might matter as much as purely technical obstacles to CHERI adoption.
- pizlonator 1y agoThis 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
- tptacek 1y agoEven 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.
- pizlonator 1y agoYeah that’s really good. That makes the probability work against the attacker really well. But it’s not a guarantee
- strcat 1y agoIt'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. io_uring is a major example of how there could be a major bypass of asymmetric mode, although Android doesn't allow it for more than a few core processes. Deploying asynchronous is still useful since it's a widely distributed bug finding tool with near zero cost. The main cost is that it finds so many bugs which need to be addressed which is a barrier for deploying it for third party apps. The main weakness is that MTE is only 4 bits... and it's not even 1/16 but typically 1/15 chance of bypassing it since a tag is usually reserved for metadata, free data, etc. The Linux kernel's standard implementation for in-kernel usage unnecessarily reserves more than 1 to make debugging easier. MTE clears the way for a more serious security focused memory tagging implementation with far more bits and other features. It provides a clear path to providing very strong protection against the main classes of vulnerabilities used in exploits, especially remote/proximity ones. It's a great feature but it's more what it leads to that's very impressive than the current 4 bit MTE. Getting rid of some known side channels doesn't make it into a memory safety implementation.
- rdtsc 1y ago1988 called and wants it memory tagging back https://www.devever.net/~hl/ppcas 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.
- pyth0 1y agoThe big difference with this seems like it is an actual security mechanism to block "invalid" accesses where as the tagged memory extensions only provided pointer metadata and it was up to the OS to enforce invariants. > Extensions provide no security. [...] The tagged memory extensions don't stop you from doing anything.
- bri3d 1y agoThe 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).
- rdtsc 1y agoYeah, the security part wasn't baked into the hardware. It relied on the OS (it ran a virtualization layer of sorts) to enforce it via traps if it set those traps. From https://www.devever.net/~hl/ppcas https://www.devever.net/~hl/ppcas > As such, they can principally be viewed as providing a performance enhancement for the IBM i operating system, which uses these instructions to keep track of pointer validity. It is the IBM i OS which enforces security invariants, for example by always following every pointer LQ with a TXER.
- sillywalk 1y agoNitpick: The AS/400 in 1988 didn't use the PowerPC. I believe it had it's own proprietary memory with tag bits included. The first RS-64 with the PowerPC AS extensions came out in 1995.
- superkuh 1y agoThis 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.
- user3939382 1y agoBingo. 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.
- astrange 1y agohttps://www.theguardian.com/news/2022/jan/17/two-female-activists-in-bahrain-and-jordan-hacked-with-nso-spyware https://www.theguardian.com/news/2022/jan/17/two-female-acti...
- bigyabai 1y agoIt's detestable how Apple handled the aftermath of this: https://en.wikipedia.org/wiki/FORCEDENTRY https://en.wikipedia.org/wiki/FORCEDENTRY In November 2021, Apple Inc. filed a complaint against NSO Group and its parent company Q Cyber Technologies in the United States District Court for the Northern District of California in relation to FORCEDENTRY, requesting injunctive relief, compensatory damages, punitive damages, and disgorgement of profits but in 2024 asked the court to dismiss the lawsuit. The perpetrators were caught red-handed and let, go by Apple! This crime can, will, and has continued to happen due to the negligence of Apple's leadership. No doubt influenced by Tim Cook's obligation to the White House and their friends.
- saagarjha 1y agoIf I remember correctly the Israeli government stepped in and seized all the material that Apple could use in the lawsuit, so there was no point in continuing.
- ysnp 1y ago>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 https://grapheneos.org/releases#2023103000 [2] https://xcancel.com/GrapheneOS/status/1716946325277909087#m https://xcancel.com/GrapheneOS/status/1716946325277909087#m
- saagarjha 1y agoApple 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.
- ysnp 1y agoI didn't mean to imply Apple (and Google) hadn't been spearheading multi-year efforts to ship this in collaboration with Arm, I regret a little that it came across that way. Just that it would be nice to see production use of it acknowledged even just as a passing comment. As an outsider I am quite ignorant to what security developments these companies are considering and when the trade-offs are perhaps too compromising for them to make it to production. So I can't appreciate the scale of what Apple had to do to reach this stage, whereas with GrapheneOS I know they favour privacy/security on balance. I use that as a weak signal to gauge how committed Apple/Google/Microsoft are to realising those kinds of goals too.
- saurik 1y ago> 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/master/writeup.pdf 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 ;)
- commandersaki 1y agoYeah it’s hard to get these things right the first time.
- MBCook 1y ago> FWIW, I presume this is "from experience"--rather than, from first principles, which is how it comes off I interpreted that as what they came up with when first looking at/starting to implement MTE, not their plan since $longTimeAgo. Apple has certainly gotten better about security, and I suspect things like what you listed are a big part of why. They were clearly forced to learn a lot by jailbreakers.
- axoltl 1y agoI have some inside knowledge here. KPP was released around the time KTRR on A11 was implemented to have some small amount of parity on <A11 SoCs. I vaguely remember the edict came down from high that such a parity should exist, and it was implemented in the best way they could within a certain time constraint. They never did that again.
- max_ 1y ago[flagged]
- deleted 1y ago[deleted]
- nothankyou777 1y agoWe move from the "prison phone" to the escape-proof "prison phone", and the spiritual abominations on hackernews celebrate.
- bergfest 1y agoWith 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.
- spaceribs 1y agoThat is, unless we balkanize our systems and services.
- ysofunny 1y ago> That is, unless we balkanize our systems and services. ...all the way back to pen and paper
- spaceribs 1y agoI wouldn't be surprised for certain kinds of secret sharing. Storage is cheap and sneaker-nets are easy. I'm sure someone is figuring out a network solution where 2 computers both have a 100tb hard drive with the same one-time pad. https://en.wikipedia.org/wiki/One-time_pad https://en.wikipedia.org/wiki/One-time_pad
- deleted 1y ago[deleted]
- elcritch 1y agoWhat is WEI?
- ls612 1y agoGoogle proposed it as DRM for web pages in 2023. After much outcry it was unceremoniously withdrawn.
- aloha2436 1y ago
- cassepipe 1y ago> 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.
- randyrand 1y ago> 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.
- brookst 1y agoMaybe, maybe not. But it seems fair to point out. Certainly if it was as exposed as, say, Windows, then there would have been many.
- randyrand 1y agoI mean, if you read the exploit chains, they apply to all iPhones and are wormable.
- strcat 1y agoNeither Apple or Google truly knows how widespread attacks on their products have been despite portraying it as if they have perfect insight into it. They're claiming to know something they cannot. GrapheneOS has published leaked data from exploit developers showing they're much more successful at exploiting devices and keeping up with updates than most people believe. We have access to more than what we've published, since we don't publish it without multiple independent sources to avoid leaks being identified. These tools are widely available, and it cannot be generally known when they're used whether it's data extraction or remote exploitation. Catching exploits in the wild is the exception to the rule, otherwise exploit development companies would have a much harder job needing to keep making new exploits after they're heavily used. They wouldn't value a single exploit chain nearly as much as they do if it stopped working after it was used 50k times. Law enforcement around the world has access to tools like Cellebrite Premium which are used against many people crossing borders, at protests, etc. That is usage at scale. There's far less insight into remote exploits which don't have to be distributed broadly to be broadly used.
- philodeon 1y ago> 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.
- sfink 1y agoTo be fair, they didn't claim it to be a meaningful attack deterrent. They said "success...in increasing exploitation complexity". Sure, the whole sentence is a bit of a weird mess. Paraphrased: it made exploits more complex, so we concluded that we needed a combined SW/HW approach. What I read into that is that they're admitting PAC didn't work, so they needed to come up with a new approach and part of that approach was to accept that they couldn't do it using either SW or HW alone. Then again... I don't know much about PAC, but to me it seems like it's a HW feature that requires SW changes to make use of it, so it's kind of HW+SW already. But that's a pointless quibble; EMTE employs a lot more coordination and covers a lot more surface, iiuc.
- ghostpepper 1y agoMaking attackers work harder is still a worthwhile goal. No security is perfect.
- astrange 1y agoAlso, all of these security improvements are nearly-free assert()s which catch memory bugs.
- saagarjha 1y ago> 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.
- pandalicious 1y ago>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?
- saagarjha 1y agohttps://mastodon.online/@ezhes_/115175838087995856 https://mastodon.online/@ezhes_/115175838087995856
- sfink 1y agoNope. I don't know why just checking the tags during speculation wouldn't stop Spectre V1, at least for cross-type accesses? I mean, it's not that simple because your program won't crash if speculation has mismatched tags. Which means you can try as many times as you want until you get lucky. But that's certainly not a "completely novel mitigation", so I'm sure I'm missing something obvious. Perhaps the real problem is that you can use speculation to scan large amounts of memory for matching tags, some of which would be different types, so you need something to handle that? (talking out of my butt here)
- MBCook 1y agoYou’re on the right track, I think. The mastodon link posted in a sibling comment within a minute of yours provides more details: It sounds like the kernel’s allocations may only use one tag(?). So if you get in there, jackpot right? No tags to deal with. So they’re using special compiler flags to limit all offsets to less than 4 GB. Then they placed different parts of the kernel far apart in address space with a 4 GB unmapped zone. So if you can put your own pointer somewhere that’s exploitable in allocated kernel memory, there is no way for it to point to any other “part” of kernel memory. Only within that one “area”. Presumably this would mean that exploiting a problem in the graphics drivers would not make it possible to provide a pointer pointing to the Secure Enclave interface code. Or something like that. I’m not 100% on if I’m understanding it correctly.
- akyuu 1y agoI wonder if these protections will apply to macOS as well.
- cmxch 1y agoMore like Manufacturer Integrity Enforcement the way Apple makes things. What’s the real benefit for regular/power users?
- saagarjha 1y agoIf you are targeted by advanced spyware then it makes it more difficult for their exploit to work.
- HackerNewt-doms 1y agoIs MTE restricted to the newest (17) iPhone models or does it work on the older ones too?
- saagarjha 1y agoJust the newest ones.
- LeakedCanary 1y ago> ... 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?
- axoltl 1y agoI believe they mean the source region's tag, rather than the destination.
- LeakedCanary 1y agoNot sure if I understand this correctly: If an attacker somehow gains out-of-bounds write capability for a tagged memory region (via a pointer that points to that region, I assume), they could potentially write into a non-tagged memory region. Since the destination region is untagged, there would be no tag check against the pointer’s tag, effectively bypassing EMTE. > I believe they mean the source region's tag, rather than the destination. But in the previous case, the pointer the attacker uses should already carry the source region’s tag, so it’s still unclear if this is what they meant. I’m not sure which attack scenario they had in mind when they said this. It would help if they provided a concrete attack example.
- vayup 1y ago> ...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.
- freakynit 1y agoFour 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.
- saagarjha 1y agoThe idea is that a tag failure crashes your process.
- kevincox 1y agoBut you only get one try. 15/16 times you get a very visible failure. It isn't great. Most users won't assume malice when an app crashes. And if they reopen it a few times your chance of succeeding goes up quickly. But this is also assuming that you need a single pointer tag to exploit something. If you need more you need to get even luckier. So it definitely isn't perfect protection. But it isn't trivial to bypass.
- qafy 1y agoThis could be solved at the OS level. Just crashing and closing the app would lead the user to simply re-open it and try again. However, if iOS detects this type of crash it could sternly alert the user that the application they are using is likely compromised. It could also transmit analytics for these specific types of crashes to Apple, who would have very realtime insights into newly compromised apps. I don't think the idea here is "crash silently and let the user reopen the app as many times as they want" I think its "crash very very loudly" > If you need more you need to get even luckier. This is a good point. Im not an expert but im guessing one is rarely enough, which would exponentially decrease your chances of success by brute force, e.g. 2 tags would be 1/256 etc
- jahooligan 1y ago"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
- amelius 1y agoYes, but with MIE there will come an end to that, hopefully. The business model of Pegasus et al. will be gone.
- jahooligan 1y agorow/throw hammer or a bit flip
- pjmlp 1y agoThis 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.
- apaprocki 1y agoWhether 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.