Mach uses tasks as the smallest unit for sharing resources, and each task can contain multiple threads. These tasks and threads are mapped 1:1 to POSIX processes and threads.
Communication between tasks occurs via Mach Inter-Process Communication (IPC), utilising one-way communication channels. Messages are transferred between ports, which act like message queues managed by the kernel.
Each process has an IPC table, in there it's possible to find the mach ports of the process. The name of a mach port is actually a number (a pointer to the kernel object).
A process can also send a port name with some rights to a different task and the kernel will make this entry in the IPC table of the other task appear.
Port Rights
Port rights, which define what operations a task can perform, are key to this communication. The possible port rights are (definitions from here):
Receive right, which allows receiving messages sent to the port. Mach ports are MPSC (multiple-producer, single-consumer) queues, which means that there may only ever be one receive right for each port in the whole system (unlike with pipes, where multiple processes can all hold file descriptors to the read end of one pipe).
A task with the Receive right can receive messages and create Send rights, allowing it to send messages. Originally only the own task has Receive right over its port.
Send right, which allows sending messages to the port.
The Send right can be cloned so a task owning a Send right can clone the right and grant it to a third task.
Send-once right, which allows sending one message to the port and then disappears.
Port set right, which denotes a port set rather than a single port. Dequeuing a message from a port set dequeues a message from one of the ports it contains. Port sets can be used to listen on several ports simultaneously, a lot like select/poll/epoll/kqueue in Unix.
Dead name, which is not an actual port right, but merely a placeholder. When a port is destroyed, all existing port rights to the port turn into dead names.
Tasks can transfer SEND rights to others, enabling them to send messages back. SEND rights can also be cloned, so a task can duplicate and give the right to a third task. This, combined with an intermediary process known as the bootstrap server, allows for effective communication between tasks.
File Ports
File ports allows to encapsulate file descriptors in Mac ports (using Mach port rights). It's possible to create a fileport from a given FD using fileport_makeport and create a FD froma. fileport using fileport_makefd.
Establishing a communication
Steps:
As it's mentioned, in order to establish the communication channel, the bootstrap server (launchd in mac) is involved.
Task A initiates a new port, obtaining a RECEIVE right in the process.
Task A, being the holder of the RECEIVE right, generates a SEND right for the port.
Task A establishes a connection with the bootstrap server, providing the port's service name and the SEND right through a procedure known as the bootstrap register.
Task B interacts with the bootstrap server to execute a bootstrap lookup for the service name. If successful, the server duplicates the SEND right received from Task A and transmits it to Task B.
Upon acquiring a SEND right, Task B is capable of formulating a message and dispatching it to Task A.
For a bi-directional communication usually task B generates a new port with a RECEIVE right and a SEND right, and gives the SEND right to Task A so it can send messages to TASK B (bi-directional communication).
The bootstrap server cannot authenticate the service name claimed by a task. This means a task could potentially impersonate any system task, such as falsely claiming an authorization service name and then approving every request.
Then, Apple stores the names of system-provided services in secure configuration files, located in SIP-protected directories: /System/Library/LaunchDaemons and /System/Library/LaunchAgents. Alongside each service name, the associated binary is also stored. The bootstrap server, will create and hold a RECEIVE right for each of these service names.
For these predefined services, the lookup process differs slightly. When a service name is being looked up, launchd starts the service dynamically. The new workflow is as follows:
Task B initiates a bootstrap lookup for a service name.
launchd checks if the task is running and if it isn’t, starts it.
Task A (the service) performs a bootstrap check-in. Here, the bootstrap server creates a SEND right, retains it, and transfers the RECEIVE right to Task A.
launchd duplicates the SEND right and sends it to Task B.
Task B generates a new port with a RECEIVE right and a SEND right, and gives the SEND right to Task A (the svc) so it can send messages to TASK B (bi-directional communication).
However, this process only applies to predefined system tasks. Non-system tasks still operate as described originally, which could potentially allow for impersonation.
The mach_msg function, essentially a system call, is utilized for sending and receiving Mach messages. The function requires the message to be sent as the initial argument. This message must commence with a mach_msg_header_t structure, succeeded by the actual message content. The structure is defined as follows:
Processes possessing a receive right can receive messages on a Mach port. Conversely, the senders are granted a send or a send-once right. The send-once right is exclusively for sending a single message, after which it becomes invalid.
In order to achieve an easy bi-directional communication a process can specify a mach port in the mach message header called the reply port (msgh_local_port) where the receiver of the message can send a reply to this message. The bitflags in msgh_bits can be used to indicate that a send-onceright should be derived and transferred for this port (MACH_MSG_TYPE_MAKE_SEND_ONCE).
Note that this kind of bi-directional communication is used in XPC messages that expect a replay (xpc_connection_send_message_with_reply and xpc_connection_send_message_with_reply_sync). But usually different ports are created as explained previously to create the bi-directional communication.
The other fields of the message header are:
msgh_size: the size of the entire packet.
msgh_remote_port: the port on which this message is sent.
msgh_id: the ID of this message, which is interpreted by the receiver.
Note that mach messages are sent over a _mach port_, which is a single receiver, multiple sender communication channel built into the mach kernel. Multiple processes can send messages to a mach port, but at any point only a single process can read from it.
Note how the senderallocates a port, create a send right for the name org.darlinghq.example and send it to the bootstrap server while the sender asked for the send right of that name and used it to send a message.
// Code from https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html// gcc receiver.c -o receiver#include<stdio.h>#include<mach/mach.h>#include<servers/bootstrap.h>intmain() {// Create a new port.mach_port_t port;kern_return_t kr =mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE,&port);if (kr != KERN_SUCCESS) {printf("mach_port_allocate() failed with code 0x%x\n", kr);return1; }printf("mach_port_allocate() created port right name %d\n", port);// Give us a send right to this port, in addition to the receive right. kr =mach_port_insert_right(mach_task_self(), port, port, MACH_MSG_TYPE_MAKE_SEND);if (kr != KERN_SUCCESS) {printf("mach_port_insert_right() failed with code 0x%x\n", kr);return1; }printf("mach_port_insert_right() inserted a send right\n");// Send the send right to the bootstrap server, so that it can be looked up by other processes. kr =bootstrap_register(bootstrap_port,"org.darlinghq.example", port);if (kr != KERN_SUCCESS) {printf("bootstrap_register() failed with code 0x%x\n", kr);return1; }printf("bootstrap_register()'ed our port\n");// Wait for a message.struct {mach_msg_header_t header;char some_text[10];int some_number;mach_msg_trailer_t trailer; } message; kr =mach_msg(&message.header, // Same as (mach_msg_header_t *) &message. MACH_RCV_MSG, // Options. We're receiving a message.0, // Size of the message being sent, if sending.sizeof(message), // Size of the buffer for receiving. port, // The port to receive a message on. MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL // Port for the kernel to send notifications about this message to. );if (kr != KERN_SUCCESS) {printf("mach_msg() failed with code 0x%x\n", kr);return1; }printf("Got a message\n");message.some_text[9] =0;printf("Text: %s, number: %d\n",message.some_text,message.some_number);}
// Code from https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html// gcc sender.c -o sender#include<stdio.h>#include<mach/mach.h>#include<servers/bootstrap.h>intmain() {// Lookup the receiver port using the bootstrap server.mach_port_t port;kern_return_t kr =bootstrap_look_up(bootstrap_port,"org.darlinghq.example",&port);if (kr != KERN_SUCCESS) {printf("bootstrap_look_up() failed with code 0x%x\n", kr);return1; }printf("bootstrap_look_up() returned port right name %d\n", port);// Construct our message.struct {mach_msg_header_t header;char some_text[10];int some_number; } message;message.header.msgh_bits =MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND,0);message.header.msgh_remote_port = port;message.header.msgh_local_port = MACH_PORT_NULL;strncpy(message.some_text,"Hello",sizeof(message.some_text));message.some_number =35;// Send the message. kr =mach_msg(&message.header, // Same as (mach_msg_header_t *) &message. MACH_SEND_MSG, // Options. We're sending a message.sizeof(message), // Size of the message being sent.0, // Size of the buffer for receiving. MACH_PORT_NULL, // A port to receive a message on, if receiving. MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL // Port for the kernel to send notifications about this message to. );if (kr != KERN_SUCCESS) {printf("mach_msg() failed with code 0x%x\n", kr);return1; }printf("Sent a message\n");}
Privileged Ports
Host port: If a process has Send privilege over this port he can get information about the system (e.g. host_processor_info).
Host priv port: A process with Send right over this port can perform privileged actions like loading a kernel extension. The process need to be root to get this permission.
Moreover, in order to call kext_request API it's needed to have other entitlements com.apple.private.kext* which are only given to Apple binaries.
Task name port: An unprivileged version of the task port. It references the task, but does not allow controlling it. The only thing that seems to be available through it is task_info().
Task port (aka kernel port): With Send permission over this port it's possible to control the task (read/write memory, create threads...).
Call mach_task_self() to get the name for this port for the caller task. This port is only inherited across exec(); a new task created with fork() gets a new task port (as a special case, a task also gets a new task port after exec()in a suid binary). The only way to spawn a task and get its port is to perform the "port swap dance" while doing a fork().
These are the restrictions to access the port (from macos_task_policy from the binary AppleMobileFileIntegrity):
If the app has com.apple.security.get-task-allow entitlement processes from the same user can access the task port (commonly added by Xcode for debugging). The notarization process won't allow it to production releases.
Apps with the com.apple.system-task-ports entitlement can get the task port for any process, except the kernel. In older versions it was called task_for_pid-allow. This is only granted to Apple applications.
Root can access task ports of applications not compiled with a hardened runtime (and not from Apple).
In macOS threads might be manipulated via Mach or using posix pthread api. The thread we generated in the previos injection, was generated using Mach api, so it's not posix compliant.
It was possible to inject a simple shellcode to execute a command because it didn't need to work with posix compliant apis, only with Mach. More complex injections would need the thread to be also posix compliant.
Therefore, to improve the thread it should call pthread_create_from_mach_thread which will create a valid pthread. Then, this new pthread could call dlopen to load a dylib from the system, so instead of writing new shellcode to perform different actions it's possible to load custom libraries.
You can find example dylibs in (for example the one that generates a log and then you can listen to it):
XPC, which stands for XNU (the kernel used by macOS) inter-Process Communication, is a framework for communication between processes on macOS and iOS. XPC provides a mechanism for making safe, asynchronous method calls between different processes on the system. It's a part of Apple's security paradigm, allowing for the creation of privilege-separated applications where each component runs with only the permissions it needs to do its job, thereby limiting the potential damage from a compromised process.
For more information about how this communication work on how it could be vulnerable check:
MIG was created to simplify the process of Mach IPC code creation. It basically generates the needed code for server and client to communicate with a given definition. Even if the generated code is ugly, a developer will just need to import it and his code will be much simpler than before.