Apples Memory Integrity Enforcement

• Apple hat Memory Integrity Enforcement (MIE) eingeführt und damit ein innovatives System für Speichersicherheit geschaffen, das eigene Silicon-Hardware mit fortschrittlicher Betriebssystem-Sicherheit verbindet
• MIE ist ständig aktiv, schützt zentrale Angriffsflächen und wird ohne Leistungseinbußen auf allen Geräten der Serien iPhone 17 und iPhone Air eingesetzt
• Durch die Kombination aus Enhanced Memory Tagging Extension (EMTE), einem sicheren Speicher-Allocator und einer Richtlinie zur Vertraulichkeit von Tags wird die Widerstandsfähigkeit gegen bösartige Angriffe deutlich erhöht
• Durch synchrone Tag-Prüfung und die enge Integration von Betriebssystem und Hardware wird die Abwehr von Buffer Overflows und Use-After-Free-Schwachstellen maximiert
• Durch jahrelange intensive Forschung und interne Evaluierung wird der Handlungsspielraum von Angreifern eingeschränkt und nach heutigem Stand die stärkste Speichersicherheit erreicht

---

Einführung

• Apples Memory Integrity Enforcement (MIE) ist eine stets aktive Schutztechnologie für Speichersicherheit, die Apple-Silicon-Hardware und fortgeschrittene Betriebssystem-Sicherheit integriert
• Sie wurde mit dem Ziel entwickelt, ohne zusätzliche Leistungseinbußen ein branchenweit erstes umfassendes Speichersicherheits-System für verschiedene Apple-Geräte bereitzustellen
• Apple bewertet dies als den wichtigsten Fortschritt in der Geschichte der Speichersicherheit von Consumer-Betriebssystemen

Hintergrund der Bedrohungslage und die Entwicklung der Speichersicherheit

• Dass es keine erfolgreichen Fälle groß angelegter Malware-Angriffe auf das iPhone gibt, liegt daran, dass in der Praxis nur komplexe Angriffsketten rund um mercenary spyware als reale Bedrohung beobachtet werden
• Diese hochentwickelten Angriffe, die Millionen kosten und sich gegen wenige Ziele richten, nutzen typischerweise Speichersicherheitslücken aus
• Apple hat die Speichersicherheit kontinuierlich verbessert – durch die Entwicklung sicherer Sprachen wie Swift, die Einführung sicherer Speicher-Allocatoren und groß angelegte systemweite Mitigationsmaßnahmen
• Mit dem Pointer Authentication Code (PAC), der weltweit erstmals im A12 Bionic eingeführt wurde, hat Apple den Trend zu kombinierter Hard- und Software-Sicherheit maßgeblich geprägt

Hardwarebasiertes Memory Tagging (MTE/EMTE) und das Überwinden seiner Grenzen

• Die von Arm vorgestellte Memory Tagging Extension (MTE) weist jeder Speicherallokation ein geheimes Tag zu und erlaubt Zugriffe nur mit dem korrekten Tag
• Apple entdeckte Schwächen im ursprünglichen MTE-Design, etwa den asynchronen Betrieb, und verbesserte es in Zusammenarbeit mit Arm zur Enhanced Memory Tagging Extension (EMTE)
• Entscheidend ist dabei, dass die Tag-Prüfung als stets synchroner Mechanismus ausgelegt ist und dadurch durchgängigen Schutz bietet

Die Schichtenarchitektur von MIE und zentrale Schutzmechanismen

• MIE besteht aus drei Komponenten: typenbewussten Sicherheits-Allocatoren wie kalloc_type, xzone malloc und WebKits libpas, EMTE sowie einer Richtlinie zur Tag Confidentiality Enforcement
• Die Allocatoren bieten schutz auf Speicherseitenebene zwischen unterschiedlichen Typen, während EMTE auch Schwachstellen in kleinen Speicherallokationen innerhalb desselben Typ-Buckets adressiert
• Gegen typische Angriffe auf Speicherbeschädigung wie Buffer Overflows und Use-After-Free erkennt und blockiert die Kombination aus Hardware und Betriebssystem Angriffe sofort durch Tagging und Re-Tagging

Tag-Vertraulichkeit und Strategien gegen Side-Channel-Angriffe

• Um zu verhindern, dass Angreifer auf Allocator-Speicher und offengelegte Tags zielen, wurden starke Schutzmechanismen wie der Secure Page Table Monitor eingeführt
• Gegen Side-Channel-Angriffe über speculative execution wurde Apple Silicon so konzipiert, dass Auswirkungen von Tag-Informationen auf speculative execution grundsätzlich ausgeschlossen sind
• Auch die Spectre-V1-Schwachstelle wird auf effiziente Weise blockiert, wodurch in den meisten Fällen praktische Angriffsketten unterbrochen werden

Integrierte Gegenmaßnahmen in Software und Hardware sowie breite Anwendung

• Beim Entwurf der neuen Chips A19 und A19 Pro wurden umfangreiche zusätzliche Hardware-Ressourcen für Tag-Speicherung und -Verifizierung vorgesehen
• MIE nutzt zunächst Sicherheits-Allocatoren, um softwareseitig schützbare Bereiche abzudecken, während EMTE gezielt dort eingesetzt wird, wo rein softwarebasierte Abwehr nicht möglich ist
• Auch ältere iPhone-Modelle sollen durch eine verfeinerte Rollout-Strategie möglichst viele Verbesserungen bei der Speichersicherheit erhalten

Sicherheitsbewertung in der Praxis und Analyse der Wirksamkeit

• Apples Attack Research Team entwickelte von 2020 bis 2025 im Rahmen der MIE-Planung verschiedene Angriffsszenarien und versuchte wiederholt echte Kompromittierungen bis hin zu Hardware-Prototypen
• Sowohl bei neuen als auch bei älteren Exploit-Ketten wurde bestätigt, dass MIE den Großteil der Angriffsschritte grundlegend blockiert
• Selbst die wenigen verbleibenden Schwachstellen lassen keine stabilen Angriffe zu, wodurch die Wahrscheinlichkeit realer Schäden stark sinkt

Fazit

• Das branchenführende Sicherheitsniveau des iPhone begrenzt für die meisten Nutzer bereits die Exposition gegenüber Angriffen auf Systemebene
• MIE neutralisiert die komplexesten und teuersten Angriffsstrategien realer mercenary spyware und schützt dabei dauerhaft auch mehr als 70 zentrale User-Space-Prozesse einschließlich des Kernels
• Die Bewertung zeigt, dass Kosten und Komplexität von Exploits für Memory-Corruption-Schwachstellen massiv steigen und damit die wichtigsten Angriffstechniken der vergangenen 25 Jahre wirksam erschwert werden
• MIE markiert auf iOS und Apple-Geräten die größte Veränderung in der Geschichte der Speichersicherheit von Consumer-Betriebssystemen

[GN⁺]

Hacker-News-Kommentare

• Beide Ansätze kamen zum gleichen Schluss. Memory Integrity Enforcement (MIE) blockiert grundsätzlich die meisten Exploit-Strategien, die Angreifer nutzen könnten. Speicherkorruptions-Bugs sind ursprünglich austauschbar, aber MIE schneidet schon auf einer grundlegenden Ebene so viele Exploit-Pfade ab, dass sich die Kette selbst mit neuen Bugs nicht wiederherstellen ließ. So sehr man es auch versuchte, ließ sich keine Umgehungskette neu zusammensetzen. Die wenigen verbleibenden Effekte waren zudem unzuverlässig und reichten für eine erfolgreiche Ausnutzung durch Angreifer nicht aus. Das sind sehr gute Nachrichten und ein wichtiger Punkt, den man leicht übersehen kann. Teile der Ökonomie rund um Söldner-Spyware beruhen auf austauschbaren Ketten, daher sind Abwehrmaßnahmen, die genau diese Eigenschaft direkt angreifen, besonders interessant
  • Ich frage mich, ob Apples Strategie ein Schritt hin zu vollständiger capability-basierter Speichersicherheit wie CHERI ist (siehe: Capability Hardware Enhanced RISC Instructions) oder ob man das eher als Signal lesen sollte, dass Apple glaubt, auch ohne ein solches System auszukommen
  • Ich möchte auch Googles Ansatz zur Speichersicherheit als Gegenstück zum Apple-Beispiel erwähnen. Google hat das Thema seit den frühen Tagen von Chrome/Android sehr ernst genommen und auch die Einführung von ASAN, syzkaller und Hardware MTE vorangetrieben. Da ich die verantwortliche Leitung eines solchen Teams innehatte, habe ich viele Vor- und Nachteile direkt erlebt. Was Google erreichen wollte, war, Validierung auf ASAN-Niveau je nach Bedarf ein- und ausschalten zu können. Als Sicherheitsmaßnahme dauerhaft aktiviert zu sein, bringt neben dem Speicher-Overhead noch diverse andere Probleme mit sich. Zum Beispiel führt das dazu, dass auf allen Geräten uneinheitlich viele für Nutzer sichtbare Abstürze auftreten. Aus Entwicklersicht sorgt das zwangsläufig für Frust, weil vernünftige Tests nur auf etwa einer Million MTE-fähiger Geräte möglich sind. MTE fängt einige Sicherheits-Exploits ab, aber auch viele harmlose Bugs. Ob es als Runtime-Mitigation immer die beste Wahl ist, bleibt jedoch unklar. Bei Google Security, Project Zero usw. fließt sehr viel Arbeit in CSV-Reaktionen, aber ich hatte den Eindruck, dass die Zentrale bei der Produktisierung von MTE schwach war (Link)
  • Vielleicht keine gute Nachricht für Vigilant Labs, aber es ist nicht sicher, ob sie tatsächlich stark betroffen sind
• Ich denke, Apples Aussage, dass „Speichersicherheits-Schutz zwingend immer synchron, standardmäßig aktiviert und dauerhaft aktiv sein muss“, stammt eher aus Erfahrung als aus Prinzipientreue. Das war anders als bei den frühen Kernel-Schutzmechanismen. Die mit iOS 9 im Jahr 2015 eingeführte Kernel Patch Protection (KPP) prüfte asynchron alle paar Minuten, wenn das Gerät Leerlauf hatte, ob der Kernel verändert worden war. Diese Methode war sicherheitstechnisch nicht besonders vertrauenswürdig, und es gab Designfehler, weshalb Hacks veröffentlicht wurden, die sie vollständig umgingen. KPP verhindert Kernel-Patches nicht grundsätzlich, sondern löst nur einen Panic aus, wenn etwas erkannt wird. Das bedeutete, dass ein Angreifer, wenn er seine Arbeit schnell genug erledigte und rückgängig machte, von KPP gar nicht erfasst wurde (siehe Writeup)
  • Basierend auf internen Informationen wurde KPP damals überhastet gebaut, um ungefähr zu dem Zeitpunkt, als KTRR auf dem A11 eingeführt wurde, absichtlich ein gleichwertiges Sicherheitsniveau auf A11-SoCs herzustellen. Für diesen kurzen Zeitrahmen wurde es auf die bestmögliche Weise umgesetzt, und später hat man diese Vorgehensweise nicht wiederholt
  • Es wirkt weniger so, als wäre das von Anfang an prinzipiell vorbereitet gewesen, sondern eher so, als wäre man bei der ersten Planung für MTE zu diesem Schluss gekommen. Apples Sicherheitsniveau verbessert sich kontinuierlich, und ein großer Teil des Hintergrunds sind Erfahrungen, die man durch Jailbreaks und Ähnliches erzwungenermaßen gelernt hat
  • Ich kann nachvollziehen, dass solche Systeme von Anfang an perfekt umzusetzen schwer ist
• Apple sagte zwar, es habe „keine erfolgreichen und breit angelegten Malware-Angriffe auf das iPhone“ gegeben, aber ich denke, dass bestehender Spyware-Code schon mit kleinen Änderungen sofort für großflächige Angriffe genutzt werden könnte. In der Praxis ist diese Unterscheidung nicht besonders klar
  • Weder Apple noch Google können die tatsächliche Größenordnung realer Angriffe vollständig überblicken. Laut von GrapheneOS veröffentlichtem Leak-Material sind Exploit-Entwickler bei Geräteangriffen und der Reaktion auf Updates deutlich fähiger, als die Leute denken. Es gibt weiteres nicht veröffentlichtes Material, und ein Teil wird nur eingeschränkt geteilt, um ohne Verifikation aus mehreren unabhängigen Quellen keine Leckpfade offenzulegen. Solche Exploit-Tools sind breit verfügbar, und es ist nicht einmal leicht zu unterscheiden, ob es um alltägliche Datenextraktion oder Remote-Ausnutzung geht. Dass Exploits im realen Einsatz entdeckt werden, ist selten; meist können sie in großem Maßstab ohne Erkennung eingesetzt werden, weshalb schon eine einzelne Kette lange wertvoll bleibt. Strafverfolgungsbehörden weltweit nutzen Werkzeuge wie Cellebrite Premium und setzen sie an Grenzen, bei Protesten und in vielen anderen Situationen gegen zahlreiche Menschen ein. Das ist bereits ein Einsatz im großen Maßstab. Bei Remote-Exploits muss selbst eine breite Nutzung nicht einmal breit verteilt werden
  • XcodeGhost ist ein typisches Beispiel für einen groß angelegten Malware-Angriff auf das iPhone. Damals waren unter anderem WeChat und andere betroffen. Referenz: XcodeGhost Wikipedia
  • Ob es tatsächlich für echte Massenangriffe hätte eingesetzt werden können, ist nicht sicher, aber bei einer ähnlich hohen Exponierung wie unter Windows hätte es wohl viele Fälle gegeben
  • Diese Formulierung könnte vor allem dazu dienen, im Vergleich zu Android die Vorteile des eigenen Kontrollmodells hervorzuheben
  • Es ist zwar eher Anwaltssprache, aber dass Apple diesmal zu neuen Technologien wie MIE sehr detaillierte Unterlagen und selbstbewusste Aussagen veröffentlicht hat, ist für uns alle positiv
• Dieses System ist definitiv beeindruckend. Allerdings könnte die Abwehr unzureichend sein, wenn der Angreifer viele Wiederholungsversuche hat. Wenn etwa Zugriff über nicht benachbarte Objekte hinaus möglich ist oder nach viel Manipulation an Speicherallokationen zufällig ein passender Tag getroffen wird, könnte eine Umgehung gelingen. Die Wahrscheinlichkeit für einen passenden Tag liegt bei 1/16. Im Text fehlen aber Details, daher bin ich nicht sicher, ob meine Vermutung stimmt. Wenn das erfolgreich umgesetzt ist, müssten verbleibende Exploits auf Logikfehlern beruhen, was es für Angreifer deutlich schwerer machen würde
  • Ähnlich war es auch bei Android MTE: Dort waren probabilistische Angriffe mit vielen Wiederholungsversuchen möglich, die die geringe Tag-Größe ausnutzten. Der entscheidende Unterschied hier ist aber die konsistente synchrone Enforcement. Das heißt, es gibt sofort bei jeder manipulierten Speicherschreiboperation einen Trap und nicht erst beim Context Switch
  • Die übrigen 15 von 16 Versuchen neben der 1/16-Wahrscheinlichkeit führen alle zu einem Absturz. Solch instabile Bugs werden leicht für Nutzer oder Diagnosesysteme sichtbar, und wenn mehrere Schritte hintereinander erfolgreich sein müssen, ist reale Ausnutzung probabilistisch fast unmöglich
  • Bei staatlichen Angriffen mit langfristiger Infiltration, etwa über Supply-Chain-Angriffe, greifen solche Schutzmaßnahmen möglicherweise nicht
• Apples/ARMs Modell dürfte wesentlich ausgefeilter sein, erinnert aber an die Architektur zur Speichertagging von Burroughs large system (Referenz)
• Bei der Erklärung „Ein Angreifer darf den vom System gewählten Tag-Wert nicht vorhersagen können. Dafür wird der PRNG häufig neu geseedet, um neue Tags zu erzeugen“ liegt das Grundproblem in der niedrigen Entropie des Tags selbst (nur 4 Bit). Wenn ein Angreifer zufällig rät, ist die Erfolgswahrscheinlichkeit 1/16, und durch das Reseeding des PRNG ändert sich daran nichts. Hier scheint zusätzliche Erklärung nötig zu sein
  • Der Angreifer hat nur eine einzige Chance zum Raten. Wenn der Versuch fehlschlägt, wird der Prozess beendet oder der Kernel löst einen Panic aus. Beim nächsten Versuch gibt es einen neuen Tag, also muss erneut geraten werden; fortlaufende Versuche sind daher nicht möglich
  • 4 Bit sind trotzdem sehr wenig. Speicherallokationen passieren millionenfach pro Sekunde, und selbst bei häufigem Reseeding steigt die Kollisionswahrscheinlichkeit sehr schnell an
• Die größte Stärke dieser Geräteserie ist genau diese neue Funktion
• Wenn politische Maßnahmen wie die EU-Chatkontrolle umgesetzt werden, kann der Staat auf meinem Gerät auf alles zugreifen, was er will, und wenn Google WEI erzwingt, könnte das gesamte Web blockiert werden. Mit Secure Boot und MIE könnte es für Nutzer schwierig werden, ihre bisherigen Freiheiten wiederzuerlangen
  • Das heißt, um solche Freiheiten zu bewahren, müsste man Systeme und Dienste wohl stärker voneinander trennen beziehungsweise balkanisieren
  • Ich frage mich, ob die Verstärkung von MIE hier auch als Beschwerde darüber gemeint ist, dass Nutzerfreiheiten wie Jailbreaks eingeschränkt werden
  • Ich frage mich, wofür WEI steht
• Dass Google letztes Jahr MTE als Opt-in angeboten hat, war ein guter erster Schritt, aber wegen der fehlenden vollständigen Integration ist das nicht dasselbe wie das von Apple hervorgehobene EMTE-basierte MIE. Mit der Einführung auf dem iPhone 17 und Air bringt Apple beeindruckenderweise das branchenweit erste umfassende, immer aktive Speichersicherheitssystem. Auch wenn es schade ist, dass die führenden Bemühungen von GrapheneOS (Release-Beispiel, Bewusstseinsbildung) nicht angemessen gewürdigt wurden, hoffe ich, dass sich Apples ernsthafter Versuch schnell auf Google, Pixel OS und verschiedene Sicherheits-OS ausbreitet. GrapheneOS bestätigt damit erneut seine Rolle als Vorreiter bei Systemen, die auch gegen unbekannte Bedrohungen schützen
  • Apple bereitet sich in diesem Bereich schon seit langer Zeit vor. Das begann nicht erst zu dem Zeitpunkt, als GrapheneOS es aktiviert hat
• Es heißt zwar, Apple habe „2018 mit dem A12-Bionic-Chip branchenweit erstmals Pointer Authentication Codes (PAC) eingeführt, um die Integrität des Code-Flows zu schützen“, aber auch nach der Einführung von PAC gab es mehrfach vollständige Angriffsketten. PAC war kein Mittel, das Angriffe substanziell abgeschreckt hätte. Angreifer finden weiterhin Wege, PAC zu umgehen. Das sollte man bei der Bewertung der Wirksamkeit von MIE berücksichtigen
  • Tatsächlich hat Apple PAC nicht als Abschreckungsmaßnahme gegen Angriffe bezeichnet, sondern gesagt, der Effekt sei eine „erhöhte Exploit-Komplexität“. Der Satz ist etwas mehrdeutig, aber ich lese ihn so, dass PAC allein nicht reicht und ein kombinierter SW/HW-Ansatz nötig ist. PAC selbst ist bereits eine Hardware-Funktion, die Software-Änderungen erfordert, aber EMTE ist eine Technik mit deutlich größerem Umfang und höherem Abstimmungsbedarf
  • Es geht nicht darum, dass PAC bedeutungslos wäre; vielmehr wirkt es als Katalysator, der Angreifer dazu zwingt, unbedingt PAC-Bypässe zu finden. Es gibt nicht unbegrenzt viele PAC-Bypässe
  • Dass PAC mehrfach umgangen wurde, bedeutet nicht, dass es wirkungslos ist; gerade das zeigt, wie effektiv es arbeitet