- Der XNU-Kernel von Apples Betriebssystemen bot grundsätzlich bislang eine einzelne Vertrauensdomäne.
- In jüngster Zeit werden Änderungen vorangetrieben, um die Auswirkungen von Sicherheitslücken durch Trennung der Kernel-Architektur und stärkere Mikrokernelisierung zu verringern.
- Mit dem 2023 eingeführten Secure Page Table Monitor (SPTM) wurden Kernfunktionen separiert und eine neue Struktur von Vertrauensdomänen geschaffen.
- Neuere Sicherheitsmechanismen wie Exclaves und der Trusted Execution Monitor (TXM) werden auf Basis von SPTM umgesetzt.
- Diese strukturellen Verbesserungen führen dazu, dass selbst bei einer Kompromittierung des Kernels nicht sofort das Vertrauensniveau des gesamten Systems sinkt.
Überblick
Der XNU-Kernel, das Herzstück von Apples Betriebssystemen, wird zwar als Hybrid-Kernel bezeichnet, arbeitet in der Praxis jedoch in einer Art monolithischer Struktur, in der sämtliche Systemfunktionen in einem einzigen privilegierten Vertrauensbereich konzentriert sind. Dadurch entsteht das Problem, dass bei einer Kompromittierung des Kernels sofort das gesamte System ernsthaft bedroht ist. In jüngster Zeit hat Apple den Kernel stärker aufgeteilt und näher an ein mikrokernelartiges Design gebracht, indem etwa zentrale Funktionen wie Seiten-Tabellen-Manipulation oder kryptografiebezogene Aufgaben aus dem Kernelbereich heraus verlagert wurden.
Motivation der Änderungen und Forschungsrichtung
- Die Notwendigkeit, die Kernel-Struktur zur Stärkung der Sicherheit zu verbessern, ist stärker in den Vordergrund gerückt.
- Ziel ist es, die negativen Auswirkungen einer Ausnutzung von Kernel-Schwachstellen auf das Gesamtsystem zu minimieren.
- Es gibt nur wenig frühere Forschung, die wissenschaftlich analysiert, wie neue Mechanismen wie SPTM tatsächlich entworfen sind und funktionieren.
- Diese Arbeit untersucht solche bislang nicht offengelegten neuen Funktionen systematisch und ordnet die Wechselwirkungen sowie die Wirkung aller aktuellen Sicherheitsmechanismen ein.
Zentrale Mechanismen von SPTM (Secure Page Table Monitor)
- SPTM ist die höchstprivilegierte Komponente im System und arbeitet auf Guarded Level 2 (der höchsten Privilegstufe) zusammen mit dem Guarded Execution Feature (GXF).
- GXF ergänzt die bestehende Ausnahmelevel-Struktur von AArch64 um horizontale Schutzebenen und isoliert sensible Systemaktivitäten vor direktem Zugriff durch XNU.
- SPTM stellt auf Grundlage von Frame-Retyping und Regeln für Memory-Mapping Vertrauensdomänen bereit und trennt Bereiche nach Funktion.
- Repräsentative Beispiele für diese Vertrauensdomänen sind TXM (zuständig für Code-Signing und Rechteprüfung) und Exclaves (eine moderne Sicherheitsfunktion zur Bereichstrennung).
Exclaves und Kommunikationsmechanismen
- Exclaves sind Ausführungsumgebungen, die in unabhängigen Vertrauensbereichen laufen und sich auf das SPTM-basierte System für Speicherschutz und Kontrolle stützen.
- Die Kommunikation zwischen Exclaves und dem System wird auf verschiedene Weise umgesetzt, darunter xnuproxy (ein Handler für Sicherheitsanfragen) und das Tightbeam IPC-Framework.
- Tightbeam verfügt über eine komplexe IPC-Struktur mit Endpoint-Erzeugung, Nachrichtenpuffern und Client-Server-Verbindungen.
- Als konkretes Beispiel für die Nutzung von Exclaves umfasst die Analyse auch die Steuerung von Privatsphäre-Indikatoren, etwa Anzeigen für Aufnahme- oder Audionutzung.
Sicherheitsverstärkung und Ausblick
- Da zentrale Systemfunktionen vom direkten Zugriff durch XNU getrennt wurden, gibt es zusätzliche Schutzmechanismen, die das Vertrauensniveau des Gesamtsystems selbst dann bewahren, wenn der Kernel kompromittiert wird.
- Die detaillierte Analyse der Wechselwirkungen zwischen SPTM, Exclaves und TXM zeigt, dass ein deutlich stärkeres mehrstufiges Schutzsystem als zuvor entstanden ist.
- Im Fazit der Arbeit werden der Stand seit der Einführung von SPTM, die Möglichkeiten weiterer Sicherheitsverstärkung, verbleibende Grenzen und Richtungen für Anschlussforschung kurz dargestellt.
Aufbau und Hinweise zu den vertieften Inhalten
Kapitel 1: Motivation – Ziele – Aufbau
- Historischer Kontext der Aufspaltungsbestrebungen beim Apple-Kernel und Forschungsbedarf
- Hervorhebung der Beiträge dieser Studie
Kapitel 2: Hintergrund und Grundlagen
- Einführung in die Ausnahmelevel der AArch64-Architektur, Speicherzugriffsverfahren und spezielle Schutztechniken in Apple-Chips (Fast Permission Restrictions, Page Protection Layer, Guarded Execution Feature, Shadow Permission Remap Register)
- Überblick über bestehende Sicherheitsforschung und ihre Grenzen
Kapitel 3: Analyseumgebung
- Beschreibung der Zielhardware, Firmware, Tools, Symbole und Apple-spezifischen Register
Kapitel 4: Überblick über das Gesamtarchitektur-Design
- Visualisierung der gesamten Systemstruktur über EL (Exception Level) und GL (horizontale Schutzebenen) hinweg
Kapitel 5: Vertiefte Struktur von SPTM
- Detaillierte Erläuterung der Grundstruktur und Initialisierung von SPTM, der Aufrufwege (Kernel, TXM, Secure Kernel) sowie von Headern und Dispatch-Tabellen
- Interne Ereignisverarbeitung in SPTM, GENTER und Abläufe bei der Verarbeitung von SVC/HVC (Hypervisor-/Supervisor-Calls)
- Schrittweise Beschreibung der Frame-Retyping-Logik: Aufruf und Prüfung, Validierung nach Typ und Domäne, Aktualisierung von SPRR (Permission Remapping) sowie Abschluss des Aufrufs
- Prozesse und Schutzmechanismen beim Page Mapping
Kapitel 6: Rolle des Secure Kernel
- Grundlagen des sicheren Betriebs wie Aufrufe des Secure Kernel an SPTM und SVC-Verarbeitung
Kapitel 7: Exclaves-System
- Wichtige Komponenten wie Exclaves, Exclavecore und ExclaveKit
- Exclave-Speicher- und Ressourcenverwaltung, Gruppierung nach Domänen, Zustandsmaschine von Conclaves (Teilbereichen) und Interaktion mit dem User Space
- Kommunikationsverfahren wie Endpoint-Erzeugung und -Scheduling, Mach-Ports, IPC im Stil von seL4, xnuproxy, Tightbeam sowie konkrete Nutzungsbeispiele (z. B. Privatsphäre-Indikatoren)
Kapitel 8: TXM (Trusted Execution Monitor)
- Wie TXM mit SPTM zusammenarbeitet, einschließlich Dispatch-, Retyping- und Betriebsstruktur geschützter Bereiche
- Erläuterung der Sicherheitsverantwortung von TXM und seiner Aufrufverarbeitung
Kapitel 9–10: Gesamtdiskussion und Fazit
- Sicherheitstechnische Implikationen der Einführung von SPTM und Exclaves, aktuelle Grenzen und künftige Richtung
- Abschluss der Studie sowie Anhänge mit Referenzmaterial und Begriffserläuterungen
Erläuterung zentraler Begriffe
- XNU: Der Kernkernel von Apples Betriebssystemen; die Abkürzung steht für „X is Not Unix“.
- SPTM: Zentrales Modul zur Vergabe von Vertrauensdomänen durch Speicherschutz und Aufteilung
- TXM: Sicherheitsaufsicht für sensible Aufgaben wie die Prüfung von Code-Signaturen
- Exclaves: Vertrauenswürdige Sicherheitsumgebungen, die in getrennten physischen und logischen Bereichen isoliert ausgeführt werden
- Tightbeam IPC: Framework für sichere Kommunikation zwischen Exclaves und dem System
- GXF/GL: Schutzbezogene Ausnahmeebenen nach AArch64 sowie die darauf aufbauende Steuerung horizontaler Vertrauensbereiche über Guarded Levels
Fazit
Die Sicherheitsarchitektur moderner iOS-Systeme entwickelt sich mit SPTM, TXM und Exclaves als Zentrum in Richtung einer maximalen Trennung von Vertrauen und Aufgabenverteilung. Dieses hierarchische Schutzsystem reduziert das Risiko einer Kompromittierung unterhalb der Kernel-Ebene drastisch und schafft eine technische Grundlage, um auch künftigen Sicherheitsbedrohungen robust zu begegnen.
1 Kommentare
Hacker-News-Kommentare
Ich finde, dass SEAR und das Apple-Team bei der iOS-Sicherheit wirklich hervorragende Arbeit leisten, und dafür möchte ich ihnen großes Lob aussprechen.
Beeindruckend ist auch der Einsatz, Sicherheitsfunktionen von der Hardware-Ebene an über den gesamten Stack hinweg einzubauen, sowie reale ITW-Exploits zu untersuchen und kontinuierlich nach Wegen zu suchen, sie zu blockieren.
Sie haben zum Beispiel Funktionen wie PPL eingeführt, und wenn sie zu dem Schluss kommen, dass diese nicht perfekt sind, werfen sie sie entschlossen wieder weg und suchen nach neuen Techniken.
Apple ist vertikal integriert, deshalb ist so etwas dort viel einfacher als bei Android. Bei Android muss man Hardware-Hersteller wie QC und Mediatek um Zusammenarbeit bitten und mehrere Stufen durchlaufen, etwa den Linux-Kernel, AOSP und LLVM upstream.
Pointer Authentication Codes (PAC) sind ebenfalls ein gutes Beispiel. Apple ist mit der Haltung „Wir probieren es einfach aus“ herangegangen, hat einen eigenen LLVM-Branch gepflegt, die Technik eingeführt und damit tatsächlich ITW-basierte Angriffe entschärft und das Problem gelöst.
Ich kaufe Apple-Produkte nicht nur deshalb, weil Sicherheit und Privatsphäre hervorragend sind, sondern auch, weil Apple solche Funktionen mit Leidenschaft und aufrichtig vorantreibt, obwohl das nichts ist, was das Unternehmen zwingend zur Monetarisierung tun müsste.
Tatsächlich geht das über Marketing hinaus: Sie holen die besten Hacker aus der Jailbreaking-Community ins Security-Team und bringen Innovationen wie Private Relay, Private Mail, Trusted Compute und Multi-Party Inference.
Natürlich gibt es auch klare Probleme mit Apples heuchlerischer Haltung. Zum Beispiel die Zulassung von VPNs (mit Ausnahme des Traffics zu Apple-Servern) oder privacy-freundliche Standardeinstellungen (mit Ausnahmen wie Wi‑Fi Calling oder „journaling suggestions“) sind enttäuschend.
De facto gilt also die Einschränkung, dass man gegenüber Apple und einigen Mobilfunkpartnern nicht wirklich abgesichert ist, aber Google wirkt eher wie „sicher vor allen außer Google oder Käufern von Google-Werbung“, deshalb liegt Apple meiner Meinung nach deutlich vorn.
Selbst nach einem enormen technischen Aufwand bleibt in iMessage weiterhin ein Pfad bestehen, über den fragwürdiger Code im Kernel ausgeführt werden kann, weshalb 0-Click-Exploits weiterhin existieren.
Ein weiterer Vorteil dieser Bemühungen ist, dass sich die Sicherheit aller Plattformen quasi automatisch erhöht, sobald ein Codepfad auf einem neuen, von Apple gehärteten Prozessor auch nur ein einziges Mal ausgeführt wird.
Theoretisch lassen sich damit sogar Probleme leichter erfassen, die allein durch statische Analyse schwer zu finden wären, und man kann über einfache Crashes hinaus tiefere Einsichten gewinnen.
Google hätte MTE eigentlich schon vor einigen Jahren hinzufügen können, wollte aber keine verpflichtende Durchsetzung für OEMs als Teil der Android-Zertifizierung.
In gewisser Weise wiederholt sich damit dieselbe Geschichte wie bei OS-Updates.
Dass Apple sich derzeit um Sicherheit kümmert, dient nicht nur dem Schutz der Nutzer.
Im Kern geht es auch darum, es Nutzern schwerer zu machen, nicht genehmigte Software selbst auszuführen oder Dinge wie Jailbreaks durchzuführen, um das App-Store-Monopol aufrechtzuerhalten.
Letztlich werden also eher die Interessen des Unternehmens als die der Nutzer priorisiert.
Wenn ich über iOS-Sicherheit lese, bin ich immer wieder über ihre Komplexität erstaunt.
Da gibt es Hardware-Ebene, Kernel-Ebene, verschiedene Sandboxing-Techniken und insgesamt ziemlich viele Schichten.
Ich frage mich, ob diese Struktur ein „angeklebtes Provisorium über einem Design mit vorausgesetztem historischen Vertrauen“ ist.
Wenn man es von Grund auf neu entwerfen würde, könnte man es dann einfacher machen, und gibt es tatsächlich ein Betriebssystem (OS), das so entworfen wurde?
Schwachstellen lassen sich nicht vermeiden, je mehr unterschiedliche Anwendungsfälle eine Plattform unterstützen soll.
Die Antwort darauf ist genau mehrschichtige Verteidigung (Defence-in-depth).
iOS basiert auf MacOS, und MacOS basiert auf NeXT, dessen Wurzeln wiederum bei Unix liegen.
Es wurde von Anfang an mit geringerem Vertrauen in den Nutzer entworfen.
Je nach Epoche hat sich der Grad des Vertrauens in Nutzer verändert, und in jüngerer Zeit ist alles durch ständig verbundene Netzwerkfunktionen und neue Bedrohungen nach Spectre noch komplexer geworden.
Auf die Frage, ob es sich um ein Provisorium für historische Designentscheidungen handelt, würde ich sagen: ja.
Es ist das Ergebnis von Bemühungen, die Grenzen des Unix-Sicherheitsmodells und der systemnahen Programmierung in C auszugleichen.
Würde man heute ganz neu entwerfen, könnte man etwa Capability Architecture einsetzen, um die Komplexität zu verringern, aber wegen POSIX-Kompatibilitätsproblemen existiert so etwas in der Praxis meist nur akademisch oder als Hobbyprojekt.
Wenn man zu einem vollständig neuen Modell wechselt, müsste man den Großteil bestehender Unix-Programme sofort aufgeben, deshalb ist eine praktische Einführung äußerst schwierig.
seL4 ist eine schnelle, hochsichere und formal verifizierte Mikrokernel-Architektur.
Hervorragend sind die hochstufige Zugriffskontrolle, die Unterstützung virtueller Maschinen und mehr.
Erklärung zur seL4-Mikrokernel-Architektur
Allerdings fehlt der „Rest“, weshalb ich es eher für forschungsnah als für ein tatsächliches Betriebssystem halte.
Ich denke, man könnte beides ausprobieren.
Auch „Hardware-Sicherheit“ hat ihre eigenen Vertrauensannahmen, aber letztlich ist sie ebenfalls nur fest verdrahtete Software, und je höher die Komplexität, desto größer wird auch die Wahrscheinlichkeit von Bugs.
Auf dieser Hexacon-Keynote von Ivan Krstić wurde angekündigt, dass Apple das Bug-Bounty-Programm ausbaut.
Zugehöriger offizieller Blog
Ich frage mich, ob das Problem unverschlüsselter Verbindungen bei regelmäßigen Updates oder beim Starten von Apps inzwischen gelöst wurde.
Relevantes Referenzmaterial