Über Apple Exclaves

• Apples Exclaves sind eine Isolationsfunktion, die bestimmte sensible Ressourcen in einem separaten Bereich belassen soll, selbst wenn der XNU-Kernel kompromittiert wird; durch die Veröffentlichung des XNU-Quellcodes für M4 und A18 wurden Teile der Struktur sichtbar
• XNU basiert auf Mach, doch die eigentlichen Systemfunktionen sind im selben Privilegierungsbereich gebündelt und verhalten sich dadurch eher wie ein monolithischer Kernel; Exclaves stehen auf einer Linie mit der vertieften Absicherung durch Secure Enclave, PPL und SPTM
• Exclaves bestehen aus beim Booten definierten Domains und Ressourcen; Shared-Memory-Buffers, Audio-Buffers, Sensoren, Conclave, Services usw. werden durch neue Seitentypen in SPTM vor XNU geschützt
• Der Secure Kernel (SK) läuft auf demselben Application Processor wie XNU und laut Hinweisen im Quellcode möglicherweise mit einer seL4-verwandten Basis und der ARM-TrustZone-Secure-World, doch große Teile der internen Implementierung sind nicht offengelegt
• Die tatsächliche Sicherheitswirkung hängt davon ab, welche Komponenten in Exclaves verlagert werden; aktuelle Build-Images deuten auf Sicherheitsindikatoren für Kamera und Mikrofon, Teile der Apple Neural Engine, einige Treiber und Kommunikationskomponenten zur Secure Enclave hin

---

Monolithische Kernel und Apples Weg zu stärkerer Isolation

• Moderne Betriebssysteme arbeiten meist mit zwei Schutzdomänen: User Mode und Kernel Mode
  • Anwendungen können stark privilegierte Vorgänge wie Dateizugriffe oder Netzwerkkommunikation nicht direkt ausführen, sondern müssen sie über System Calls beim Kernel anfordern
  • Der Kernel prüft die Zugriffsrechte und gibt anschließend Ergebnisse wie etwa einen Handle für eine geöffnete Datei an den User Mode zurück
• Die meisten Betriebssysteme verwenden eine monolithische Kernel-Architektur; der Kernel hat uneingeschränkten Zugriff auf Hardware, Speicher und sämtliche Nutzerdaten
  • Je größer der Kernel wird, desto höher ist auch die Wahrscheinlichkeit für Schwachstellen
  • Die Ausnutzung einer Kernel-Schwachstelle kann zur vollständigen Kompromittierung des Systems führen
• Ein Mikrokernel kann die Sicherheitsisolation verbessern, indem er die Funktionen im Kernel reduziert und den Großteil der Aufgaben in separate unprivilegierte Prozesse auslagert
  • Nachteile bleiben Performance-Probleme und höhere Komplexität der Anwendungssoftware
• XNU, das iOS, macOS, tvOS, visionOS und watchOS gemeinsam nutzen, basiert zwar auf dem Mach-Mikrokernel, verhält sich in der Praxis aber wie ein monolithischer Kernel, weil viele Systemfunktionen innerhalb desselben Privilegierungsbereichs liegen

Apples Sicherheitsisolation vor Exclaves

• 2013 wurde mit dem iPhone 5s die Secure Enclave eingeführt
  • Auf dedizierten gehärteten CPU-Kernen läuft ein mikrokernelbasiertes OS namens SepOS
  • Der Kernel von SepOS ist cL4, eine angepasste Version von Apples L4-embedded
  • Sie dient zum Schutz kryptografischer Schlüssel und biometrischer Daten wie Face ID
  • Selbst wenn der iOS-Kernel kompromittiert wird, bleibt die Secure Enclave in der Regel unbeeinflusst, sofern kein zusätzlicher Exploit direkt gegen sie vorliegt
  • Secure Enclave und Secure Exclaves sind unterschiedliche Ziele
• 2017 wurde mit den A11-basierten iPhone 8 und iPhone X die Page Protection Layer (PPL) eingeführt
  • Nur einem Teil des Kernels wird das Recht gegeben, Speicherseitentabellen zu verändern; der übrige Kernel darf sie nicht direkt ändern
  • Die Angriffsfläche war klein und Umgehungen selten, doch der restliche Kernel behielt weiterhin viele Rechte, die für Datenkompromittierungen ausreichen
• 2021 bis 2023 wurde mit A15 und iOS 17 der Secure Page Table Monitor (SPTM) als Ersatz und Verbesserung für PPL eingeführt
  • Er schützt zusätzliche Speicherfunktionen und isoliert auf Ebene kleiner Kernel-Komponenten
  • Auch die Code-Signing-Prüfung zur Verifikation von Apple-Signaturen wurde ausgelagert
  • In dieser Zeit tauchten indirekte Verweise auf Exclaves im XNU-Quellcode auf; damals wurden sie als von SPTM verwaltetes Subsystem vermutet

Das Auftreten von XNU Exclaves im Jahr 2024

• Mit der Veröffentlichung des XNU-Quellcodes für Systeme auf Basis von M4 und A18 wurden Teile der Exclaves-Struktur sichtbar
  • Betroffen sind Systeme wie das iPhone 16
  • Auf früheren Prozessoren sind Exclaves nicht aktiviert
• Exclaves bezeichnen Ressourcen, die von XNU getrennt sind und so entworfen wurden, dass sie selbst bei einer Kompromittierung des Kernels geschützt bleiben
  • Ressourcen sind beim OS-Build vordefiniert
  • Sie werden über Namen oder IDs identifiziert
  • Sie haben einen Typ und werden beim Booten initialisiert
  • Sie sind in eigenen Domains organisiert
• SPTM schützt Exclave-Speicher mit eigenen Seitentypen vor XNU
• Die bestätigten Ressourcentypen zeigen, wo die Grenze zwischen XNU und Exclave entsteht
  • Shared-Memory-Buffers, auf die XNU und Exclave gemeinsam zugreifen können
    • Aus Sicht von XNU können sie als read-only oder read-write konfiguriert sein
  • Audio-Buffers und Sensoren, die für die Sicherheit von Funktionen wie Kamera- und Mikrofon-Zugriffsindikatoren genutzt werden
  • Conclave und der Conclave Manager, die mehrere Ressourcen in einer eigenen Sicherheitsdomäne bündeln
  • Services, mit denen XNU-Threads beim Aufruf Code im Exclave-Bereich ausführen können

Secure Kernel und Secure World

• Damit Exclave-Services isoliert von XNU laufen können, hat Apple den Secure Kernel (SK) eingeführt
• Die SK-Image-Datei enthält die Versionszeichenfolge „cL4“
  • Die IPC-Struktur wirkt näher an seL4 als am ursprünglichen L4-embedded von SepOS cL4
  • In SK-Strings tauchen häufig seL4-bezogene Begriffe wie capability, frame, untyped memory und minting auf
  • Apple veröffentlichte im April 2024 den Beitritt zur seL4 Foundation
• Anders als SepOS, das auf einem dedizierten Prozessor läuft, läuft SK auf demselben schnellen Application Processor wie XNU/iOS
• Diese Architektur erfordert zusätzliche Privilegierungsstufen des Prozessors; als mögliche Grundlage werden Virtualisierungserweiterungen, zusätzliche SPTM-Funktionen von Apple und ARM TrustZone diskutiert
  • Im XNU-Quellcode finden sich Verweise auf Übergänge in die Secure World von TrustZone
  • Daraus ergibt sich die Interpretation, dass XNU und iOS in der Insecure World laufen, SK dagegen in der Secure World
• SK stellt eine eingeschränkte Laufzeitumgebung für Exclaves, Ressourcen und Services bereit
  • Das unterscheidet sich von dem von ARM vorgeschlagenen Designmuster für Trusted Applications
  • Da die Angriffsfläche von Exclave-Services und Secure Kernel begrenzt ist, dürfte es deutlich schwieriger sein, aus der Secure World auszubrechen und XNU zu kompromittieren, als XNU direkt aus der Insecure World anzugreifen
• Im XNU-Quellcode wird der Übergang in die Secure World als RINGGATE bezeichnet
  • Dass SPTM diesen Übergang verwalten könnte, bleibt Spekulation; die betreffenden Bereiche sind nicht Open Source und erfordern Binäranalyse

Domains, Ressourcen und Conclave

• XNU initialisiert beim Booten eine zweistufige Kernel-Tabellenstruktur, um Informationen zu erkannten Exclave-Ressourcen zu speichern
  • root_table identifiziert Domains über ihren Namen
  • Jede Domain verweist auf eine zweistufige Tabelle mit den Ressourcen dieser Domain
• Die identifizierte Domain-Struktur sieht wie folgt aus
  • com.apple.kernel
    • Enthält unter anderem Conclave Launcher, Debug-Services, den ExclaveIndicatorController für Sicherheitsanzeigen, Logging-Services sowie FrameMint für den Start von ExclaveKit
    • Enthält auch den Shared-Memory-Buffer com.apple.storage.backend, den Exclave-Services für Datei-I/O im XNU-Bereich per Upcall verwenden
    • Enthält pro Conclave jeweils eine Conclave-Manager-Ressource
  • com.apple.darwin
    • In Open-Source-Komponenten gibt es keinen erkennbaren Anwendungsfall
  • com.apple.conclave.name
    • Für jede Conclave existiert genau eine Domain
    • Sie kann Services, Audio-Buffers, Shared-Memory-Buffers usw. enthalten
  • com.apple.driver.*name*
    • Domains pro Gerätetreiber, die laut Kommentaren existieren sollen, im Open-Source-Code aber nicht tatsächlich bestätigt werden
• Conclave ist sowohl ein Ressourcentyp, der mehrere Ressourcen enthalten kann, als auch eine Sicherheitseinheit, in der Services und Ressourcen wechselseitigen Shared Access haben
  • Für Mach-Tasks ist die Menge aufrufbarer Conclaves begrenzt
  • Jede Conclave besitzt einen Conclave Manager in der Kernel-Domain
  • Eine Conclave hat einen Lebenszyklus mit attach, launch, stop und detach
  • Es gibt außerdem Übergangszustände wie launching und stopping

Erzeugung, Anbindung und Ausführung von Conclaves

• posix_spawn() in XNU kann task_add_conclave() aufrufen, um eine Task mit einer Conclave-Manager-Ressource zu verbinden
  • Die Beziehung ist 1:1
  • Eine Task wird nur mit einem Conclave Manager verbunden und umgekehrt
• Eine Conclave spawnen dürfen launchd oder Tasks mit dem Entitlement com.apple.private.exclaves.conclave-spawn
  • Das Entitlement com.apple.private.exclaves.conclave-host wird eher als Recht interpretiert, sich selbst anzubinden, statt eine neue Task zu spawnen
• Der Kernel sucht die mit der Ziel-Conclave verbundene Conclave-Manager-Ressource in der Domain com.apple.kernel
  • Danach speichert er im Ressourcen-Struct der Conclave einen Tightbeam-Endpoint, der auf den Conclave-Manager-Endpoint zeigt
  • Tightbeam scheint ein RPC-Framework für die Kommunikation zwischen Exclave-Komponenten zu sein
• Die Ausführung einer Conclave muss durch die verbundene Conclave-Manager-Task erfolgen
  • Launch-Versuche warten, bis Exclaves vollständig bis zum Zustand EXCLAVES_BS_BOOTED_EXCLAVEKIT hochgefahren sind
  • Eine neue Mach Trap läuft in die Funktion _exclaves_ctl_trap(), wobei EXCLAVES_CTL_OP_LAUNCH_CONCLAVE zum Starten einer Conclave verwendet wird
  • In Produktionsumgebungen kann ein gestarteter Conclave-Host in einen tainted-Zustand geraten; ein anschließendes exit() kann dann einen Kernel Panic auslösen

Neue Mach Trap für Exclaves

• _exclaves_ctl_trap() ist eine neue Mach Trap zur Verarbeitung von Exclave-Funktionen
  • Je nach operation-Parameter führt sie verschiedene Aktionen aus
  • In der Regel prüft sie die für die aufgerufene Operation erforderlichen Entitlements
• EXCLAVES_CTL_OP_BOOT wird während des Systemstarts zweimal aufgerufen
  • Start von Exclaves Boot Stage 2
  • Boot von ExclaveKit
  • Aufrufer muss launchd sein oder das Entitlement com.apple.private.exclaves.boot besitzen
• Die übrigen wichtigen Operationen setzen mindestens voraus, dass die aktuelle Task das Entitlement com.apple.private.exclaves.kernel-domain besitzt oder die zugehörige Conclave-Manager-Task ist
  • EXCLAVES_CTL_OP_LOOKUP_SERVICES: Sucht Services in der Exclave-Domain der aktuellen Task und prüft bei Fehlschlag je nach Berechtigung zusätzlich die Darwin-Domain und die Kernel-Domain
  • EXCLAVES_CTL_OP_ENDPOINT_CALL: Ruft den Endpoint eines Exclave-Service in der Domain der aktuellen Task auf, wodurch der aktuelle Thread in die Secure World wechselt und bestimmten Code ausführt
  • Erzeugung benannter Buffer und copyin/copyout
  • Erzeugung von Audio-Buffern und copyout
  • Erzeugung, start, stop und status von Sensoren
  • Lookup von Notification-Ressourcen

Downcall und Upcall

• Downcall bezeichnet den Aufruf eines Exclave-Service-Endpoints in der Secure World und ist der Punkt, an dem die Ausführung von Secure-World-Code beginnt
• Ein Downcall schaltet den aktuellen Thread in die Secure World um und startet die Ausführung am Entry Point des Secure Codes
  • Die Arbeit wird nicht an einen anderen Thread delegiert
  • Die aufrufende Task muss das kernel-domain-Entitlement besitzen oder die mit dem Service-Conclave verbundene Conclave-Manager-Task sein
  • Eine Conclave kann bis zu 128 aufrufbare Services haben
• Offenbar plant XNU Threads über sk_enter() in den Secure Kernel ein
  • Möglicherweise besitzt SK keine eigenen unabhängigen Threads und XNU übernimmt das gesamte Thread-Scheduling für die Secure World
  • Ein in der Secure World laufender Thread kann übliche Scheduler-Aktionen wie yield, wait, suspend und interrupt ausführen
  • In diesem Fall verlässt der Thread die Secure World, kehrt in den XNU-Kernel-Kontext zurück und wird danach durch den Exclave-Scheduler-Code erneut in die Secure World eingeplant
• Die IPC-Struktur eines Downcalls wird vor dem Eintritt in die Secure World als Request- und Response-Buffer eingerichtet
  • Während der Vorbereitung der endgültigen IPC-Request-Struktur und des Aufrufs von sk_enter() sind Interrupts und Preemption deaktiviert
  • Der Grund ist, dass diese Struktur nur einmal pro CPU-Kern existiert
  • Die Downcall-Response kann wegen Unterbrechungen, Upcalls, yield oder Re-Scheduling im Per-Core-Response-Buffer einer anderen CPU zurückkehren
• Upcall beschreibt den Fall, dass ein in der Secure World laufender Thread über Tightbeam einen Exclaves-Upcall-Handler aufruft, wenn er Hilfe von XNU benötigt
  • Er ist auf bestimmte erlaubte XNU-Funktionen beschränkt
  • Ein Thread in einem Upcall darf nicht in den User Mode zurückkehren
  • Ein erneuter Eintritt per Downcall in die Secure World ist ebenfalls nicht erlaubt
  • Der Thread muss in den Secure-World-Kontext an genau die Stelle zurückkehren, an der er den Upcall ausgelöst hat
• Im Quellcode identifizierte Upcall-Kategorien sind Speicher, Dateispeicher, DriverKit, DriverKit Apple Neural Engine und Conclave-Steuerung

XNUProxy und Boot-Phasen

• Es gibt viele Verweise auf XNUProxy, doch seine genaue Position und Rolle sind nicht geklärt
  • Es könnte eine eigenständige Exclave-Domain sein
  • Es könnte ein Service oder Service-Bündel in der Domain com.apple.kernel sein, das bestimmte Downcalls verarbeitet
  • Es könnte auch ein von SPTM verwaltetes Subsystem sein, das Downcalls in die Secure World ausführt
• Kommentare in Exclaves_L4.h sagen, dass XNU Proxy mehrere Exclaves erreichbar macht
  • user app template
  • audio driver
  • ExclaveDriverKit
  • SecureRTBuddy für Always On Processor und Display Coprocessor
  • Conclave control, Conclave debug usw.
• Das Booten von Exclaves erfordert Abstimmung zwischen Insecure World und Secure World; bei Problemen endet es meist in panic()
• Der Bootvorgang ist in drei Stufen unterteilt
  • Stage 1 ist im Open Source nicht sichtbar und könnte ein Secure-Boot-Prozess sein, der SK in den Speicher lädt, die Code-Signatur prüft und dann die Ausführung ermöglicht
  • Stage 2 umfasst die Initialisierung des Upcall-Servers, das Sammeln von Boot-Informationen des Secure Kernel, die Initialisierung des Exclave-Schedulers, die Initialisierung der XrtHostedXNU-kext, die Multicore-Initialisierung, die Initialisierung von XNU Proxy, die Erkennung statischer Exclave-Ressourcen und die Erzeugung von Conclave-Manager-Endpoints
  • Stage 3 sucht den Service com.apple.service.FrameMint, führt Aufrufe im Zusammenhang mit framemint_framemint__init() und framemint_framemint_populate() aus und erreicht danach den Zustand EXCLAVES_BS_BOOTED_EXCLAVEKIT

SPTM-Speichertypen und verbleibende Grenzen

• SPTM weist Speicherseiten Typen zu, um die Zugriffskontrolle pro Subsystem durchzusetzen
  • Zu den bestehenden Typen gehören XNU_USER_EXEC, XNU_USER_DEBUG, XNU_USER_JIT, XNU_ROZONE, XNU_KERNEL_RESTRICTED sowie Typen im Zusammenhang mit TXM und DART
• Exclaves ergänzen neue SK-bezogene Typen
  • SK_DEFAULT: nur für SK, kein Zugriff durch XNU
  • SK_IO: nur für SK, kein Zugriff durch XNU
  • SK_SHARED_RO: von SK und XNU gemeinsam genutzt, für XNU aber nur lesbar
  • SK_SHARED_RW: von SK und XNU gemeinsam genutzt, für XNU les- und schreibbar
• Exclaves können als große Investition in defence in depth in Apples Betriebssystemen gesehen werden
  • Sie isolieren sensible Ressourcen und verringern damit die potenzielle Angriffsfläche
  • Sie zielen darauf ab, die Auswirkungen einer einzelnen Kernel-Kompromittierung zu begrenzen
• Welche Komponenten tatsächlich aus dem Kernel in Exclaves verlagert werden, wurde nicht direkt analysiert
  • Build-Images deuten auf Sicherheitsindikatoren für Kamera und Mikrofon, einige Funktionen der Apple Neural Engine, einige Gerätetreiber und Komponenten zur Kommunikation mit der Secure Enclave hin
  • Künftig könnten weitere Komponenten in Exclaves verlagert werden
  • XNU-Bereiche außerhalb von Exclaves bleiben weiterhin Angriffsziel
• Die Analyse basiert auf Apple Open Source XNU build 11215
  • Die genaue Position von ExclaveKit, ExclaveDriverKit und XNUProxy, der Mechanismus für den Übergang von XNU in die Secure World, der Secure Kernel sowie Userspace in der Secure World bleiben Bereiche für weitere Analyse

[GN⁺]

Hacker-News-Kommentare

• In Apples jüngsten Smartphone- und Notebook-SoCs ist Hardware-Unterstützung für verschachtelte Virtualisierung enthalten; dazu zählt auch das M4 iPad Pro, das für die Kamera-LED eine Exclave verwendet.
  Hoffentlich behandelt die nächste überarbeitete Ausgabe des Apple Platform Security Guide die SK-Exclave und Baseband-Gegenmaßnahmen für Wi‑Fi-Radarerkennung: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
  Zu Apples SPTM-Erweiterungen gibt es auch einen Reverse-Engineering-Beitrag zu SPTM: https://www.df-f.com/blog/sptm3
  XNU wird in Richtung einer von Mikrokernels inspirierten Struktur refaktoriert; das Ziel ist, die Codebasis zu verkleinern und sicherheitskritische Aufgaben nach außen zu verlagern. Die Trennung der Speicherbereiche wird vom Secure Page Table Monitor (SPTM) unterstützt, während Aufgaben wie Code-Signing, Rechteprüfung, Developer Mode und Restricted Execution Mode vom Trusted eXecution Monitor (TXM) übernommen werden.
  Es gibt mehr als 150 TrustZone-bezogene CVEs: https://www.cve.org/CVERecord/SearchResults?query=trustzone
  Google hat vor einigen Jahren auf Pixel ebenfalls pKVM mit verschachtelter Hardware-Virtualisierung implementiert und sogar Code in den Linux-Mainline eingebracht, der im Vergleich zu pKVM L0 die TrustZone-Berechtigungen kooperativ reduziert. Abgesehen von der Debian-VM „Linux Terminal“ wurden allerdings keine Abwehrfunktionen vorgestellt, die pKVM/AVF nutzen.

  • Die meisten TrustZone-CVEs betreffen verwundbare Software, die Hersteller in die von TrustZone geschützte Umgebung gepackt haben. Unter dieser Software ist vieles miserabel, während Berichte über eigentliche Hardware-Schwachstellen sehr selten sind.
  • Der Autor hat einen Folgebeitrag und ein überarbeitetes Diagramm veröffentlicht: https://randomaugustine.medium.com/more-speculation-on-excla...
    Zunächst wurde die Nutzung von TrustZone vermutet, aber die Exclave könnte auch die vorhandenen SPTM- und GXF-(Guarded Execution)-Privilegstufen verwenden. Wenn das so ist, gäbe es – abgesehen von RAM-Anforderungen und Entwicklungsaufwand – womöglich keinen grundlegenden Grund, warum es nicht auch auf dem iPhone 13 und neuer unterstützt werden könnte. Natürlich wäre das auch für Apple eine gewaltige Aufgabe.

• Steve glaubte offenbar aufrichtig, dass „ein Notebook das persönliche Tagebuch eines Menschen“ ist und Apple die Verantwortung hat, das zu schützen.
  Tim wäre wohl auch nicht CEO geworden, wenn er nicht dieselbe Überzeugung wie Steve gehabt hätte. Klingt seltsam, aber ich vermisse Steve wirklich.
  https://www.youtube.com/watch?v=Ij-jlF98SzA

  • Aus Sicht von Herstellern industrieller und wissenschaftlicher Geräte sind Apples verbraucherorientierte Geräte völlig nutzlos. Es wirkt wie Verschwendung, ein an sich leistungsfähiges Rechengerät auf diese Weise abzuriegeln.
    Mir gefällt auch nicht, wie Apple den Geräte- und Softwaremarkt selbst dann noch kontrolliert, wenn der Eigentümer des Geräts gewechselt hat. Ich meide solche Ökosysteme konsequent und verstehe nicht, warum so viele sogenannte „Hacker“ von Systemen begeistert sind, bei denen die Motorhaube zugeschweißt wurde.
  • Jobs war polarisierend und oft schroff, daher fragt man sich auch, warum man überhaupt einem Tech-Milliardär nachtrauern sollte. Trotzdem habe ich das Gefühl, Jobs und den Apple-Leuten etwas zu verdanken, die zu Produkten beigetragen haben, die ich mag, etwa den Mac, den iPod und das iPad.
    Vieles von dem, was Jobs gesagt hat, spricht mich noch immer an. Vor Kurzem hat Apple den „classic Mac“-Bildschirmschoner veröffentlicht, und er zeigt, wie sorgfältig die ursprüngliche Mac-GUI gestaltet war. Niemand vermisst die Zeit, in der App-Bugs das Betriebssystem zum Absturz brachten, aber ich wünschte, Apple würde sich heute noch genauso an Details festbeißen wie damals.
  • Wenn man die aufrichtigen Gefühle gegenüber Jobs sieht, fragt man sich, ob beim Einsatz und Erleben von LLMs etwas Ähnliches wirkt.
    Etwas unverblümt gesagt scheint da ein mystischer oder religiöser Aspekt mitzuschwingen. Es fühlt sich an, als sehnten sich Menschen nach einem gütigen, gottähnlichen Mann, der Wunder, Orakel, schöne Produkte und Rituale sowie eine elegante, wohlhabende und ewige Zukunft liefert. Es ist, als würde eine Art spirituelles „Loch“ gefüllt.
    Das soll keine Leute herabsetzen, die Jobs oder LLMs mögen; ich teile nur eine Beobachtung.
  • Ich verstehe, dass der Exclave-Beitrag Gedanken an Steve ausgelöst hat, aber mir ist nicht klar, wie das eine zum anderen geführt hat. Ich wäre neugierig auf eine Erklärung.

• Verwandter Thread: „Apple rearranged its XNU kernel with exclaves“ https://news.ycombinator.com/item?id=43314171

  • Laut der Zusammenfassung dieses Beitrags bezeichnet Exclave bestimmte Ressourcen, die vom Hauptkernel XNU getrennt sind und auf die selbst bei einer Kompromittierung des Kernels nicht zugegriffen werden kann.
    Außerdem sei es nicht ungewöhnlich, dass Zwischenreleases von macOS bereits Funktionen zur Vorbereitung der nächsten Hauptversion enthalten; Exclave könnte die grundlegendste und wichtigste Funktion sein, die in Sonoma 14.4 sowie iOS 17.4, iPadOS 17.4 und watchOS 10.4 hinzugefügt wurde.
    https://eclecticlight.co/2024/08/20/sonomas-unfinished-busin...

• Dass für die Steuerung der physischen Kamera-LED eine Security-Exclave verwendet wird, ist ziemlich überraschend, und es wirkt so, als hätte man für eine einfache Aufgabe ein übermäßig komplexes Design gebaut.
  Es hätte vermutlich gereicht, im Kameramodul eine sehr kleine dedizierte Hardware-Logik unterzubringen. Man könnte den digitalen I/O oder die Stromversorgung der Kamera gaten und einen Pulse Stretcher vorsehen, damit die LED jedes Mal mindestens einige Sekunden lang leuchtet, um Angriffe zu verhindern, bei denen die Kameralogik schnell ein- und ausgeschaltet wird.
  Für das Mikrofon wäre eine ähnliche Schaltung mit einer physischen LED in einer anderen Farbe ebenfalls sinnvoll. Ein per Software auf dem Bildschirm angezeigter Punkt allein reicht nicht aus.

  • Es ist komplexer, als man denkt. Eine „Kamera“ ist ein Verbund aus mehreren Komponenten. Naheliegend wäre es, sich am CMOS-Sensor-Strom zu orientieren, aber es gibt verschiedene Energiezustände wie Standby, Sleep oder Idle. Deshalb müsste die Hardware-Schaltung wahrscheinlich nicht nur Spannung, sondern auch Strom erkennen. Oder sie müsste weiter oben I2C-Nachrichten parsen, um Änderungen des Power-Modus zu erkennen.
    Der LED-Treiber müsste auch die Bildschirmhelligkeit oder Informationen vom Umgebungslichtsensor kennen. Er müsste hell genug sein, um auch in direktem Sonnenlicht sichtbar zu bleiben, aber diese Helligkeit wäre in dunklen Umgebungen störend und könnte die normale Kameranutzung beeinträchtigen.
    Wenn man glaubt, dass SK sicher ist, ist es einfacher und zugleich besser, das dafür zu verwenden. Wenn SK nicht sicher ist, bricht ohnehin die ganze Annahmebasis zusammen.
  • Es ist kein übermäßiges Design. Es ist wegen solcher Forschung und der Ergebnisse anderer Forschender wie Charlie Miller nötig.
    Apple macht Dinge in der Regel nicht absichtlich ohne guten Grund komplex.
    https://news.ycombinator.com/item?id=42260379
  • Ich frage mich, ob es wirklich überdesignt ist oder ob es eine Lösung für etwas ist, das man erst beim Ausliefern von enorm vielen Smartphones entdeckt hat. Ich habe die Kamera bisher nicht als Security-Vektor betrachtet, aber vielleicht sieht Apple das so.
  • Mehr Hintergrund dazu gibt es hier: https://news.ycombinator.com/item?id=42260379
  • Es scheint nicht nur um die Kamera-LED zu gehen, sondern auch um Bildschirmindikatoren wie die orangefarbenen, grünen und blauen Punkte in der Menüleiste, die erscheinen, wenn eine App auf Mikrofon, Kamera oder Bildschirmaufnahme zugreift.

• Ich frage mich, wer der Autor dieses Textes ist. Er ist sehr ausgefeilt und gut geschrieben, und auch aus der Perspektive von jemandem, der Exclaves verfolgt hat, gut aufbereitet.

• Ich frage mich, wie sich das mit Linux’ Virtualization Based Security vergleichen lässt.
  Laut der Seite mit dem Video kann diese Sicherheitsfunktion den Kernel härten und sicherstellen, dass wichtige Kernel-Ressourcen auch dann nicht manipuliert werden können, wenn der Kernel kompromittiert wird. VBS nutzt Hardware-Virtualisierung und den Hypervisor Hyper‑V, um eine isolierte virtuelle Umgebung auf einer höheren Vertrauensebene, Virtual Trust Level 1 (VTL1), zu schaffen; VTL1 hat mit dem Secure Kernel einen eigenen Kernel, der vom Guest-Kernel getrennt ist.
  https://lssna24.sched.com/event/1aIeD/linux-virtualization-b...

  • Exclaves laufen auf einer parallelen Vertrauensebene.

• Exclave wirkt wichtig, aber wie ein Zwischenschritt. Apple macht XNU zwar risikoärmer, übernimmt aber noch nicht vollständig eine Mikrokernel-Architektur, sondern agiert weiterhin defensiv.
  Wenn ich wetten müsste, würde ich sagen, dass Exclaves eine Brücke zu einer größeren Veränderung sind. Das könnte ein modulareres Betriebssystem wie Fuchsia sein oder ein CHERI-artiges Sicherheitsmodell, das Memory Safety auf Hardware-Ebene erzwingt.
  Apple liegt bei der Sicherheit von Consumer-Betriebssystemen vorne, aber Exclaves wirken eher wie eine Patchwork-Verbesserung als wie das Ergebnis eines vollständig neu gedachten Systemdesigns. Trotzdem ist das möglicherweise die größte Sicherheitsveränderung im Mainstream-Betriebssystemdesign der letzten zehn Jahre, und es dürfte noch einige Jahre dauern, bis die volle Wirkung sichtbar wird.

  • Es wirkt wie eine Rückkehr zu den Mikrokernels von früher, nur mit modernen Lösungen und neuen Anforderungen.
    Als Mach entwickelt wurde, war Security noch längst nicht so ein großes Thema wie heute. Die Leistung heutiger Maschinen ist so hoch, dass der Overhead durch die Interprozesskommunikation eines Mikrokernels möglicherweise vernachlässigbar geworden ist.

• Ich bin mit Inhalten auf diesem Niveau nicht vertraut, aber für mich sieht es so aus, als könnte man den Enclave selbst angreifen und damit auf eine noch höhere Privilegienstufe als den Kernel eskalieren. Ich frage mich, ob es sich bei diesem Hardware-Stück um so etwas wie einen Coprozessor handelt.

  • Exclave ist keine Hardware, sondern isolierte Software, die bestimmte sensible Aufgaben übernimmt, auf die der Kernel keinen Zugriff haben soll.
    Wenn man sie also ausnutzt, erhält man tatsächlich Zugriffsrechte, die der Kernel nicht hat. Aber genau das ist beabsichtigt. Das Ziel ist, dass selbst bei einer Kompromittierung des Kernels kein Zugriff auf diesen sensiblen Bereich möglich ist.

• Laut der Apple-Dokumentation wird SPTM nicht verwendet, daher frage ich mich, welche Auswirkungen das auf die macOS-Sicherheit hat: https://support.apple.com/guide/security/operating-system-in...
  Im Moment scheinen bestehende Exclaves wie die für Kameraindikatoren auf macOS keine große Rolle zu spielen, weil MacBooks dafür dedizierte Hardware haben. In Zukunft könnte es aber Exclaves geben, die auch auf macOS Anwendung finden.

  • Ich glaube, man sollte diese Fußnote noch einmal lesen. Dort steht, dass die Page Protection Layer (PPL) und der Secure Page Table Monitor (SPTM) auf allen Plattformen außer macOS die Ausführung signierten und vertrauenswürdigen Codes erzwingen. macOS ist aus gutem Grund dafür ausgelegt, auch beliebigen Code auszuführen. Andere Sicherheitseigenschaften, einschließlich des Schutzes von Seitentabellen, gibt es auf allen unterstützten Plattformen.
    Das bedeutet also nicht, dass macOS SPTM nicht verwendet. Es bedeutet, dass macOS SPTM nicht dafür verwendet, die Ausführung unsignierten Codes zu verhindern. macOS muss es Nutzern ermöglichen, nach einigen Schritten auch unsignierten Code auszuführen.

• Es stellt sich die Frage, ob App-Entwickler Exclaves nutzen können. Es ist frustrierend, wenn Apple intern beeindruckende neue Funktionen baut, sie für Entwickler aber komplett abschottet. Dadurch müssen Dinge wie Banking-Apps, Wallets und sichere Messenger weiterhin im weniger sicheren User Space laufen.

  • Nicht unbedingt. Auch Apples User Space ist im Lauf der Zeit immer sicherer geworden.
    Ein einfaches Beispiel: Aktuelle macOS-Versionen führen alle Apps in einer Sandbox aus, auch wenn die App dies nicht ausdrücklich auswählt. Diese Sandbox verhindert, dass Apps die Dateien anderer Apps verändern, was früher eine große Schwachstelle des Sicherheitssystems war. Bundle-Signaturen wurden nämlich nur beim ersten Start geprüft und nicht bei jedem weiteren Ausführen.
  • Nach meinem Verständnis ist das im aktuellen Design nicht möglich. Exclaves sind in das gesamte Betriebssystem integriert und werden als Teil des Bootvorgangs gestartet, daher sind sie relativ statisch. Aus Sicherheitsgründen ist es wahrscheinlich, dass auch die Beziehungen dieser Komponenten statisch festgelegt sind.
    Außerdem handelt es sich derzeit um eine Kernel-zu-Kernel-Struktur, sodass Third-Party-Support, falls es ihn gäbe, wohl darauf beschränkt wäre, Dinge wie Treiber für Sicherheitsgeräte zu implementieren. Apple hat allerdings darauf hingearbeitet, Third-Party-Treiber nicht in den Hypervisor, sondern in den User Space zu verlagern. Wenn man bedenkt, dass dieser Übergang parallel zur Exclave-Entwicklung verläuft, wirkt es nicht so, als wolle Apple Third-Party-Treiberentwickler künftig Exclaves nutzen lassen.
    Dass Apple solche vom Kernel erzwungenen Plattformfunktionen intern deutlich weiter stabilisiert, bevor sie extern veröffentlicht werden, kommt häufig vor. Pointer Authentication in arm64e ist ein ähnliches Beispiel.
  • Derzeit nicht.