Steve Gibson (120:21)
Certainly sets the bar high. Yeah. So the reason we're here today is to gain at the with this podcast is to gain an understanding of what Apple has done to justify this claim. Their posting then continues to remind us of the nature of the threats they face and some details of their journey up to this point. I'm going to share that, interrupting to comment and elaborate where needed. They write There has never been a successful widespread malware attack against iPhone. Okay, now that's true. And it's worth remembering. Microsoft might argue that Windows, being a far more open platform compared to Apple's, which is a much more controlled environment, faces a much more daunting security challenge. That is, the Windows faces a much more daunting security challenge. But all of Microsoft's biggest problems were of their own making, with their own code all of those early Internet worms leveraged fundamental flaws in Microsoft's IIS web server and the many continuing problems with Microsoft's NT LAN Manager and their remote desktop protocol. Those were in every case enabled by Microsoft's poor coding and insecure protocol designs. Apple has objectively done a far better job and their devices are every bit as well connected as Microsoft's. So Apple continues the only system level iOS attacks we observe in the wild come from mercenary spyware, which is vastly more complex than regular cybercriminal activity and consumer man malware. Mercenary spyware is historically associated with state actors and uses exploit chains that cost millions of dollars to target a very small number of specific individuals and their devices. And I'll just note that that what Apple is saying is we don't care, we're going to stop that even though you know, they've never really had a big problem, they wrote. Although the vast majority of users will never be targeted in this way, these exploit chains demonstrate some of the most expensive, complex and advanced attacker capabilities at any given time, and are uniquely deserving of steady as we work to protect iPhone against even the most sophisticated threats known. Mercenary spyware chains used against ISOs share a common denominator with those targeting Windows and Android. They exploit memory safety vulnerabilities which are interchangeable, powerful and exist throughout the industry. Okay, that's all true and and I'll just say I may not care less how thin Apple is able to make an iPhone, but the same dogged, crazy over the top passion that they show for making their phones ever thinner. A whole different group at Apple is showing the same sort of focus on darn it, we're not going to let anything attack our devices, period. No matter how much they cost. Whoever it is that wants to do it, we're just saying not here. So as I noted earlier, despite all the lessons we've learned, even you know, recently authored code such as that Adobe DNG file decompressor continue to exploit exploit to exhibit exploitable vulnerabilities. So Apple writes For Apple, improving memory safety is a broad effort that includes developing with safe languages and deploying mitigations at scale. We created swift and easy to use memory safe language which we employ for new code and targeted component rewrites. In iOS 15 we introduced K Alloctype, a secure memory allocator for the kernel, followed in iOS 17 by its user leverage user level counterpart X Zone Malloc. These secure allocators take advantage of knowing the type or purpose of allocations so that memory can be organized in A way that makes exploiting most memory corruption vulnerabilities inherently more difficult. In 2018, we were the first in the industry to deploy pointer authentication codes and 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. It's worth noting that that means what they're saying is we learned something from that a 12 bionic chip experience, they said. Then, with Pack behind us, we immediately began design and evaluation work to find the most effective way to build sophisticated memory safety capabilities right into Apple Silicon. Okay, so put. To put this into perspective, the earliest efforts at building barriers around memory to protect its misuse were implemented in software. They were useful and effective, but they turned out to fall short of being absolute. As a consequence, while the bar was meaningfully raised, this just meant that the bad guys needed to work a lot harder. You know, we talked about address, address space layout, randomization, for example, and, and that in turn, with the bad guys working needing to work harder, the governments needed to pay more as exploits became significantly more rarefied. Unfortunately for journalists, political activists and other targeted individuals, governments have no shortage of funds nor willingness to pay a competitive price. You know, after adding things like address space layout, randomization, kernel address space layout, randomization, stack cookies, reference counting and other software based mitigations, all I'll note that we've covered in in the previous years of this podcast. They were all eventually worked around by highly motivated attackers. So the ante had been upped and it was time to start adding explicit anti exploitation features to the underlying Hardware. Apple wrote. ARM published the Memory Tagging Extension MTE specification in 2019. Okay, so that was six years ago. 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. It's a four bit 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 and the event is logged. This allows developers, again developers, to identify memory corruption bugs immediately as they occur. Okay, so again I'm going to pause to highlight this distinction because it's important. ARMS MTE was introduced, As I said, six years ago, in 2019 with the ARM version 8.5 A architecture. Its intention, design and focus was to assist developers, both software developers, both the software like like debuggers and the people during code development time when they were debugging, running code under a debugger that would attempt to verify and validate every memory access would introduce prohibitive overhead. We'll be talking a lot about overhead in a bit. You know, everything is about overhead. So ARMS MTE was added to the ARM architecture to allow the hardware, while running at speed, full speed, to detect instances of use after free and out of bounds accesses. And we'll explain how in a minute. It's not possible to do this at speed without hardware assistance because I'm. You'd have to check every reference to memory and you just can't you. This has to be done in the hardware. By tagging memory allocations with what were known as colors consisting of four bit tags so different allocations receive different coloring and then checking against those pointer tags at runtime, MTE was able to provide a low overhead always available bug trapping mechanism in hardware. Since we're going to be talking about tagging a lot, let me clarify what's going on here. When an application running on behalf of its user or some process in the kernel needs to needs the use of of a block of memory, for example, it needs a buffer, some buffer space to store some incoming communications data. The app or a kernel process makes a request of the operating system's memory management system for decades, a memory manager for decades in the past. The way this works is that a memory manager would locate some free memory, increment that memory's usage count to show that it's now in use, and then return a pointer to the requested memory to its requester. From that point on, that memory would be considered to be owned by the requesting application, and it would be free to do anything with it that it wished. Unfortunately, the required flexibility of access required that the memory's ownership not be enforced. Any other process that knew where the memory was located could also access it. This is what in this is what the introduction of MTE changed. Under arm's memory tagged extension, the requester would receive not only a pointer to a block of memory that satisfied its request, but also that short tag, that color, a four bit secret key that would need to be present anytime that memory was accessed. The theory was that while bad guys might be able to arrange to determine where some memory was that had recently been freed or might still be in use, requiring that they would need to determine that memory's access tag significantly raised the bar for memory access abuse. Okay, but MTE alone proved to be insufficient for Apple's needs, they wrote. We conducted a deep evaluation and research process to determine whether MTE as designed would meet our goals for hardware assisted memory safety. Our analysis found that when employed as real time as a real time defensive measure, the original ARM MTE release exhibited weaknesses that were unacceptable to us, and we worked with ARM to address these shortcomings in the new Enhanced Memory Tagging Extension EMTE specification released in 2022. So, three years after the 2019 release of MTE. Working with Apple, ARM released a new specification, the Enhanced memory tagging extension EMTE, in 2022, they said. More importantly, our analysis showed that while EMTE had great potential as specified, a rigorous implementation with deep hardware and operating system support could be a breakthrough that provides an extraordinary new security mechanism, they said. Consider that MTE can be configured to report memory corruption either synchronously or asynchronously. In the latter mode, memory corruption does not immediately raise an exception, leaving a race window open for attackers. We would not implement such a mechanism. We believe memory safety protections need to be strictly synchronous on by default and working continuously. But supporting always on synchronous MTE across key attack surfaces while preserving a great high performance user experience is extremely demanding for hardware to support. In addition, for MTE to provide memory safety in an adversarial context, we would need to finely tune the operating system to defend the new semantics and the confidentiality of memory tags on which MTE relies. Okay, again I'll just pause to say that MTE was remember was designed to help developers and debuggers. It was not meant as a proactive security measure. So Apple was this exploration that Apple talked about going on this deep analysis was can we use ARMS mte released in ARM8.5A as a security measure? And they said unfortunately no, it comes up short. They said. Ultimately we determined that to deliver truly best in class memory safety, we would carry out a massive engineering effort spanning all of Apple, including updates to Apple Silicon, our operating systems and our software frameworks. This effort, together with our highly successful secure memory allocator work would transform MTE from a helpful debugging tool into a groundbreaking new security feature. Today we're introducing the culmination of this effort, Memory Integrity Enforcement mie, our comprehensive memory safety defense for Apple platforms. Memory Integrity Enforcement is built on the robust foundation provided by our secure Memory Allocators coupled with enhanced memory tagging extension. That's the EMTE from 2022 in synchronous mode and supported by extensive tag confidentiality enforcement policies again for use against malware. MIE is built right into Apple hardware and software in all models of iPhone 17 and iPhone Air, and offers unparalleled always on memory safety protection for our key attack surfaces, including the kernel, while maintaining the power and performance that users expect. In addition, we're making emtech available to all Apple developers in xcode as part of the new enhanced security feature that we released earlier this year during the Worldwide Developer Conference. The rest of this post, they wrote, dives into the intensive engineering effort required to design and validate memory integrity enforcement. Okay, so let's get all these abbreviations straight. Originally, to aid in debugging, ARM designed and introduced MTE in 2019. But MTE was never designed to be used in an adversarial environment. It was designed to be a debugging aid. So for example, it was acceptable if it operated asynchronously from the code, notifying a developer of a violation sometime after the fact. That was okay because they could go back and see what had caused that. Acceptable for a debugger, but in an adversarial setting, the damage might have already been done by the time an exception was raised. Thus Apple's need for synchronous checking. That is the instant you try to access memory, if you shouldn't be doing it, you're that your butt is terminated. They said after. Well so and what? So what they found was after experiencing for themselves MTE's limitations three years later in 2022, they work closely with ARM on the development and and implementation of an extension to that emte. They're enhanced or extended memory tagging extension. Original MTE allowed also allowed non tagged memory regions. That is, you know, it's like, okay, if you're not going to tag this, that's fine, you know, for example, global or static allocations or untagged regions could be accessed without any tag checks, meaning that allocators could exploit out of bounds rights into such regions. EMTE addressed this by requiring access from a tagged memory region into non tagged memory to respect the tag knowledge. This prevented the use of untagged memory from being used as a tag bypass. Again, Apple just looked at every single aspect of this and just said, you know, no, no, no, no, no, we need to fix these things. I mean this is, to me, this represents them really, really getting serious about, you know, nipping this stuff once and for all. EMTE also brings more comprehensive enforcement of tag mismatches, especially in synchronous mode, so that buffer overflows and use after Free bugs are blocked immediately, not just signaled later or more coarsely, so much more granular control and as I said, synchronous, meaning the instant something tries to make a fetch, if it should not be doing so, the process is terminated and an exception is logged. So there's a lot more to the improvements that EMTE brought over its predecessor MTE. But with their A19 ARM chips, Apple has already moved on to, to their next generation of even more rigorous protections. So, Leo, let's take our final break and then we're going to continue looking at what Apple has done here.
