De nombreuses nouvelles vulnérabilités de sortie de sandbox macOS

 (jhftss.github.io)
1 points par GN⁺ 2024-11-09 | 1 commentaires | Partager sur WhatsApp
  • Dans les recherches sur les sorties de sandbox macOS, les services XPC du domaine PID, relativement moins étudiés, sont apparus comme une surface d’attaque, menant à la découverte de plus de 10 nouvelles vulnérabilités
  • La cible principale n’est pas les services Mach des domaines System/User, mais les services XPC de type Application enregistrés dans le domaine PID lors du chargement d’une app ou d’un framework
  • Les cas vulnérables incluent CVE-2023-27944, CVE-2023-32414, CVE-2023-32404, CVE-2023-41077, CVE-2023-42961, CVE-2024-27864, CVE-2023-42977, entre autres ; certains sont liés à un contournement de TCC, à des privilèges liés à SIP, voire à un impact sur iOS
  • Le point d’échec récurrent tient au fait que des services non isolés traitaient fichiers, répertoires, archives et DMG sans gérer de manière sûre l’attribut étendu quarantine, les chaînes de chemins et la vérification des droits du client
  • La réponse d’Apple a consisté à supprimer des services XPC vulnérables, à normaliser les entrées, à déplacer les vérifications côté serveur et à exiger des private entitlements, mais 5 rapports sont encore en attente de correctif

Le modèle de sandbox macOS et l’objectif d’une sortie

  • Sur macOS, de nombreux processus, y compris des services Apple et des apps tierces, s’exécutent dans un environnement sandbox restreint
  • Même si un attaquant obtient une exécution de code à distance (RCE) dans un processus sandboxé, ses capacités d’exécution et ses droits d’accès aux fichiers restent limités ; l’étape suivante consiste donc à réaliser une sortie de sandbox afin d’obtenir des privilèges plus larges

  • App Sandbox

    • Conformément aux exigences du Mac App Store, de nombreuses apps s’exécutent avec les restrictions de l’App Sandbox
    • Une app sandboxée doit disposer de l’entitlement com.apple.security.app-sandbox
    • Les restrictions sont appliquées pendant la phase d’initialisation de dyld, avant la fonction main de l’app
    • Une fois dans l’App Sandbox, l’app est conteneurisée, et les opérations sur les fichiers sont limitées au chemin de son conteneur de données
    • Les fichiers créés par une app sandboxée reçoivent par défaut l’attribut étendu com.apple.quarantine
    • Le profil sandbox contient une règle empêchant la suppression de cet attribut étendu
    • Les droits détaillés de l’App Sandbox sont définis dans /System/Library/Sandbox/Profiles/application.sb
    • Le réseau, le matériel, le système de fichiers et les services Mach accessibles sont limités
    • Les processus enfants créés via fork héritent des restrictions App Sandbox du parent
    • Les processus lancés via LaunchService.framework n’héritent pas de ces restrictions ; par exemple, la commande système open peut lancer directement une app non sandboxée

  • Service Sandbox

    • De nombreux services daemon d’Apple s’exécutent dans le contexte Service Sandbox
    • Les profils de sandbox de service se trouvent principalement dans /System/Library/Sandbox/Profiles/*.sb et /usr/share/sandbox/*.sb
    • Les restrictions Service Sandbox sont appliquées manuellement depuis la fonction main du service, via un appel à l’API sandbox_init_XXX
    • Un service entré dans le Service Sandbox n’est généralement pas conteneurisé
    • Une différence importante est que les fichiers créés dans le Service Sandbox ne sont pas, par défaut, placés en quarantine
    • Si les API liées à quarantine ne sont pas appelées manuellement, les fichiers créés ne reçoivent pas l’attribut quarantine

Voies de sortie de sandbox macOS existantes

  • Attaques via LaunchService.framework

    • L’une des méthodes courantes existantes consiste à attaquer une app non sandboxée via LaunchService.framework
    • CVE-2021-30864 est un cas de manipulation de la variable d’environnement $HOME contre Terminal.app, une app système non sandboxée
    • Au lancement de Terminal, une charge malveillante sous $HOME/.profile, contrôlable par l’attaquant, est exécutée sans restrictions de sandbox
    • Un autre scénario consiste à déposer puis exécuter une nouvelle app non sandboxée
    • Toutefois, une app nouvellement déposée par une app sandboxée est placée en quarantine, ce qui bloque son exécution
    • S’il est possible de déposer un fichier ou un dossier sans quarantine, l’App Sandbox peut être entièrement contournée
    • CVE-2023-32364 est un cas où l’absence de prise en charge des attributs étendus par devfs a été exploitée pour déposer un dossier sans quarantine

  • Attaques contre des services Mach accessibles

    • La deuxième méthode courante consiste à attaquer les services Mach listés dans le profil App Sandbox
    • Les informations sur les services Mach du système sont stockées dans /System/Library/xpc/launchd.plist
    • L’API bootstrap_look_up permet de vérifier si une app sandboxée peut accéder à un service Mach donné
    • Ces services Mach existent dans le domaine System ou le domaine User
    • Le point de départ de cette recherche est le fait qu’il existe d’autres services XPC accessibles depuis l’App Sandbox en dehors de ces deux domaines

Nouvelle surface d’attaque : les services XPC du domaine PID

  • Les services XPC négligés existent dans le domaine PID
  • Contrairement aux services XPC des domaines System/User principalement étudiés jusqu’ici, leur type de service est Application
  • Les services XPC de type Application sont lancés à la demande d’une app, puis se terminent avec l’app qui les a demandés
  • Les services XPC des domaines System/User ne sont accessibles depuis une app sandboxée que s’ils sont définis dans application.sb
  • Tous les services XPC nécessaires à une app et à ses frameworks apparaissent dans le domaine PID de cette app
  • Beaucoup de services XPC du domaine PID ne s’attendent pas à être appelés depuis une app sandboxée ; ils peuvent donc ne pas effectuer de contrôle d’entitlement ni de contrôle de sandbox sur les clients XPC entrants

  • Exemple de SystemShoveService.xpc

    • SystemShoveService.xpc est un bundle XPC dans le framework private système ShoveService.framework
    • Dans Info.plist, son type de service est Application et son identifiant de bundle est com.apple.installandsetup.shoveservice.system
    • Lorsqu’une app sandboxée charge /System/Library/PrivateFrameworks/ShoveService.framework, le service XPC correspondant est automatiquement enregistré dans le domaine PID
    • SystemShoveService.xpc ne vérifiait pas le client XPC demandeur, ce qui permettait de l’exploiter pour sortir de l’App Sandbox
    • Ce service disposait d’un entitlement lié à SIP puissant, com.apple.rootless.install, ce qui pouvait aussi permettre un contournement de la protection SIP
    • Cette vulnérabilité a été attribuée à CVE-2022-26712, et les détails sont présentés dans cet article précédent

  • Méthode d’exploration

    • Tous les services XPC dont le Service Type est Application sont des cibles potentielles pour une sortie de l’App Sandbox
    • On peut les trouver en énumérant les services XPC dans les frameworks système et les frameworks private
      • /System/Library/Frameworks
      • /System/Library/PrivateFrameworks
    • S’il existe un service XPC du domaine PID qui ne vérifie pas les clients XPC entrants, on peut tenter une attaque de la manière suivante
      • déposer un dossier d’app sans quarantine pour obtenir une sortie complète de sandbox
      • déposer sans quarantine un fichier ZIP ou DMG contenant une app non sandboxée

Deux vulnérabilités propres aux versions bêta

  • Beta-No-CVE-1 : exécution de commandes arbitraires dans StorageKit

    • Apple a mentionné cette vulnérabilité dans les additional recognitions, mais ne lui a pas attribué de CVE
    • Selon Apple, les CVE ne sont attribuées qu’aux vulnérabilités de logiciels publiés en production, et non aux vulnérabilités de logiciels uniquement en bêta
    • Seules les versions bêta de macOS Sonoma étaient concernées
    • Le chemin du service XPC vulnérable était /System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc
    • Ce service pouvait s’exécuter sans restrictions de sandbox et acceptait tous les clients XPC dans sa méthode delegate
    • L’unique méthode runTask:arguments:withReply: de SKRemoteTaskRunnerProtocol était conçue pour exécuter une commande arbitraire avec le chemin d’exécutable et les arguments indiqués
    • Comme le chemin de l’exécutable et les arguments pouvaient être contrôlés par un client XPC sandboxé, il était possible d’exécuter des commandes système arbitraires sans restrictions de sandbox
    • Apple a entièrement supprimé le service XPC vulnérable du système d’exploitation avant la sortie stable de macOS Sonoma 14.0

  • Beta-No-CVE-2 : exploitation de la création de ZIP dans AudioAnalyticsHelperService

    • Cette vulnérabilité n’a pas non plus reçu de CVE, pour la même raison liée au caractère beta-only
    • Le chemin du service XPC vulnérable était /System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc
    • Le service pouvait s’exécuter sans restrictions de sandbox et acceptait tous les clients XPC
    • La méthode createZipAtPath:hourThreshold:withReply: compressait un chemin arbitraire indiqué par le client XPC
    • Si le dossier compressed n’existait pas à l’emplacement indiqué, elle le créait, recherchait les fichiers .json, les déplaçait dans ce dossier, puis créait un fichier ZIP
    • Un attaquant pouvait remplacer le dossier compressed par un symlink afin de déplacer un fichier arbitraire vers un emplacement arbitraire
    • Le contenu du fichier source n’était pas vérifié, et le chemin du fichier cible devait avoir le suffixe .json
    • Le nouveau fichier ZIP créé n’était pas placé en quarantaine, car le service n’était pas sandboxé
    • Avant la sortie de macOS Sonoma 14.0, Apple a corrigé le problème en vérifiant l’entitlement com.apple.audioanalytics.helper.service des clients XPC entrants
    • Dans les versions récentes de macOS, le framework privé AudioAnalyticsInternal.framework et le service XPC correspondant ont été entièrement supprimés

CVE-2023-27944 : TrialArchivingService

  • Le service vulnérable est /System/Library/PrivateFrameworks/TrialServer.framework/XPCServices/TrialArchivingService.xpc
  • Ce service entre dans une Service Sandbox avec le profil /System/Library/Sandbox/Profiles/com.apple.trial.TrialArchivingService.sb
  • Comme il s’agit d’une Service Sandbox, les fichiers déposés ne sont pas placés en quarantaine
  • Le service accepte tous les clients XPC entrants
  • La méthode extractArchiveFromHandle:withArchiveName:toDirectory:destDirExtension:postExtractionCompression:completion: extrait à l’emplacement indiqué un fichier d’archive transmis par une application sandboxée
  • L’attribut étendu de quarantaine n’était pas transmis au contenu extrait, ce qui pouvait conduire au dépôt de fichiers sans quarantaine

  • Conditions d’exploitation et contournements

    • En exploitant cette méthode, les fichiers Mach-O présents dans l’archive perdaient leur permission d’exécution après extraction et ne pouvaient donc pas être exécutés directement
    • Une approche utilisant des symlinks, comme la technique de CVE-2021-30990, pouvait servir de contournement
    • Toutefois, cette méthode XPC n’extrait que des répertoires et des fichiers ordinaires, et n’autorise pas l’extraction de symlinks depuis une archive
    • Une méthode de contournement consiste à extraire l’app contenant la charge utile dans le chemin du conteneur d’app sandboxé
    • L’application sandboxée disposant de droits de lecture et d’écriture sur ce chemin, elle peut créer directement un symlink ou accorder la permission d’exécution avec chmod
    • Une autre méthode consiste à archiver deux fois l’app contenant la charge utile
      • Décompresser le ZIP externe avec la méthode XPC vulnérable
      • Décompresser le ZIP interne avec la commande système open

  • Correctif

    • Dans macOS Ventura 13.3, Apple a corrigé le problème en vérifiant l’entitlement com.apple.TrialArchivingService.internal des clients XPC entrants
    • Sans cet entitlement, la connexion XPC est refusée

CVE-2023-32414 : ArchiveService

  • Le service vulnérable est /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/XPCServices/ArchiveService.xpc
  • Ce service entre dans une Service Sandbox, mais les fichiers déposés ne sont pas placés en quarantaine
  • Le service accepte tous les clients XPC
  • La méthode unarchiveItemWithURLWrapper:… décompresse à l’emplacement indiqué un élément transmis par une application sandboxée
  • Comme l’attribut étendu de quarantaine n’était pas transmis au contenu extrait, une application sandboxée pouvait déposer des fichiers arbitraires sans quarantaine
  • Le client XPC était déjà implémenté dans la classe Objective-C DSArchiveService de DesktopServicesPriv.framework

  • Correctif

    • Dans macOS Ventura 13.4, Apple a corrigé le problème en vérifiant l’entitlement com.apple.private.ArchiveService.XPC des clients XPC entrants
    • Sans cet entitlement, la connexion XPC est refusée

CVE-2023-32404 : ShortcutsFileAccessHelper

  • Le service vulnérable est /System/Library/PrivateFrameworks/WorkflowKit.framework/XPCServices/ShortcutsFileAccessHelper.xpc
  • Ce service pouvait s’exécuter sans restrictions de sandbox, ce qui permettait de l’exploiter pour sortir de l’App Sandbox
  • Sa signature de code incluait aussi un entitlement TCC spécial pour le Full Disk Access
  • Cette vulnérabilité pouvait donc également être exploitée pour contourner complètement les protections TCC
  • Le service acceptait tous les clients XPC
  • L’unique méthode extendAccessToURL:completion: de WFFileAccessHelperProtocol était conçue pour accorder au client XPC des droits de lecture et d’écriture sur une URL arbitraire
    • En interne, elle appelait l’API sandbox_extension_issue_file pour émettre un jeton d’accès au fichier
    • L’URL arbitraire était indiquée par le client XPC sandboxé

  • Correctif

    • Dans macOS Ventura 13.4, Apple a corrigé le problème en vérifiant l’entitlement com.apple.shortcuts.file-access-helper des clients XPC entrants
    • Sans cet entitlement, la connexion XPC est refusée

CVE-2023-41077 : mscamerad-xpc et contournements répétés de correctifs

  • Le service vulnérable est /System/Library/Frameworks/ImageCaptureCore.framework/XPCServices/mscamerad-xpc.xpc
  • Ce service pouvait s’exécuter sans restrictions de sandbox, ce qui permettait de l’exploiter pour sortir de l’App Sandbox
  • Sa signature de code disposait d’entitlements TCC spéciaux permettant d’accéder à Photos et aux Volumes amovibles sans invite utilisateur
  • Il était donc également possible de contourner ces protections TCC

  • Flux vulnérable

    • Le nom de service par défaut est com.apple.mscamerad-xpc
    • Le service accepte tous les clients XPC
    • openDevice:withReply: de ICXPCDeviceManagerProtocol ouvre et configure un nouveau MSCameraDevice
    • Lors de l’initialisation du nouvel appareil, un autre service XPC anonyme est ouvert afin de fournir une routine de service pour l’appareil photo
    • Ce service XPC anonyme accepte lui aussi tous les clients XPC
    • La méthode requestReadDataFromObjectHandle:options:withReply: de ICCameraDeviceProtocol lit le contenu de l’élément de fichier demandé et le renvoie au client XPC
    • Le chemin du fichier demandé pouvant être contrôlé par le client XPC, une application sandboxée pouvait lire des fichiers arbitraires en dehors de son conteneur
    • En raison des puissants entitlements TCC du service, elle pouvait aussi lire les Photos de l’utilisateur sans invite

  • Configuration d’un faux appareil photo

    • MSCameraDevice pouvait être émulé en créant et en montant un fichier DMG
    • Si le chemin d’un fichier dans le volume DMG correspondait à une expression régulière donnée, l’élément de fichier était indexé comme ICCameraFile
    • Exemple de noms de dossier : 123abcde, DCIM, dcIm
    • Exemple de noms de fichier : abcd1234.mp3, 1234E5678.HEIC
    • Une application sandboxée pouvait déclencher le problème en déposant le fichier DMG puis en l’ouvrant pour le monter
    • Le client XPC était déjà implémenté dans le framework ImageCaptureCore

  • Correctifs et contournements

    • Apple a ajouté un nouveau contrôle dans acceptConnection: avec macOS Sonoma 14
    • Le client est autorisé s’il possède l’entitlement privé com.apple.private.imagecapturecore.authorization_bypass
    • Ou bien si le client est un platform binary
    • La condition de platform binary pouvait être contournée en injectant une bibliothèque dynamique dans un binaire signé par Apple
      • Choix de /bin/ls, un binaire signé par Apple sans entitlement
      • Injection, via la variable d’environnement DYLD_INSERT_LIBRARIES, d’une dylib contenant l’ancien code d’exploit
      • Communication ensuite avec le service XPC comme auparavant
    • Apple a attribué CVE-2024-23253 à ce rapport de contournement
    • Dans macOS 14.4, la deuxième condition a été renforcée : le client XPC devait non seulement être un platform binary, mais aussi être signé avec les flags CS_REQUIRE_LV ou CS_FORCED_LV
    • Ce correctif pouvait lui aussi être contourné
      • Injection d’une dylib dans /bin/ls
      • Définition manuelle des flags requis à l’exécution avec l’API csops
      • Passage ensuite du contrôle du service XPC
    • Apple a attribué CVE-2024-40831 à ce deuxième contournement
    • Dans macOS Sequoia 15, un nouveau correctif n’autorise plus que les clients XPC possédant l’entitlement privé com.apple.private.imagecapturecore.authorization_bypass

CVE-2023-42961 : intents_helper

  • Cette vulnérabilité est également exploitable sur iOS
  • Le service vulnérable est /System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc
  • Le service peut s’exécuter sans restrictions de sandbox et accepte tous les clients XPC
  • Une traversée de chemin (path traversal) dans la fonction filePathForImageWithFileName permettait d’accéder à des chemins arbitraires
  • Le paramètre fileName est une chaîne arbitraire contrôlable par le client XPC

  • Méthodes affectées

    • La fonction vulnérable était accessible depuis deux méthodes XPC
    • retrieveImageWithIdentifier:completion: pouvait être exploitée pour lire des fichiers arbitraires avec l’extension .png
    • Les données lues étaient stockées dans une variable membre d’une instance INImage puis renvoyées au client XPC
    • purgeImageWithIdentifier:completion: pouvait être exploitée pour supprimer des fichiers à des chemins arbitraires

  • Correctif

    • Dans macOS Sonoma 14.0, Apple a corrigé le problème en normalisant la chaîne d’entrée fournie par le client XPC
    • Les caractères spéciaux utilisés pour la traversée de chemin sont supprimés

CVE-2024-27864 : diskimagescontroller

  • L’entrée CVE était en attente de publication au moment de la rédaction de l’article
  • Le service vulnérable est /System/Library/PrivateFrameworks/DiskImages2.framework/XPCServices/diskimagescontroller.xpc
  • Ce service dispose, dans sa signature de code, de l’entitlement com.apple.diskimages.creator-uc, qui lui permet d’effectuer des opérations puissantes
  • Cet entitlement a deux fonctions principales
    • Communiquer avec /usr/libexec/diskimagesiod, qui possède un entitlement FDA et effectue réellement l’opération d’attach
    • Se connecter au service IOKit AppleDiskImagesController pour créer des appareils destinés aux fichiers DMG et gérer la mise en quarantaine

  • Cause de la vulnérabilité

    • Le service accepte tous les clients XPC
    • La méthode attachWithParams:reply: de DIControllerProtocol constituait le point d’attaque
    • En interne, elle appelle checkAttachEntitlementWithError, mais, contrairement à ce que son nom suggère, cette fonction renvoie toujours TRUE
    • Dans DiskImages2.framework, un client XPC est déjà implémenté avec la classe Objective-C DIAttachParams
    • Le code client du framework vérifie si l’URL d’entrée est en quarantaine
    • Si l’URL d’entrée est en quarantaine, il définit un paramètre de quarantaine avant l’attach, et ce paramètre indique au service XPC de mettre en quarantaine l’appareil cible
    • En créant son propre client XPC, il était possible de sauter la définition du paramètre de quarantaine et d’appeler directement attachWithParams:reply:
    • Résultat : il était possible d’attacher un fichier DMG en quarantaine sans mettre en quarantaine l’appareil correspondant

  • Correctif

    • Dans macOS Sonoma 14.4, Apple a déplacé la logique de validation du côté client vers le côté serveur
    • Si le chemin du fichier d’entrée est en quarantaine, le serveur met directement en quarantaine l’appareil correspondant

CVE-2023-42977 : PerfPowerServicesSignpostReader

  • Le service vulnérable est /System/Library/PrivateFrameworks/PowerlogCore.framework/XPCServices/PerfPowerServicesSignpostReader.xpc
  • Le service peut s’exécuter sans restrictions de sandbox et accepte tous les clients XPC
  • XPCSignpostReaderProtocol comporte 6 méthodes, mais Apple n’en a implémenté qu’une seule, submitSignpostDataWithConfig:withReply:, les 5 autres étant des implémentations vides
  • La logique principale de cette méthode consiste à collecter des données de logs et à les archiver dans un fichier gzip
  • Il était possible de détourner le chemin powerlog vers un chemin arbitraire via la chaîne tagUUID contrôlée par le client XPC

  • Suppression de chemin arbitraire

    • Dans la fonction, archiveDirectoryAt:deleteOriginal: est appelé pour supprimer le chemin powerlog
    • En plaçant une chaîne de traversée de chemin dans TagUUID, on peut obtenir une primitive de suppression de chemin arbitraire

  • Création de répertoire arbitraire et sortie complète de sandbox

    • La fonction createSignpostFile: crée un répertoire dans le chemin powerlog
    • Cela permet de créer un répertoire arbitraire sans attribut étendu de quarantaine
    • Une primitive de création de répertoire arbitraire sans quarantaine peut conduire à une sortie complète de sandbox
    • L’article utilise la technique de CVE-2023-32364
      • Créer un dossier .app sans quarantaine
      • Créer un symlink vers /bin/bash sous Contents/MacOS
      • Définir BASH_ENV dans LSEnvironment
      • L’exécuter avec open ./poc.app

  • Correctif

    • Apple a corrigé le problème dans macOS Sonoma 14.0 en normalisant la chaîne UUID des clients XPC
    • Si la chaîne d’entrée n’est pas un UUID valide, la fonction se termine

Motifs récurrents

  • La surface d’attaque principale ne concerne pas les services XPC des domaines System ou User, mais les services XPC du domaine PID présents dans les frameworks système et privés
  • Les services XPC dont le Service Type est Application peuvent être enregistrés dans le domaine PID d’une app sandboxée simplement en chargeant le framework
  • Beaucoup de services vulnérables ne s’attendaient pas à être appelés par des clients sandboxés et omettaient donc les contrôles suivants
    • Vérification des entitlements du client XPC
    • Vérification du fait que le client soit sandboxé ou non
    • Normalisation des chemins d’entrée
    • Validation côté serveur de l’état de quarantaine
  • Les conditions exploitées de manière répétée sont les suivantes
    • Le dépôt de fichiers ou dossiers sans quarantaine peut mener à une sortie complète de sandbox
    • Si l’attribut étendu de quarantaine disparaît lors de la décompression, cela peut conduire à un contournement de Gatekeeper et à une sortie de sandbox
    • Les fichiers créés par la Service Sandbox ne sont, par défaut, pas mis en quarantaine
  • Il reste encore 5 rapports en attente de correctif

Commentaires supplémentaires sur App Sandbox et Service Sandbox

  • Pour l’un des rapports, Apple a estimé qu’il s’agissait du comportement attendu, car l’application nouvellement lancée n’est pas dans le contexte du processus actuel et ne peut pas partager les entitlements ni les permissions de ce processus
  • Dans App Sandbox, les fichiers déposés sont mis en quarantaine par défaut
  • Dans Service Sandbox, les fichiers déposés ne sont pas mis en quarantaine par défaut
  • Le fait qu’un processus nouvellement lancé ne soit pas dans le contexte d’exécution du service actuel et ne partage donc pas les entitlements ni les privilèges de ce service n’est pas considéré en soi comme une faille
  • À l’inverse, le fait qu’un attaquant puisse obtenir une RCE dans le contexte d’un service soumis à des restrictions de sandbox, puis déposer et lancer une nouvelle app non sandboxée pour sortir des restrictions de sandbox du service cible peut être considéré comme une faille
    • IMTranscoderAgent, qui avait été la cible d’un exploit 0-click de NSO Group, est cité comme exemple
  • com.apple.WebDriver.HTTPService.xpc est cité comme exemple d’appel manuel de l’API WBSEnableSandboxStyleFileQuarantine
  • Sortir de l’App Sandbox vers la Service Sandbox revient, en pratique sur macOS, à passer en Non Sandbox

À lire aussi

1 commentaires

 
GN⁺ 2024-11-09
Avis de Hacker News

  • La réponse consistant à corriger un par un les services XPC ici paraît un peu étrange.
    Cela ressemble à un problème de conception du sandbox lui-même, et on peut se demander pourquoi autant de services XPC qui semblent destinés à un usage interne aux apps sont accessibles depuis des apps sandboxées.

    • Oui. Il est très probable que, comme cela a été ajouté après coup à macOS, ce soit un compromis pour éviter de casser ce qui venait d’UNIX et de NeXTSTEP.
      Côté Windows aussi, il existe beaucoup de mécanismes similaires — sandbox WinRT, sandbox pour apps Win32, noyau sécurisé, protection des pilotes, etc. — mais dès qu’il faut faire tourner un même exécutable dans plusieurs configurations, des brèches liées à la rétrocompatibilité apparaissent.
      Les systèmes d’exploitation mobiles sont beaucoup plus simples à cet égard, car ils n’ont pas de rétrocompatibilité à gérer et peuvent fortement contraindre le modèle d’exécution.

  • macOS aurait besoin de quelque chose comme des conteneurs Darwin fondés sur les capabilities, plutôt que cette approche qui ressemble à un énorme amas de listes de blocage.

    • https://github.com/darwin-containers
      https://news.ycombinator.com/item?id=37655477
      Il n’existe pas de modèle de sécurité qui fonctionne vraiment bien sur le desktop.
      Comme le dit un autre commentaire, iOS a pu proposer un modèle de sécurité cohérent parce qu’il n’avait pas tout ce vieux passif.
      En revanche, quand Telegram demande l’accès à tous les contacts et à toutes les photos, les gens l’autorisent réellement.

  • Beau travail.
    Cela dit, je me demande si ce type d’architecture va dans la bonne direction. À chaque fois qu’on crée un framework de sécurité pour bloquer un type d’attaque, on dirait qu’une catégorie entièrement nouvelle de problèmes apparaît, et je n’ai pas l’impression qu’au final on soit vraiment plus en sécurité.
    C’est une structure comme le droit fiscal néerlandais, où les correctifs destinés à empêcher les abus s’empilent sans fin ; elle a peut-être déjà acquis une forme de conscience.

    • C’est parce que beaucoup de ces systèmes n’ont pas été conçus correctement pour être sûrs de bout en bout dès le départ.
      Les approches correctes échouent généralement sur le marché à cause de la rétrocompatibilité ou du refus des développeurs d’adopter certaines fonctionnalités. Le sandbox WinRT en est un exemple.
      La sécurité des téléphones était plus facile, car il n’y avait pas à se soucier de la rétrocompatibilité et, jusqu’ici, le contrôle exercé par les app stores a obligé les développeurs voulant participer à s’y conformer.
    • En fin de compte, la sécurité est difficilement compatible avec la rétrocompatibilité.
      Tous les systèmes d’exploitation actuellement en service devraient être reconstruits à partir de zéro pour rester sûrs jusqu’au siècle prochain, et il faudrait jeter beaucoup de code dans le processus. C’est le prix à payer.
    • C’est amusant de mentionner le droit fiscal néerlandais. Dire que certaines de ces « failles d’abus » ont été introduites intentionnellement ne serait sans doute pas très controversé.
      On peut supposer qu’il existe aussi des forces puissantes cherchant à injecter davantage de vulnérabilités dans l’informatique grand public.
      Voici deux exemples connus, respectivement :
      https://en.wikipedia.org/wiki/Dutch_Sandwich
      https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...

  • macOS, c’est-à-dire NeXTstep, a été conçu dès le départ comme un système d’exploitation ouvert et extrêmement extensible.
    Il existait d’innombrables façons d’ajouter des extensions ou des hooks tiers, et les logiciels pouvaient être accessibles depuis plusieurs runtimes ; à l’époque, le simple fait que tout cela fonctionne ensemble de manière fluide était une prouesse technique impressionnante.
    Java, le Mac classique, X11 et la base de code NeXTstep tournaient ensemble sans problème grâce aux multiples points d’entrée d’extension du noyau.
    En plus, la plateforme disposait aussi d’API permettant aux apps de communiquer entre elles sans difficulté.
    Mais Apple s’est peu à peu éloignée de cette philosophie et continue de fermer le système. C’est un parcours assez intéressant.

  • SBPL (sandbox profile language) est intéressant. On trouve plus de détails ici : https://github.com/0xbf00/simbple
    Je me demande s’il existe quelque part dans macOS un interpréteur Scheme qui traite ça.
    P.-S. : il me semble que c’est sandbox-exec qui fait ce travail. Référence : https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...

  • Découverte impressionnante. Comme l’article le suggère, il semble très probable que des failles similaires soient encore présentes dans la nature.
    Si Apple ne repense pas son approche de durcissement de ces services, on risque de continuer à voir apparaître régulièrement des CVE liées à XPC.

  • J’aime les sandboxes tout en les détestant.
    C’est une excellente deuxième ligne de défense, mais les grandes organisations ont tendance à refuser de corriger les vulnérabilités d’exécution de code à distance si elles ne permettent pas de sortir du sandbox et de faire quelque chose de significatif. On finit donc par utiliser le sandbox comme ligne de défense principale, et c’est triste.

    • Je ne sais pas de qui il s’agit quand on dit qu’« ils refusent de corriger les vulnérabilités d’exécution de code à distance si elles ne permettent pas de sortir du sandbox ».
      À ma connaissance, Apple, Microsoft et Google ont tous des programmes de bug bounty, et même s’ils paient davantage pour une sortie de sandbox, ils récompensent aussi les vulnérabilités bloquées par le sandbox.
      Tout le monde sait très bien que les attaquants mettent de côté des vulnérabilités d’exécution de code à distance inutilisables pour l’instant, puis les combinent avec une sortie de sandbox lorsqu’elle est découverte.

  • C’est un peu hors sujet, mais si parmi les spécialistes du sandbox quelqu’un connaît une stratégie pour contourner la limite maximum "pattern serialization length", ce problème me donne des maux de tête depuis un bon moment : https://github.com/NixOS/nix/issues/4119
    Malheureusement, sandbox-exec est très peu documenté, et comme on dit aussi qu’il est voué à disparaître, c’est assez pénible à résoudre.

  • Sur macOS, les contournements n’en finissent jamais. C’est parce que ce système d’exploitation n’a jamais été conçu au départ pour ce genre de permissions granulaires.
    On ne peut pas simplement greffer ça après coup sur des technologies héritées de Mac OS classique et de NeXTSTEP.
    Je ne suis même pas chercheur en sécurité, juste un vieux développeur d’apps, et j’ai pourtant trouvé moi-même plusieurs contournements. Disons que je sais où sont enterrés les cadavres.
    Mais j’ai fini par arrêter de chercher. Le système de signalement des failles de sécurité d’Apple est un désastre complet, et ils semblaient surtout vouloir vous faire taire le plus longtemps possible. Une perte de temps.
    Dans l’ensemble, macOS donne l’impression d’être victime de théâtre de la sécurité : des logiciels affaiblis et des demandes d’autorisations sans fin pénalisent à la fois les utilisateurs et les développeurs légitimes, tandis que les vrais attaquants peuvent contourner tout ça facilement quand ils le veulent. Ça rappelle les anciennes parodies de Windows Vista par Apple.

    • Le chercheur qui a écrit cet article semble avoir réussi à faire corriger pas mal de failles, avec attribution. Cela dit, certaines de ces CVE semblent dater de plusieurs années.
      Le fait qu’une entreprise veuille disposer d’un maximum de temps pour corriger les bugs fait aussi partie du jeu. Voulons-nous vraiment que les autres entreprises divulguent les vulnérabilités découvertes aussi vite que possible ? Comme on ne contrôle pas la rapidité avec laquelle les utilisateurs feront la mise à niveau, retarder la divulgation est toujours préférable pour l’utilisateur final, et cela devrait passer avant le besoin de visibilité du chercheur.
      L’architecture du sandbox d’Apple semble généralement assez bien conçue. Dans ce cas précis, il semble y avoir eu un problème quelque part dans l’architecture ou la communication.
      L’existence de contournements tient aussi au fait qu’on exige trop de fonctionnalités d’un système d’exploitation de bureau. On peut considérer qu’un OS de bureau est bien plus sophistiqué et complexe qu’une plateforme serveur. C’est pour la même raison que les navigateurs web ont beaucoup de CVE. On veut à la fois la sécurité et les fonctionnalités, donc il existe inévitablement une zone de friction entre les deux.
    • Contrairement à l’idée selon laquelle « on ne peut pas simplement greffer ça après coup sur des technologies héritées de Mac OS classique et de NeXTSTEP », Apple possède toute la stack, donc elle peut le faire, et elle l’a effectivement fait.
      Le renforcement progressif des logiciels et du matériel macOS au cours des 20 dernières années en est la preuve.
      Cela a été assez progressif pour que la plupart des utilisateurs finaux ne s’en rendent pas compte, mais les développeurs macOS sont douloureusement conscients des problèmes liés à la sécurité qu’ils doivent gérer, aussi bien dans les mises à jour majeures que mineures. Par exemple :
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/09/…
    • Ce genre de poids de l’héritage semble exister dans tous les systèmes d’exploitation grand public.
      Il existe des systèmes fondés sur les capabilities, mais aucun n’est vraiment largement utilisé.
      Je ne sais pas très bien quelle est la solution. Malgré tout, les tentatives d’ajouter de la sécurité semblent préférables à ne rien faire et à laisser une seule vulnérabilité applicative se transformer immédiatement en prise de contrôle complète du compte utilisateur.
    • Si « on ne peut pas l’ajouter après coup sur Mac OS classique », SELinux y est bien parvenu ; qu’est-ce qui bloque fondamentalement MacOS ?
    • La raison de ces restrictions est de rendre plus difficile pour les développeurs tiers de concurrencer les produits Apple.

  • Les services XPC oubliés dans le domaine pid sont une manière astucieuse de contourner les restrictions du sandbox de macOS.
    L’astuce d’injection dyld qui évite les vérifications de permissions est élégante aussi.
    Le correctif d’Apple donne ici l’impression d’être un bricolage temporaire, et il faudra peut-être revoir sérieusement la façon dont fonctionne l’héritage du sandbox.