macOS IPC - Inter Process Communication
Messagerie Mach via les ports
Informations de base
Mach utilise des tâches comme unité la plus petite pour le partage de ressources, et chaque tâche peut contenir plusieurs threads. Ces tâches et threads sont mappés 1:1 sur les processus et threads POSIX.
La communication entre les tâches se fait via la Communication Inter-Processus (IPC) de Mach, en utilisant des canaux de communication unidirectionnels. Les messages sont transférés entre les ports, qui agissent comme des files d'attente de messages gérées par le noyau.
Chaque processus a une table IPC, où il est possible de trouver les ports Mach du processus. Le nom d'un port Mach est en réalité un nombre (un pointeur vers l'objet du noyau).
Un processus peut également envoyer un nom de port avec certains droits à une tâche différente et le noyau fera apparaître cette entrée dans la table IPC de l'autre tâche.
Droits de port
Les droits de port, qui définissent les opérations qu'une tâche peut effectuer, sont essentiels pour cette communication. Les droits de port possibles sont (définitions d'ici) :
Le droit de réception, qui permet de recevoir des messages envoyés au port. Les ports Mach sont des files d'attente MPSC (multiproducteur, monoclient), ce qui signifie qu'il ne peut y avoir qu'un seul droit de réception pour chaque port dans tout le système (contrairement aux tubes, où plusieurs processus peuvent tous détenir des descripteurs de fichier pour l'extrémité de lecture d'un tube).
Une tâche avec le droit de réception peut recevoir des messages et créer des droits d'envoi, lui permettant d'envoyer des messages. À l'origine, seule la tâche elle-même a le droit de réception sur son port.
Le droit d'envoi, qui permet d'envoyer des messages au port.
Le droit d'envoi peut être cloné afin qu'une tâche possédant un droit d'envoi puisse cloner le droit et le donner à une troisième tâche.
Le droit d'envoi unique, qui permet d'envoyer un message au port puis disparaît.
Le droit de jeu de ports, qui indique un jeu de ports plutôt qu'un seul port. Défiler un message d'un jeu de ports défile un message d'un des ports qu'il contient. Les jeux de ports peuvent être utilisés pour écouter plusieurs ports simultanément, un peu comme
select
/poll
/epoll
/kqueue
dans Unix.Nom mort, qui n'est pas un droit de port réel, mais simplement un espace réservé. Lorsqu'un port est détruit, tous les droits de port existants sur le port deviennent des noms morts.
Les tâches peuvent transférer des droits d'ENVOI à d'autres, leur permettant d'envoyer des messages en retour. Les droits d'ENVOI peuvent également être clonés, de sorte qu'une tâche puisse dupliquer et donner le droit à une troisième tâche. Cela, combiné à un processus intermédiaire appelé le serveur d'amorçage, permet une communication efficace entre les tâches.
Ports de fichiers
Les ports de fichiers permettent d'encapsuler des descripteurs de fichiers dans des ports Mac (en utilisant des droits de port Mach). Il est possible de créer un fileport
à partir d'un FD donné en utilisant fileport_makeport
et de créer un FD à partir d'un fileport en utilisant fileport_makefd
.
Établir une communication
Étapes :
Comme mentionné, pour établir le canal de communication, le serveur d'amorçage (launchd sur Mac) est impliqué.
La tâche A initie un nouveau port, obtenant un droit de RÉCEPTION dans le processus.
La tâche A, étant le détenteur du droit de RÉCEPTION, génère un droit d'ENVOI pour le port.
La tâche A établit une connexion avec le serveur d'amorçage, fournissant le nom de service du port et le droit d'ENVOI via une procédure connue sous le nom d'enregistrement d'amorçage.
La tâche B interagit avec le serveur d'amorçage pour exécuter une recherche d'amorçage pour le nom du service. En cas de succès, le serveur duplique le droit d'ENVOI reçu de la tâche A et le transmet à la tâche B.
Après avoir acquis un droit d'ENVOI, la tâche B est capable de formuler un message et de l'envoyer à la tâche A.
Pour une communication bidirectionnelle, généralement la tâche B génère un nouveau port avec un droit de RÉCEPTION et un droit d'ENVOI, et donne le droit d'ENVOI à la tâche A pour qu'elle puisse envoyer des messages à la TÂCHE B (communication bidirectionnelle).
Le serveur d'amorçage ne peut pas authentifier le nom de service revendiqué par une tâche. Cela signifie qu'une tâche pourrait potentiellement usurper n'importe quelle tâche système, en revendiquant faussement un nom de service d'autorisation, puis en approuvant chaque demande.
Ensuite, Apple stocke les noms des services fournis par le système dans des fichiers de configuration sécurisés, situés dans des répertoires protégés par SIP : /System/Library/LaunchDaemons
et /System/Library/LaunchAgents
. Aux côtés de chaque nom de service, le binaire associé est également stocké. Le serveur d'amorçage, créera et détiendra un droit de RÉCEPTION pour chacun de ces noms de service.
Pour ces services prédéfinis, le processus de recherche diffère légèrement. Lorsqu'un nom de service est recherché, launchd démarre le service de manière dynamique. Le nouveau flux de travail est le suivant :
La tâche B initie une recherche d'amorçage pour un nom de service.
launchd vérifie si la tâche est en cours d'exécution et si ce n'est pas le cas, la démarre.
La tâche A (le service) effectue un enregistrement d'amorçage. Ici, le serveur d'amorçage crée un droit d'ENVOI, le conserve, et transfère le droit de RÉCEPTION à la tâche A.
launchd duplique le droit d'ENVOI et l'envoie à la tâche B.
La tâche B génère un nouveau port avec un droit de RÉCEPTION et un droit d'ENVOI, et donne le droit d'ENVOI à la tâche A (le svc) pour qu'elle puisse envoyer des messages à la TÂCHE B (communication bidirectionnelle).
Cependant, ce processus s'applique uniquement aux tâches système prédéfinies. Les tâches non système fonctionnent toujours comme décrit initialement, ce qui pourrait potentiellement permettre l'usurpation.
Un message Mach
Trouvez plus d'informations ici
La fonction mach_msg
, essentiellement un appel système, est utilisée pour envoyer et recevoir des messages Mach. La fonction nécessite que le message soit envoyé en tant qu'argument initial. Ce message doit commencer par une structure mach_msg_header_t
, suivie du contenu du message. La structure est définie comme suit:
Les processus possédant un droit de réception peuvent recevoir des messages sur un port Mach. En revanche, les expéditeurs se voient accorder un droit d'envoi ou un droit d'envoi unique. Le droit d'envoi unique est exclusivement pour l'envoi d'un seul message, après quoi il devient invalide.
Pour réaliser une communication bidirectionnelle facile, un processus peut spécifier un port Mach dans l'en-tête du message Mach appelé le port de réponse (msgh_local_port
) où le destinataire du message peut envoyer une réponse à ce message. Les indicateurs de bits dans msgh_bits
peuvent être utilisés pour indiquer qu'un droit d'envoi unique doit être dérivé et transféré pour ce port (MACH_MSG_TYPE_MAKE_SEND_ONCE
).
Notez que ce type de communication bidirectionnelle est utilisé dans les messages XPC qui attendent une réponse (xpc_connection_send_message_with_reply
et xpc_connection_send_message_with_reply_sync
). Mais généralement, des ports différents sont créés comme expliqué précédemment pour créer la communication bidirectionnelle.
Les autres champs de l'en-tête du message sont :
msgh_size
: la taille de l'ensemble du paquet.msgh_remote_port
: le port sur lequel ce message est envoyé.msgh_voucher_port
: bons Mach.msgh_id
: l'ID de ce message, qui est interprété par le destinataire.
Notez que les messages Mach sont envoyés sur un _port Mach_, qui est un canal de communication un seul destinataire, plusieurs expéditeurs intégré dans le noyau Mach. Plusieurs processus peuvent envoyer des messages à un port Mach, mais à tout moment, un seul processus peut le lire.
Énumérer les ports
Vous pouvez installer cet outil sur iOS en le téléchargeant depuis http://newosxbook.com/tools/binpack64-256.tar.gz
Exemple de code
Notez comment l'expéditeur alloue un port, crée un droit d'envoi pour le nom org.darlinghq.example
et l'envoie au serveur de démarrage tandis que l'expéditeur demande le droit d'envoi de ce nom et l'utilise pour envoyer un message.
Ports Privilégiés
Port hôte: Si un processus a le privilège Envoyer sur ce port, il peut obtenir des informations sur le système (par exemple,
host_processor_info
).Port de privilège hôte: Un processus avec le droit Envoyer sur ce port peut effectuer des actions privilégiées comme charger une extension de noyau. Le processus doit être root pour obtenir cette permission.
De plus, pour appeler l'API
kext_request
, il est nécessaire d'avoir d'autres autorisationscom.apple.private.kext*
qui ne sont données qu'aux binaires Apple.Port de nom de tâche: Une version non privilégiée du port de tâche. Il fait référence à la tâche, mais ne permet pas de la contrôler. La seule chose qui semble être disponible à travers lui est
task_info()
.Port de tâche (alias port noyau): Avec la permission d'envoi sur ce port, il est possible de contrôler la tâche (lecture/écriture en mémoire, création de threads...).
Appelez
mach_task_self()
pour obtenir le nom de ce port pour la tâche appelante. Ce port n'est hérité qu'à traversexec()
; une nouvelle tâche créée avecfork()
obtient un nouveau port de tâche (dans un cas particulier, une tâche obtient également un nouveau port de tâche aprèsexec()
dans un binaire suid). La seule façon de créer une tâche et d'obtenir son port est d'effectuer la "danse d'échange de port" tout en faisant unfork()
.Voici les restrictions d'accès au port (à partir de
macos_task_policy
du binaireAppleMobileFileIntegrity
):Si l'application a l'autorisation
com.apple.security.get-task-allow
, les processus du même utilisateur peuvent accéder au port de tâche (communément ajouté par Xcode pour le débogage). Le processus de notarisation ne le permettra pas pour les versions de production.Les applications avec l'autorisation
com.apple.system-task-ports
peuvent obtenir le port de tâche pour n'importe quel processus, sauf le noyau. Dans les anciennes versions, cela s'appelaittask_for_pid-allow
. Cela n'est accordé qu'aux applications Apple.Root peut accéder aux ports de tâche des applications non compilées avec un runtime renforcé (et non d'Apple).
Injection de code shell dans un thread via le port de tâche
Vous pouvez obtenir un code shell à partir de :
macOS IPC (Inter-Process Communication)
Mach Messages
Mach messages are the fundamental inter-process communication (IPC) mechanism in macOS. Processes can send messages to each other using Mach ports. Understanding how Mach messages work is crucial for privilege escalation and persistence techniques on macOS.
XPC Services
XPC Services are a type of service that allows you to create separate processes for performing specific tasks. They are commonly used for privilege separation and sandboxing in macOS applications. Understanding how XPC Services work is essential for macOS security research and exploitation.
Distributed Objects
Distributed Objects is another IPC mechanism in macOS that allows objects to be passed between processes. It is commonly used in macOS applications for communication between different components. Understanding how Distributed Objects work is important for analyzing and exploiting macOS applications.
NSXPCConnection
NSXPCConnection is a high-level API in macOS that simplifies the use of XPC Services for inter-process communication. It provides a convenient way to establish connections between processes and exchange messages securely. Understanding how NSXPCConnection works is crucial for developing secure macOS applications.
Conclusion
macOS provides various IPC mechanisms for inter-process communication, each with its own characteristics and use cases. Understanding these mechanisms is essential for macOS security researchers, developers, and hackers to analyze and exploit macOS applications effectively.
Compilez le programme précédent et ajoutez les droits nécessaires pour pouvoir injecter du code avec le même utilisateur (sinon vous devrez utiliser sudo).
Last updated