Mehrere neue macOS-Sandbox-Escape-Schwachstellen

 (jhftss.github.io)
1 Punkte von GN⁺ 2024-11-09 | 1 Kommentare | Auf WhatsApp teilen
  • In der Forschung zu macOS-Sandbox-Escapes erwiesen sich XPC-Dienste der PID-Domain, die bislang vergleichsweise wenig beachtet wurden, als Angriffsfläche und führten zur Entdeckung von mehr als 10 neuen Schwachstellen
  • Das Hauptziel sind nicht Mach-Dienste der System-/User-Domain, sondern XPC-Dienste vom Typ Application, die beim Laden von Apps oder Frameworks in der PID-Domain registriert werden
  • Zu den betroffenen Fällen gehören CVE-2023-27944, CVE-2023-32414, CVE-2023-32404, CVE-2023-41077, CVE-2023-42961, CVE-2024-27864 und CVE-2023-42977; einige reichen bis zu TCC-Umgehung, SIP-bezogenen Berechtigungen und Auswirkungen auf iOS
  • Wiederkehrende Schwachpunkte waren, dass nicht isolierte Dienste beim Verarbeiten von Dateien, Verzeichnissen, Archiven und DMGs quarantine-Extended-Attributes, Pfad-Strings und die Prüfung von Client-Berechtigungen nicht sicher behandelten
  • Apples Reaktion umfasste das Entfernen verwundbarer XPC-Dienste, die Normalisierung von Eingaben, die Verlagerung auf serverseitige Prüfungen und die Anforderung von private entitlements; dennoch stehen noch 5 gemeldete Fälle ohne Patch aus

macOS-Sandbox-Modell und Ziel des Ausbruchs

  • Unter macOS laufen viele Prozesse, darunter Apple-eigene Dienste und Drittanbieter-Apps, in einer eingeschränkten Sandbox-Umgebung
  • Selbst wenn ein Angreifer in einem Sandbox-Prozess Remote Code Execution (RCE) erlangt, sind Ausführungsmöglichkeiten und Dateizugriffsrechte begrenzt; der nächste Schritt ist daher ein Sandbox-Escape, um weiterreichende Rechte zu erhalten

  • App Sandbox

    • Viele Apps laufen aufgrund der Mac-App-Store-Anforderungen unter den Einschränkungen der App Sandbox
    • Sandbox-Apps müssen das Entitlement com.apple.security.app-sandbox besitzen
    • Die Einschränkungen werden in der Phase der dyld-Initialisierung angewendet, also noch vor der main-Funktion der App
    • Nach Eintritt in die App Sandbox wird die App containerisiert, und Dateioperationen sind auf den Pfad des Daten-Containers beschränkt
    • Dateien, die von Sandbox-Apps erstellt werden, erhalten standardmäßig das Extended Attribute com.apple.quarantine
    • Das Sandbox-Profil enthält Regeln, die das Entfernen dieses Extended Attributes verhindern
    • Die Detailberechtigungen der App Sandbox sind in /System/Library/Sandbox/Profiles/application.sb definiert
    • Netzwerk, Hardware, Dateisystem und zugängliche Mach-Dienste sind eingeschränkt
    • Per fork erzeugte Kindprozesse erben die App-Sandbox-Beschränkungen des Elternprozesses
    • Prozesse, die über LaunchService.framework gestartet werden, erben diese Einschränkungen nicht; so kann etwa mit dem Systembefehl open direkt eine nicht sandboxierte App ausgeführt werden

  • Service Sandbox

    • Viele Daemon-Dienste von Apple laufen im Kontext der Service Sandbox
    • Service-Sandbox-Profile liegen hauptsächlich unter /System/Library/Sandbox/Profiles/*.sb und /usr/share/sandbox/*.sb
    • Die Einschränkungen der Service Sandbox werden im main der Dienste manuell durch Aufruf der API sandbox_init_XXX angewendet
    • Dienste innerhalb der Service Sandbox werden in der Regel nicht containerisiert
    • Ein wichtiger Unterschied ist, dass in der Service Sandbox erzeugte Dateien standardmäßig nicht unter quarantine gestellt werden
    • Wenn die zugehörigen quarantine-APIs nicht manuell aufgerufen werden, erhalten erzeugte Dateien kein quarantine-Attribut

Bisherige Wege für macOS-Sandbox-Escapes

  • Angriffe über LaunchService.framework

    • Eine der bisher gängigen Methoden war der Angriff auf nicht sandboxierte Apps über LaunchService.framework
    • CVE-2021-30864 ist ein Fall, in dem die Umgebungsvariable $HOME bei der nicht sandboxierten System-App Terminal.app manipuliert wurde
    • Beim Start von Terminal wurde ein bösartiger Payload unter dem kontrollierbaren Pfad $HOME/.profile ohne Sandbox-Beschränkungen ausgeführt
    • Ein weiteres Szenario besteht darin, eine neue nicht sandboxierte App abzulegen und anschließend zu starten
    • Allerdings werden von Sandbox-Apps neu abgelegte Apps unter quarantine gestellt, wodurch ihre Ausführung blockiert wird
    • Wenn sich Dateien oder Ordner ohne quarantine ablegen lassen, kann die App Sandbox vollständig umgangen werden
    • CVE-2023-32364 ist ein Fall, der ausnutzt, dass devfs keine Extended Attributes unterstützt, um einen Ordner ohne quarantine abzulegen

  • Angriffe auf zugängliche Mach-Dienste

    • Die zweite gängige Methode war der Angriff auf Mach-Dienste, die im App-Sandbox-Profil aufgeführt sind
    • Informationen zu den Mach-Diensten des Systems sind in /System/Library/xpc/launchd.plist gespeichert
    • Mit der API bootstrap_look_up lässt sich aus einer Sandbox-App heraus prüfen, ob ein bestimmter Mach-Dienst erreichbar ist
    • Solche Mach-Dienste befinden sich in der System-Domain oder User-Domain
    • Ausgangspunkt dieser Forschung war die Beobachtung, dass es auch außerhalb dieser beiden Domains XPC-Dienste gibt, die aus der App Sandbox erreichbar sind

Neue Angriffsfläche: XPC-Dienste der PID-Domain

  • Die übersehenen XPC-Dienste befinden sich in der PID-Domain
  • Anders als die bislang meist betrachteten XPC-Dienste der System-/User-Domain ist ihr Diensttyp Application
  • XPC-Dienste vom Typ Application werden auf Anfrage einer App gestartet und beendet, wenn die anfragende App beendet wird
  • XPC-Dienste der System-/User-Domain sind nur dann aus einer Sandbox-App erreichbar, wenn sie in application.sb definiert sind
  • Alle XPC-Dienste, die von Apps und Frameworks benötigt werden, sind in der PID-Domain der jeweiligen App sichtbar
  • Viele XPC-Dienste der PID-Domain rechnen nicht damit, von Sandbox-Apps aufgerufen zu werden, sodass möglicherweise keine Entitlement-Prüfung oder Sandbox-Prüfung für eingehende XPC-Clients vorhanden ist

  • Beispiel SystemShoveService.xpc

    • SystemShoveService.xpc ist ein XPC-Bundle im privaten System-Framework ShoveService.framework
    • In der Info.plist ist der Diensttyp Application, und die Bundle-ID lautet com.apple.installandsetup.shoveservice.system
    • Wenn eine Sandbox-App /System/Library/PrivateFrameworks/ShoveService.framework lädt, wird der entsprechende XPC-Dienst automatisch in der PID-Domain registriert
    • SystemShoveService.xpc prüfte den anfragenden XPC-Client nicht und konnte daher für einen Ausbruch aus der App Sandbox missbraucht werden
    • Dieser Dienst besaß das mächtige SIP-bezogene Entitlement com.apple.rootless.install, was auch zu einer Umgehung des SIP-Schutzes führen konnte
    • Die Schwachstelle erhielt die Kennung CVE-2022-26712; Details sind im früheren Beitrag beschrieben

  • Suchmethode

    • Alle XPC-Dienste mit dem Service-Typ Application sind potenzielle Ziele für einen Ausbruch aus der App Sandbox
    • Sie lassen sich durch Auflisten der XPC-Dienste in System-Frameworks und privaten Frameworks finden
      • /System/Library/Frameworks
      • /System/Library/PrivateFrameworks
    • Falls es XPC-Dienste der PID-Domain gibt, die eingehende XPC-Clients nicht prüfen, kann man folgende Angriffe versuchen
      • Einen App-Ordner ohne quarantine ablegen, um einen vollständigen Sandbox-Escape zu erreichen
      • Eine ZIP- oder DMG-Datei mit einer nicht sandboxierten App ohne quarantine ablegen

2 nur in der Beta vorhandene Schwachstellen

  • Beta-No-CVE-1: Beliebige Befehlsausführung in StorageKit

    • Apple führte diese Schwachstelle unter additional recognitions auf, vergab jedoch keine CVE
    • Laut Apple werden CVEs nur für Schwachstellen in Software vergeben, die in der Produktion veröffentlicht wurde, nicht für Schwachstellen in beta-only Software
    • Betroffen waren nur Beta-Versionen von macOS Sonoma
    • Der Pfad des verwundbaren XPC-Dienstes ist /System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc
    • Dieser Dienst konnte ohne Sandbox-Beschränkungen ausgeführt werden und erlaubte in der Delegate-Methode alle XPC-Clients
    • Die einzige Methode von SKRemoteTaskRunnerProtocol, runTask:arguments:withReply:, war dafür ausgelegt, beliebige Befehle mit einem angegebenen Pfad zur ausführbaren Datei und Argumenten auszuführen
    • Da Pfad zur ausführbaren Datei und Argumente vom XPC-Client in der Sandbox gesteuert werden konnten, war die Ausführung beliebiger Systembefehle ohne Sandbox-Beschränkungen möglich
    • Apple entfernte den verwundbaren XPC-Dienst vollständig aus dem Betriebssystem, bevor macOS Sonoma 14.0 offiziell veröffentlicht wurde

  • Beta-No-CVE-2: Missbrauch der ZIP-Erstellung in AudioAnalyticsHelperService

    • Auch für diese Schwachstelle wurde aus demselben Grund als beta-only keine CVE vergeben
    • Der Pfad des verwundbaren XPC-Dienstes ist /System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc
    • Der Dienst konnte ohne Sandbox-Beschränkungen ausgeführt werden und erlaubte alle XPC-Clients
    • Die Methode createZipAtPath:hourThreshold:withReply: komprimiert einen vom XPC-Client angegebenen beliebigen Pfad
    • Falls am angegebenen Pfad kein Ordner compressed vorhanden ist, wird er erstellt; anschließend werden .json-Dateien gesucht, in diesen Ordner verschoben und danach eine ZIP-Datei erzeugt
    • Angreifer konnten den Ordner compressed durch einen Symlink ersetzen und so beliebige Dateien an beliebige Orte verschieben
    • Der Inhalt der Quelldateien wird nicht geprüft, und der Zielpfad der Datei muss die Endung .json haben
    • Die neu erzeugte ZIP-Datei wurde nicht unter Quarantäne gestellt, da der Dienst nicht sandboxed war
    • Apple patchte dies vor der Veröffentlichung von macOS Sonoma 14.0, indem bei eingehenden XPC-Clients das Entitlement com.apple.audioanalytics.helper.service geprüft wird
    • In aktuellen macOS-Versionen wurden das private AudioAnalyticsInternal.framework und der zugehörige XPC-Dienst vollständig entfernt

CVE-2023-27944: TrialArchivingService

  • Der verwundbare Dienst ist /System/Library/PrivateFrameworks/TrialServer.framework/XPCServices/TrialArchivingService.xpc
  • Dieser Dienst läuft mit dem Profil /System/Library/Sandbox/Profiles/com.apple.trial.TrialArchivingService.sb in der Service Sandbox
  • Da es sich um eine Service Sandbox handelt, werden abgelegte Dateien nicht unter Quarantäne gestellt
  • Der Dienst erlaubt alle eingehenden XPC-Clients
  • Die Methode extractArchiveFromHandle:withArchiveName:toDirectory:destDirExtension:postExtractionCompression:completion: extrahiert eine von einer Sandbox-App übergebene Archivdatei an einen angegebenen Ort
  • Da das Quarantäne-Extended-Attribut nicht an die extrahierten Inhalte weitergegeben wurde, konnte dies zum Ablegen von Dateien ohne Quarantäne führen

  • Bedingungen für die Ausnutzung und Umgehungen

    • Bei Ausnutzung dieser Methode verlieren Mach-O-Dateien im Archiv nach der Extraktion ihre Ausführungsrechte und können daher nicht sofort ausgeführt werden
    • Eine Umgehung könnte die Nutzung von Symlinks sein, wie bei CVE-2021-30990
    • Diese XPC-Methode extrahiert jedoch nur Verzeichnisse und normale Dateien; das Extrahieren von Symlinks aus dem Archiv ist nicht erlaubt
    • Eine mögliche Umgehung besteht darin, die Payload-App in einen Pfad des App-Containers einer Sandbox-App zu extrahieren
    • Eine Sandbox-App hat dort Lese- und Schreibrechte und kann daher selbst einen Symlink erstellen oder mit chmod Ausführungsrechte vergeben
    • Eine weitere Methode ist, die Payload-App zweimal zu archivieren
      • Das äußere ZIP wird mit der verwundbaren XPC-Methode entpackt
      • Das innere ZIP wird mit dem Systembefehl open entpackt

  • Patch

    • Apple patchte dies in macOS Ventura 13.3, indem bei eingehenden XPC-Clients das Entitlement com.apple.TrialArchivingService.internal geprüft wird
    • Fehlt dieses Entitlement, wird die XPC-Verbindung abgelehnt

CVE-2023-32414: ArchiveService

  • Der verwundbare Dienst ist /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/XPCServices/ArchiveService.xpc
  • Dieser Dienst läuft in der Service Sandbox, aber abgelegte Dateien werden nicht unter Quarantäne gestellt
  • Der Dienst erlaubt alle XPC-Clients
  • Die Methode unarchiveItemWithURLWrapper:… entpackt ein von einer Sandbox-App übergebenes Element an einen angegebenen Ort
  • Da das Quarantäne-Extended-Attribut nicht an die extrahierten Inhalte weitergegeben wurde, konnte eine Sandbox-App beliebige Dateien ohne Quarantäne ablegen
  • Der XPC-Client war bereits in der Objective-C-Klasse DSArchiveService des DesktopServicesPriv.framework implementiert

  • Patch

    • Apple patchte dies in macOS Ventura 13.4, indem bei eingehenden XPC-Clients das Entitlement com.apple.private.ArchiveService.XPC geprüft wird
    • Fehlt dieses Entitlement, wird die XPC-Verbindung abgelehnt

CVE-2023-32404: ShortcutsFileAccessHelper

  • Der verwundbare Dienst ist /System/Library/PrivateFrameworks/WorkflowKit.framework/XPCServices/ShortcutsFileAccessHelper.xpc
  • Dieser Dienst konnte ohne Sandbox-Beschränkungen ausgeführt werden und ließ sich zum Ausbruch aus der App Sandbox missbrauchen
  • Die Code-Signatur enthielt außerdem ein spezielles TCC-Entitlement für Full Disk Access
  • Daher konnte diese Schwachstelle auch für eine vollständige Umgehung des TCC-Schutzes missbraucht werden
  • Der Dienst erlaubt alle XPC-Clients
  • Die einzige Methode von WFFileAccessHelperProtocol, extendAccessToURL:completion:, war dafür ausgelegt, dem XPC-Client Lese- und Schreibzugriff auf eine beliebige URL zu gewähren
    • Intern ruft sie die API sandbox_extension_issue_file auf, um ein Token für Dateizugriff auszustellen
    • Die beliebige URL wird vom XPC-Client in der Sandbox angegeben

  • Patch

    • Apple patchte dies in macOS Ventura 13.4, indem bei eingehenden XPC-Clients das Entitlement com.apple.shortcuts.file-access-helper geprüft wird
    • Fehlt dieses Entitlement, wird die XPC-Verbindung abgelehnt

CVE-2023-41077: mscamerad-xpc und wiederholte Patch-Umgehungen

  • Der betroffene Dienst ist /System/Library/Frameworks/ImageCaptureCore.framework/XPCServices/mscamerad-xpc.xpc
  • Dieser Dienst konnte ohne Sandbox-Beschränkungen ausgeführt werden und ließ sich daher zum Ausbruch aus der App Sandbox missbrauchen
  • Die Code-Signatur enthielt ein spezielles TCC-Entitlement, das ohne Nutzerabfrage Zugriff auf Photos und Removable Volumes erlaubt
  • Dadurch ließ sich auch dieser TCC-Schutz umgehen

  • Angriffsablauf

    • Der Standard-Dienstname ist com.apple.mscamerad-xpc
    • Der Dienst erlaubt alle XPC-Clients
    • ICXPCDeviceManagerProtocol mit openDevice:withReply: öffnet und konfiguriert ein neues MSCameraDevice
    • Während der Initialisierung des neuen Geräts wird ein weiterer anonymer XPC-Dienst geöffnet, um Service-Routinen für das Kameragerät bereitzustellen
    • Auch dieser anonyme XPC-Dienst erlaubt alle XPC-Clients
    • Die Methode requestReadDataFromObjectHandle:options:withReply: von ICCameraDeviceProtocol liest den Inhalt des angeforderten Dateieintrags und gibt ihn an den XPC-Client zurück
    • Der angeforderte Dateipfad kann vom XPC-Client kontrolliert werden, sodass eine Sandbox-App beliebige Dateien außerhalb ihres Containers lesen konnte
    • Wegen des mächtigen TCC-Entitlements des Dienstes konnten ohne Nutzerabfrage auch die Photos des Benutzers gelesen werden

  • Konfiguration eines gefälschten Kamerageräts

    • MSCameraDevice konnte durch Erstellen und Mounten einer DMG-Datei emuliert werden
    • Wenn Dateipfade im DMG-Volume einem bestimmten regulären Ausdruck entsprachen, wurden Dateieinträge als ICCameraFile indiziert
    • Ordnernamen-Beispiele: 123abcde, DCIM, dcIm
    • Dateinamen-Beispiele: abcd1234.mp3, 1234E5678.HEIC
    • Eine Sandbox-App konnte das Problem auslösen, indem sie eine DMG-Datei ablegte, öffnete und mountete
    • Der XPC-Client war bereits im Framework ImageCaptureCore implementiert

  • Patch und Umgehungen

    • Apple fügte in macOS Sonoma 14 eine neue Prüfung in acceptConnection: hinzu
    • Erlaubt wird, wenn der Client das private Entitlement com.apple.private.imagecapturecore.authorization_bypass besitzt
    • Oder wenn der Client ein platform binary ist
    • Die Bedingung für platform binaries ließ sich umgehen, weil sich in von Apple signierte Binärdateien dynamische Bibliotheken injizieren ließen
      • Als von Apple signierte Binärdatei ohne Entitlement wurde /bin/ls gewählt
      • Über die Umgebungsvariable DYLD_INSERT_LIBRARIES wurde eine dylib mit dem früheren Exploit-Code injiziert
      • Danach wurde wie zuvor mit dem XPC-Dienst kommuniziert
    • Apple vergab für diesen Umgehungsbericht CVE-2024-23253
    • In macOS 14.4 wurde die zweite Bedingung verschärft: Der XPC-Client musste nicht nur ein platform binary sein, sondern auch mit den Flags CS_REQUIRE_LV oder CS_FORCED_LV signiert sein
    • Auch dieser Patch ließ sich umgehen
      • In /bin/ls wurde eine dylib injiziert
      • Zur Laufzeit wurden die erforderlichen Flags manuell über die csops-API gesetzt
      • Danach bestand der Client die Prüfung des XPC-Dienstes
    • Apple vergab für diese zweite Umgehung CVE-2024-40831
    • In macOS Sequoia 15 wurde erneut gepatcht, sodass nur noch XPC-Clients mit dem privaten Entitlement com.apple.private.imagecapturecore.authorization_bypass erlaubt sind

CVE-2023-42961: intents_helper

  • Diese Schwachstelle konnte auch unter iOS ausgenutzt werden
  • Der betroffene Dienst ist /System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc
  • Der Dienst konnte ohne Sandbox-Beschränkungen ausgeführt werden und erlaubt alle XPC-Clients
  • Wegen Path Traversal in der Funktion filePathForImageWithFileName war Zugriff auf beliebige Pfade möglich
  • Der Parameter fileName ist ein beliebiger String, der vom XPC-Client kontrolliert werden kann

  • Betroffene Methoden

    • Die verwundbare Funktion war über zwei XPC-Methoden erreichbar
    • retrieveImageWithIdentifier:completion: konnte missbraucht werden, um beliebige Dateien mit der Erweiterung .png zu lesen
    • Die gelesenen Daten werden in einer Member-Variable einer INImage-Instanz gespeichert und an den XPC-Client zurückgegeben
    • purgeImageWithIdentifier:completion: konnte missbraucht werden, um beliebige Dateipfade zu löschen

  • Patch

    • Apple patchte in macOS Sonoma 14.0 die Normalisierung der vom XPC-Client gelieferten Eingabestrings
    • Für Path Traversal verwendete Sonderzeichen werden abgeschnitten

CVE-2024-27864: diskimagescontroller

  • Der CVE-Eintrag war zum Zeitpunkt der Artikelerstellung noch nicht veröffentlicht
  • Der betroffene Dienst ist /System/Library/PrivateFrameworks/DiskImages2.framework/XPCServices/diskimagescontroller.xpc
  • Dieser Dienst besaß in seiner Code-Signatur das Entitlement com.apple.diskimages.creator-uc und konnte dadurch mächtige Operationen ausführen
  • Dieses Entitlement hat zwei Hauptfunktionen
    • Es kommuniziert mit /usr/libexec/diskimagesiod, das das FDA entitlement besitzt und die eigentliche Attach-Operation ausführt
    • Es verbindet sich mit dem IOKit-Dienst AppleDiskImagesController, erstellt Geräte für DMG-Dateien und setzt Quarantine-Markierungen

  • Ursache der Schwachstelle

    • Der Dienst erlaubt alle XPC-Clients
    • Die Methode attachWithParams:reply: von DIControllerProtocol war der Angriffspunkt
    • Intern ruft sie checkAttachEntitlementWithError auf, aber diese Funktion gibt entgegen ihrem Namen immer TRUE zurück
    • In DiskImages2.framework ist mit der Objective-C-Klasse DIAttachParams bereits ein XPC-Client implementiert
    • Der Client-Code des Frameworks prüft, ob sich die Eingabe-URL im Quarantine-Zustand befindet
    • Wenn die Eingabe-URL unter Quarantine steht, setzt er vor dem Attach Quarantine-Parameter, die dem XPC-Dienst mitteilen, das Zielgerät unter Quarantine zu stellen
    • Mit einem selbstgebauten XPC-Client lässt sich das Setzen der Quarantine-Parameter überspringen und attachWithParams:reply: direkt aufrufen
    • Dadurch konnte eine unter Quarantine stehende DMG-Datei angehängt werden, ohne das entsprechende Gerät unter Quarantine zu stellen

  • Patch

    • Apple verlegte in macOS Sonoma 14.4 die Validierungslogik von der Client-Seite auf die Server-Seite
    • Wenn sich der Eingabedateipfad im Quarantine-Zustand befindet, setzt der Server das entsprechende Gerät selbst unter Quarantine

CVE-2023-42977: PerfPowerServicesSignpostReader

  • Der verwundbare Dienst ist /System/Library/PrivateFrameworks/PowerlogCore.framework/XPCServices/PerfPowerServicesSignpostReader.xpc
  • Der Dienst kann ohne Sandbox-Beschränkungen ausgeführt werden und erlaubt alle XPC-Clients
  • XPCSignpostReaderProtocol hat 6 Methoden, aber Apple implementierte nur submitSignpostDataWithConfig:withReply:; die übrigen 5 sind leere Implementierungen
  • Die Kernlogik dieser Methode besteht darin, Log-Daten zu sammeln und als gzip-Datei zu archivieren
  • Mit der vom XPC-Client kontrollierten Zeichenkette tagUUID konnte der powerlog-Pfad auf einen beliebigen Pfad umgebogen werden

  • Löschen beliebiger Pfade

    • Innerhalb der Funktion wird archiveDirectoryAt:deleteOriginal: aufgerufen, um den powerlog-Pfad zu löschen
    • Wenn man in TagUUID eine Path-Traversal-Zeichenkette einfügt, erhält man ein Primitive zum Löschen beliebiger Pfade

  • Erstellen beliebiger Verzeichnisse und vollständiger Sandbox-Escape

    • Die Funktion createSignpostFile: erstellt ein Verzeichnis im powerlog-Pfad
    • Dadurch lässt sich ein beliebiges Verzeichnis ohne quarantine-Extended-Attribut erzeugen
    • Ein Primitive zum Erstellen beliebiger Verzeichnisse ohne quarantine kann zu einem vollständigen Sandbox-Escape führen
    • Im Artikel wird die Technik aus CVE-2023-32364 verwendet
      • Einen .app-Ordner ohne quarantine erstellen
      • Unter Contents/MacOS einen Symlink auf /bin/bash erstellen
      • In LSEnvironment BASH_ENV setzen
      • Mit open ./poc.app ausführen

  • Patch

    • Apple patchte dies in macOS Sonoma 14.0, indem die UUID-Zeichenkette des XPC-Clients normalisiert wird
    • Wenn die Eingabezeichenkette keine gültige UUID ist, beendet die Funktion die Verarbeitung

Wiederkehrendes Muster

  • Die zentrale Angriffsfläche sind nicht XPC-Dienste in der System- oder User-Domain, sondern PID-Domain-XPC-Dienste in System- und Private-Frameworks
  • XPC-Dienste mit dem Service Type Application können allein durch das Laden des Frameworks in der PID-Domain einer Sandbox-App registriert werden
  • Viele verwundbare Dienste rechneten nicht mit Aufrufen durch Sandbox-Clients und ließen daher folgende Prüfungen aus
    • Prüfung der Entitlements des XPC-Clients
    • Prüfung, ob es sich um einen Sandbox-Client handelt
    • Normalisierung von Eingabepfaden
    • Serverseitige Prüfung des quarantine-Status
  • Die wiederholt ausgenutzten Bedingungen sind folgende
    • Das Ablegen von Dateien oder Ordnern ohne quarantine kann zu einem vollständigen Sandbox-Escape führen
    • Wenn beim Entpacken das quarantine-Extended-Attribut verschwindet, kann das zu einer Umgehung von Gatekeeper und zu einem Sandbox-Escape führen
    • Von einer Service Sandbox erstellte Dateien werden standardmäßig nicht mit quarantine versehen
  • Es gibt noch 5 Berichte, die auf einen Patch warten

Zusätzliche Anmerkungen zu App Sandbox und Service Sandbox

  • Apple bewertete einen Bericht als expected behavior, da eine neu gestartete Anwendung sich nicht im aktuellen Prozesskontext befinde und die Entitlements oder Berechtigungen des aktuellen Prozesses nicht teilen könne
  • In der App Sandbox werden abgelegte Dateien standardmäßig mit quarantine versehen
  • In der Service Sandbox werden abgelegte Dateien standardmäßig nicht mit quarantine versehen
  • Dass sich ein neu gestarteter Prozess nicht im aktuellen Ausführungskontext des Dienstes befindet und daher dessen Entitlements oder Privilegien nicht teilt, wird für sich genommen nicht als flaw eingeordnet
  • Umgekehrt kann es als flaw angesehen werden, wenn ein Angreifer nach Erlangen von RCE im Kontext eines sandbox-beschränkten Dienstes eine neue nicht sandboxte App ablegt und ausführt, um die Sandbox-Beschränkungen des Zieldienstes zu verlassen
    • Als Beispiel wird IMTranscoderAgent genannt, Ziel eines 0-click-Exploits der NSO Group
  • com.apple.WebDriver.HTTPService.xpc erscheint als Beispiel für einen manuellen Aufruf der API WBSEnableSandboxStyleFileQuarantine
  • Ein Escape von der App Sandbox in die Service Sandbox wird unter macOS faktisch als Schritt zu Non Sandbox eingeordnet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-09
Meinungen auf Hacker News

  • Die Reaktion, hier XPC-Dienste einzeln zu patchen, wirkt etwas seltsam.
    Es sieht eher nach einem Designproblem der Sandbox selbst aus, und ich frage mich, warum so viele XPC-Dienste, die wie app-interne Dienste wirken, für Sandbox-Apps zugänglich sind.

    • Stimmt. Da das nachträglich in macOS hineingesteckt wurde, ist es wahrscheinlich ein Kompromiss, um nichts kaputtzumachen, was aus UNIX und NeXTSTEP übernommen wurde.
      Auch auf Windows-Seite gibt es viele ähnliche Mechanismen wie die WinRT-Sandbox, Sandboxing für Win32-Apps, den Secure Kernel und Treiberschutz, aber wenn man eine einzelne ausführbare Datei über verschiedene Konfigurationen hinweg laufen lassen will, entstehen Lücken durch Abwärtskompatibilität.
      Mobile Betriebssysteme haben keine Abwärtskompatibilität und können das Ausführungsmodell stark einschränken, daher ist es dort deutlich einfacher.

  • macOS bräuchte eher so etwas wie capability-basierte Darwin-Container, statt eines Ansatzes, der wie ein riesiger Haufen Blocklisten wirkt.

  • Gute Arbeit.
    Allerdings frage ich mich, ob eine solche Architektur der richtige Weg ist. Jedes Mal, wenn man ein Sicherheits-Framework baut, um einen bestimmten Angriff zu verhindern, scheint eine völlig neue Art von Problem aufzutauchen, und am Ende fühlt es sich nicht wirklich sicherer an.
    Es ist eine Struktur wie das niederländische Steuerrecht, in der sich immer mehr Patches gegen Missbrauch auftürmen, und vielleicht hat sie bereits ein Bewusstsein entwickelt.

    • Das liegt daran, dass viele dieser Systeme nicht von Anfang bis Ende wirklich sicher entworfen wurden.
      Der richtige Ansatz scheitert am Markt meist an Abwärtskompatibilität oder daran, dass Entwickler die neuen Funktionen nicht übernehmen wollen. Die WinRT-Sandbox ist so ein Beispiel.
      Bei der Sicherheit von Smartphones war es einfacher, weil man sich nicht um Abwärtskompatibilität kümmern musste und Entwickler, die teilnehmen wollten, sich dank App-Store-Gatekeeping bislang fügen mussten.
    • Letztlich ist Sicherheit schwer mit Abwärtskompatibilität vereinbar.
      Alle heute betriebenen Betriebssysteme müssten von Grund auf neu gebaut werden, wenn sie bis ins nächste Jahrhundert sicher sein sollen, und dabei müsste viel Code weggeworfen werden. Das ist der Preis.
    • Interessant, dass du das niederländische Steuerrecht erwähnst. Bei manchen dieser „Missbrauchslücken“ wäre es wohl kaum umstritten zu sagen, dass sie absichtlich eingebaut wurden.
      Man kann vermuten, dass es starke Kräfte gibt, die auch in Consumer-Computing mehr Schwachstellen hineinbringen wollen.
      Die jeweils bekannten Beispiele sind diese:
      https://en.wikipedia.org/wiki/Dutch_Sandwich
      https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...

  • macOS, also NeXTstep, wurde von Anfang an als offenes und extrem erweiterbares Betriebssystem gebaut.
    Es gab unzählige Möglichkeiten, Erweiterungen oder Hooks von Drittanbietern hinzuzufügen, und Software konnte aus mehreren Runtimes heraus erreicht werden; damals war es schon eine beeindruckende technische Leistung, dass all das reibungslos zusammenspielte.
    Java, klassisches Mac, X11 und die NeXTstep-Codebasis liefen dank zahlreicher Erweiterungs-Einstiegspunkte im Kernel problemlos nebeneinander.
    Außerdem hatte die Plattform APIs, mit denen Apps problemlos miteinander kommunizieren konnten.
    Aber Apple hat sich nach und nach von dieser Philosophie entfernt und schließt das System immer weiter. Eine ziemlich interessante Reise.

  • SBPL (sandbox profile language) ist interessant. Details gibt es hier: https://github.com/0xbf00/simbple
    Ich frage mich, ob irgendwo in macOS ein Scheme-Interpreter steckt, der das verarbeitet.
    PS: Das scheint sandbox-exec zu machen. Siehe: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...

  • Eine beeindruckende Entdeckung. Wie der Beitrag andeutet, scheint es sehr wahrscheinlich, dass noch ähnliche Fehler in freier Wildbahn vorhanden sind.
    Wenn Apple seinen Ansatz zur Härtung solcher Dienste nicht neu entwirft, dürften weiterhin regelmäßig XPC-bezogene CVEs auftauchen.

  • Ich mag Sandboxes und hasse sie zugleich.
    Sie sind eine hervorragende zweite Verteidigungslinie, aber große Organisationen neigen dazu, die Behebung von Remote-Code-Execution-Schwachstellen abzulehnen, wenn man nicht aus der Sandbox ausbrechen und etwas Sinnvolles tun kann. Dadurch wird die Sandbox faktisch zur Hauptverteidigungslinie, und das ist traurig.

    • Ich weiß nicht, wer damit gemeint sein soll, dass man „die Behebung von Remote-Code-Execution-Schwachstellen ablehnt, wenn man nicht aus der Sandbox ausbrechen kann“.
      Soweit ich weiß, haben Apple, Microsoft und Google alle Bug-Bounty-Programme, und Sandbox-Escapes werden zwar höher belohnt, aber auch von der Sandbox blockierte Schwachstellen werden bezahlt.
      Allen ist sehr wohl bewusst, dass Angreifer Remote-Code-Execution-Schwachstellen sammeln, die aktuell nicht nutzbar sind, und sie dann zusammen mit einem später gefundenen Sandbox-Escape einsetzen.

  • Etwas am Thema vorbei, aber falls jemand unter den Sandbox-Experten eine Strategie kennt, um das Limit für die maximum "pattern serialization length" zu umgehen: Dieses Issue bereitet mir schon ziemlich lange Kopfschmerzen: https://github.com/NixOS/nix/issues/4119
    Leider ist sandbox-exec kaum dokumentiert, und es heißt auch, es solle abgeschafft werden, was die Lösung ziemlich mühsam macht.

  • Unter macOS tauchen endlos Umgehungen auf. Denn dieses Betriebssystem wurde ursprünglich nie für derart granulare Berechtigungen entworfen.
    So etwas kann man nicht einfach nachträglich auf Legacy-Mac-OS- und NeXTSTEP-Technik setzen.
    Ich bin kein Sicherheitsforscher, sondern nur ein langjähriger App-Entwickler, und trotzdem habe ich selbst mehrere Umgehungen gefunden. Man weiß eben, wo die Leichen vergraben sind.
    Aber am Ende habe ich aufgegeben, weiter danach zu suchen. Apples System zum Melden von Sicherheitslücken ist völlig kaputt, und es wirkte, als ginge es ihnen vor allem darum, einen möglichst lange zum Schweigen zu bringen. Zeitverschwendung.
    Insgesamt wirkt macOS wie ein Opfer von Security Theater: geschwächte Software und endlose Berechtigungsabfragen schaden sowohl Nutzern als auch legitimen Entwicklern, während echte Angreifer das Ganze bei Bedarf leicht umgehen können. Es erinnert an Apples alte Windows-Vista-Parodie.

    • Der Forscher, der diesen Beitrag geschrieben hat, scheint es geschafft zu haben, ziemlich viele Lücken mit Nennung seines Namens patchen zu lassen. Einige dieser CVEs scheinen allerdings schon Jahre alt zu sein.
      Dass ein Unternehmen möglichst viel Zeit haben will, um Bugs zu beheben, gehört auch zum Spiel. Wollen andere Unternehmen wirklich, dass entdeckte Schwachstellen so schnell wie möglich veröffentlicht werden? Man kann nicht kontrollieren, wie schnell Nutzer upgraden; daher ist eine verzögerte Veröffentlichung für Endnutzer immer besser und sollte Vorrang vor dem PR-Bedürfnis eines Forschers haben.
      Die Sandbox-Architektur von Apple wirkt normalerweise ziemlich gut durchdacht. In diesem Fall scheint irgendwo in der Architektur oder der Kommunikation etwas schiefgelaufen zu sein.
      Dass es Umgehungen gibt, liegt auch daran, dass wir von Desktop-Betriebssystemen zu viele Funktionen verlangen. Desktop-Betriebssysteme kann man als deutlich ausgefeiltere und komplexere Betriebssysteme betrachten als Serverplattformen. Aus demselben Grund haben Webbrowser so viele CVEs. Weil wir sowohl Sicherheit als auch Funktionen wollen, entsteht zwangsläufig ein Zwischenbereich, in dem beides kollidiert.
    • Entgegen der Aussage, man könne es „nicht einfach nachträglich auf Legacy-Mac-OS- und NeXTSTEP-Technik setzen“, kann Apple das sehr wohl, weil es den gesamten Stack kontrolliert, und hat es auch getan.
      Der schrittweise Ausbau der Sicherheit von macOS-Software und -Hardware in den letzten 20 Jahren ist der Beleg dafür.
      Für Endnutzer geschah das meist so graduell, dass sie es kaum bemerkt haben, aber macOS-Entwickler kennen die sicherheitsbezogenen Probleme nur zu gut, die sie bei großen wie kleinen Updates bewältigen müssen. Zum Beispiel:
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/09/…
    • Diese Art von Legacy-Last scheint es bei allen großen Betriebssystemen zu geben.
      Capability-basierte Systeme existieren zwar, aber keines davon wird wirklich breit genutzt.
      Was die Lösung ist, weiß ich auch nicht genau. Trotzdem wirken Versuche, Sicherheit nachzurüsten, besser, als gar nichts zu tun, sodass eine einzelne Anwendungsschwachstelle sofort zur vollständigen Übernahme des gesamten Benutzerkontos führt.
    • Wenn man es „nicht nachträglich auf Legacy-Mac-OS aufsetzen kann“: SELinux hat es geschafft — was hindert MacOS grundsätzlich daran?
    • Der Grund für solche Einschränkungen ist, es Drittentwicklern schwerer zu machen, mit Apple-Produkten zu konkurrieren.

  • Im pid-Domain übersehene XPC-Dienste sind eine clevere Methode, um macOS-Sandbox-Beschränkungen zu umgehen.
    Auch der dyld-Injection-Trick, der Berechtigungsprüfungen vermeidet, ist elegant.
    Apples Patch wirkt hier wie ein Provisorium; vielleicht muss man sich wirklich ansehen, wie Sandbox-Vererbung funktioniert.