Macos Xpc Connection Get Audit Token Attack

macOS XPC Audit Token Spoofing

A skill for researching and understanding XPC audit token spoofing vulnerabilities on macOS. This covers the race condition class of bugs where an attacker can manipulate which process's audit token is used during authorization checks.

Core Concepts

Mach Messages

• Mach ports are single receiver, multiple sender communication channels
• Multiple processes can send messages to a mach port, but only one can read from it
• Ports are kernel-managed integers that processes use to communicate

XPC Connection Audit Tokens

• XPC's abstraction is one-to-one connection, but built on Mach's multiple sender technology
• An XPC connection's audit token is copied from the most recently received message
• Audit tokens are critical for security checks and authorization decisions

The Vulnerability

The core issue: XPC connections can have their audit token overwritten by messages from different senders under specific timing conditions.

Not vulnerable:

• Checks before accepting a connection (in -listener:shouldAcceptNewConnection:)
• Inside XPC event handlers (synchronous handling prevents overwrite)

Vulnerable patterns:

• xpc_connection_get_audit_token called outside the event handler (e.g., in dispatch_async)
• Reply message parsing concurrent with event handler execution

Attack Variant 1: Async Audit Token Check

Requirements

1. Two Mach services A and B that you can both connect to
2. Service A has an authorization check for an action that B can pass but you cannot
3. Service A obtains the audit token asynchronously (e.g., from dispatch_async)

Exploitation Flow

1. Connect to service A (e.g., smd)
2. Connect to service B (e.g., diagnosticd running as root)
3. Duplicate the send right of your A connection and use it as B's client port
4. Messages from B are now delivered to A's connection
5. Trigger B to send messages while you request the privileged action from A
6. Race condition: B's audit token overwrites yours during A's authorization check

Real-World Example: smd + diagnosticd

• Service A: smd (System Management Daemon)
• Service B: diagnosticd (runs as root, sends frequent monitoring messages)
• Privileged action: SMJobBless to install privileged helper tools as root
• Attack: Flood smd with messages while diagnosticd sends monitoring data, causing smd to use diagnosticd's root audit token

Attack Variant 2: Reply Forwarding

Requirements

1. Two Mach services A and B
2. Service A sends a message expecting a reply
3. You can send a message to B that it will respond to

Exploitation Flow

1. Wait for service A to send a message expecting a reply
2. Hijack the reply port instead of replying directly to A
3. Send the reply port to service B
4. Dispatch your privileged action request to A
5. Race condition: B's reply overwrites the audit token while your request is being parsed

Key Insight

• xpc_connection_send_message_with_reply: processed on designated queue
• xpc_connection_send_message_with_reply_sync: processed on current dispatch queue
• Reply packets can be parsed concurrently with event handler execution
• _xpc_connection_set_creds locks only the audit token, not the entire connection object

Discovery Techniques

Static Analysis

1. Search for xpc_connection_get_audit_token calls
2. Look for calls reachable from dispatch_async/dispatch_after blocks
3. Find authorization helpers mixing per-connection and per-message state:
   • xpc_connection_get_pid (per-connection) + xpc_connection_get_audit_token (per-connection)
4. In NSXPC code, verify checks use per-message audit tokens

Dynamic Analysis

Use the Frida hook script to detect vulnerable patterns:

# Run the Frida hook on a target process
frida -U -f <process-name> -l scripts/xpc-audit-token-hook.js --no-pause

The script flags xpc_connection_get_audit_token calls outside the event handler path.

Tooling

• gxpc: Open-source XPC sniffer for enumerating connections and observing traffic

  gxpc -p <PID> --whitelist <service-name>
  

• Frida: Dynamic instrumentation for hooking XPC functions
• IDA/Ghidra: Static analysis of Mach service binaries
• dyld interposing: Log call sites and stacks during black-box testing

Exploitation Primitives

Multi-Sender Setup (Variant 1)

Duplicate a SEND right to route B's messages through A's connection:

// Duplicate a SEND right you already hold
mach_port_t dup;
mach_port_insert_right(mach_task_self(), a_client, a_client, MACH_MSG_TYPE_MAKE_SEND);
dup = a_client; // Use `dup` when crafting B's connect packet

Reply Hijack (Variant 2)

Capture the send-once right from A's pending request and use it for B's reply:

// Extract reply port from A's message
mach_port_t reply_port = /* from A's message header */;

// Send to B using A's reply port
xpc_connection_send_message_with_reply(b_connection, message, reply_port);

The Fix

Apple's fix for CVE-2023-32405 in smd:

• Replace xpc_connection_get_audit_token with xpc_dictionary_get_audit_token
• The dictionary function retrieves the audit token directly from the mach message
• This prevents race conditions since the token is tied to the specific message

Note: xpc_dictionary_get_audit_token is not part of the public API.

Current Status (2024-2025)

• The issue persists in iOS 17 and macOS 14
• Apple has not implemented a broader fix (possibly due to legitimate audit token changes in setuid scenarios)
• Focus on authorization performed outside message event handlers or concurrently with reply processing

References

• Sector 7 – Don't Talk All at Once!
• Apple – macOS Ventura 13.4 Security Content (CVE-2023-32405)

Quick Start

To begin researching XPC audit token vulnerabilities:

1. Identify target services using gxpc or by examining Mach ports
2. Run the Frida hook to detect vulnerable xpc_connection_get_audit_token calls
3. Analyze the call stack to determine if the check is outside the event handler
4. Map the authorization flow to understand what privileges are being checked
5. Identify a second service (B) with higher privileges that can send messages to the target
6. Craft the exploit using the appropriate variant based on the vulnerability pattern