Crash One - A StarBucks Story (CVE-2025-24277)

Crash One - A StarBucks Story (CVE-2025-24277)

Speakers: Csaba Fitzl (Kandji), Gergely Kalman (Independent)

Conference: Hexacon

YouTube: https://www.youtube.com/watch?v=IQzeFnqywh8

Overview

This talk, "Crash One - A Starbucks Story," presented by Csaba Fitzl and Gergely Kalman, delves into a critical vulnerability (CVE-2025-24277) they uncovered in macOS. The presentation meticulously details a chained exploit that leverages a flaw in the OS analytics helperd process, a root-running daemon responsible for writing crash logs, to achieve both arbitrary file write and ultimately, full privilege escalation and a macOS sandbox escape. What began as an initially dismissed bug, deemed "unexploitable" by both researchers due to perceived sandbox limitations, evolved into a sophisticated attack vector capable of compromising system integrity.

The talk is significant because it highlights several fundamental weaknesses in macOS security paradigms, including the often-overlooked implications of dynamic sandbox extensions, the inherent race conditions within standard POSIX file operations like rename, and the subtle power of Access Control Lists (ACLs) in bypassing traditional Unix permissions. Fitzl and Kalman not only provide a deep technical dive into the vulnerability's mechanics but also demonstrate a practical, multi-stage exploit that transforms a sandboxed user-level code execution into a root-privileged, unsandboxed remote shell. Their journey from initial skepticism to full system compromise serves as a compelling case study in persistent vulnerability research and creative exploitation techniques.

Background

▶ Watch: Initial bug: OS analytics helperd writes root-owned crash logs (2:00)

The journey into CVE-2025-24277 began with Csaba Fitzl and Gergely Kalman discussing a peculiar behavior they both independently observed in the OS analytics helperd process. This helper daemon, running with root privileges, is responsible for writing out process crash logs. When a user-level process crashes, the log is written to ~/Library/Logs/DiagnosticReports, a user-controlled directory. If a root process crashes, the log goes to /Library/Logs/DiagnosticReports. The initial point of interest was the root daemon writing into a user-owned directory, leading to thoughts of potential privilege escalation by redirecting the crash log.

Their initial attempts to exploit this were met with several roadblocks. File system events revealed that OS analytics helperd would open the target directory, then create the crash file, chown it to the user, and finally rename it from .processname.time to processname.time. They tried symlinking the directory or using hard links, but these attempts failed. The process checked for symlinks to the target directory, and although it didn't error, it didn't allow redirection. Furthermore, the file was opened with O_EXCL | O_CREAT flags, meaning it would not be created if it already existed, preventing pre-placement of files or hard links. The most significant perceived limitation was the sandbox profile of OS analytics helperd, which was believed to restrict writes to only specific, safe directories.

However, a crucial detail was initially overlooked: a specific entry in the sandbox profile that stated: "if the process has an extension com.apple.security.sandbox.read-write, then it can read and write anywhere on the file system." This discovery changed everything. Sandbox extensions on macOS are a mechanism for dynamically expanding a process's sandbox capabilities. They are essentially signed tokens, typically in a C string format, that allow an unsandboxed process (or one with sufficient privileges) to grant temporary or permanent additional file system access to a sandboxed process. The typical flow involves an unsandboxed Process A generating a token, sending it via XPC (eXternal Procedure Call) or another IPC (Inter-Process Communication) mechanism to sandboxed Process B, which then must explicitly consume the token using APIs like sandbox_extension_consume. This realization opened the door to potentially granting OS analytics helperd arbitrary file system write access, despite its restrictive default sandbox.

Key Findings

▶ Watch: Understanding macOS sandbox extensions and token mechanism (4:30)

The core discoveries and contributions of this research can be summarized as follows:

1. Dynamic Sandbox Expansion Exploitation: The critical finding was that OS analytics helperd, a root-privileged daemon, could be coerced into consuming a sandbox extension token. This token, crafted by the attacker, granted the daemon the com.apple.security.sandbox.read-write privilege, effectively allowing it to write to any location on the file system, bypassing its default restrictive sandbox profile. This transformed the "unexploitable" file write into a powerful arbitrary file write primitive.

1. XPC Message Reconstruction: The researchers successfully reverse-engineered the complex XPC message structure required to communicate with OS analytics helperd and trigger crash log generation. This was achieved by sniffing a legitimate message generated during a crash and using AI (specifically, GPT) to reconstruct the corresponding C code, significantly accelerating the research process.

1. Back Channel Handling for File Control: A crucial, undocumented "back channel" mechanism was discovered within OS analytics helperd. After creating a crash file, the daemon would establish a new XPC connection back to the caller, sending a file descriptor for the newly created file. The caller was then expected to populate this file with additional crash data and return a 1 to prevent its deletion. Implementing an anonymous XPC listener to correctly handle this back channel was essential for the exploit to succeed and gain full control over the content of the created file.

1. In-Place Rename Race Condition Primitive: The talk highlighted the inherent race condition in the rename system call on POSIX-compliant systems, particularly when used for "in-place renames" (where only the file's leading dot is removed). By switching the directory of the target path between the source and destination path resolution, an attacker could achieve an almost fully controlled file overwrite. This primitive allowed an attacker to move an arbitrary, attacker-controlled file to a root-owned, system-critical location, albeit without full control over the final file name.

1. ACL-Based Persistent Ownership Bypass: To overcome the challenge of OS analytics helperd changing the ownership of the created file to the user, the researchers employed Access Control Lists (ACLs). By setting specific ACLs (file_inherit and directory_inherit) on a directory, they could ensure that any file dropped into it, even if chowned by root, would retain specific permissions for the attacker. This allowed the attacker to maintain control over the content of the file even after it was moved to a root-owned location.

1. Chained Privilege Escalation and Sandbox Escape: The ultimate finding was the successful chaining of these primitives. First, arbitrary file write via sandbox extension and XPC communication, combined with the rename race condition, allowed the placement of a malicious file into /etc/sudoers.d/, granting passwordless sudo. Second, by leveraging the fact that even sandboxed system binaries could communicate with OS analytics helperd, they demonstrated a full sandbox escape. This was achieved by dropping a malicious DMG (Disk Image) file (without a quarantine flag) into a default writable location, then mounting it and launching an unsandboxed application from within, which then executed the privilege escalation exploit, leading to a full root shell from a sandboxed process (e.g., a screensaver).

Technical Deep Dive

▶ Watch: Using GPT to reconstruct complex XPC messages (6:40)

The technical depth of this vulnerability and its exploitation spans several layers of macOS internals. At its core is the OS analytics helperd daemon, a root-privileged process designed to manage crash logs. The daemon's sandbox profile initially appeared restrictive, but a critical line (extension "com.apple.security.sandbox.read-write") within it revealed a potential avenue for dynamic sandbox expansion.

Sandbox Extension Mechanics:

macOS sandbox extensions are powerful tokens that dynamically modify a process's sandbox. An unsandboxed process can generate such a token using sandbox_extension_create_file (or similar APIs for directories or global access). This token, a C string, is then passed via XPC to a sandboxed process. The sandboxed process must explicitly call sandbox_extension_consume with the token to activate the extended permissions. In this case, the researchers crafted a token for the root directory (/), effectively granting OS analytics helperd system-wide read/write capabilities once consumed.

XPC Communication and Message Reconstruction:

Communicating with OS analytics helperd required understanding its XPC interface. Rather than attempting to fully reverse-engineer the complex, multi-hundred-line XPC handler function, the researchers employed a clever shortcut. They crashed a process, sniffed the XPC message sent to OS analytics helperd, and then leveraged a large language model (GPT) to reconstruct the corresponding C code for sending that message. This significantly reduced the time and effort typically required for such reverse engineering. The message included parameters such as the process ID (PID) of the crashing process, the path for the crash log, and critically, a dataWriter endpoint.

The Back Channel Dilemma:

Initial attempts to simply send the XPC message and consume the token failed to create the file. This led to the discovery of a "back channel" mechanism. After OS analytics helperd creates the initial crash file, it establishes a new XPC connection to the dataWriter endpoint provided in the original message. Over this back channel, it sends a file descriptor for the newly created crash file to the caller. The caller (typically reportcrash, the main crash reporting utility) is then expected to write additional crash data (stack traces, memory maps, etc.) into this file and return a specific value (1). If 1 is not returned, OS analytics helperd deletes the file. To successfully exploit this, the attackers had to implement an anonymous XPC listener on their side, handle the incoming file descriptor, and correctly return 1, thus allowing them to gain full control over the file's content and prevent its deletion.

The In-Place Rename Race Condition (CVE-2025-24277):

With arbitrary file creation and content control in a user-controlled directory, the next step was to elevate privileges. The key primitive here was a race condition in the rename system call. The OS analytics helperd process performs an "in-place rename" by changing the file name from .processname.time to processname.time within the same directory. While intuitively, one might expect the kernel to be "smart" and atomic, POSIX rename is not always atomic across directory changes. The kernel resolves the source path and the destination path separately. If, between these two resolutions, an attacker can replace the target directory with a symlink to an arbitrary location, the rename operation will effectively move the attacker-controlled file (created by OS analytics helperd) into a root-owned, system-critical directory. This is a classic race condition, requiring rapid manipulation of the file system. The researchers noted that this behavior is common on POSIX systems, including Linux.

Exploiting the Race with ACLs:

The race condition allows moving an attacker-controlled file to an arbitrary location, but there were two remaining challenges:

1. File Name Control: The final file name (processname.time) is not fully controlled by the attacker.
2. Ownership: OS analytics helperd chowns the file to the user before the rename.

To address the file name issue for privilege escalation, the target chosen was /etc/sudoers.d/. This directory is used by sudo to load additional configuration files, and critically, the file name within this directory does not matter, only its content and permissions (root-owned, specific Unix permissions). An attacker-controlled file dropped here could grant passwordless sudo access.

To address the ownership problem while retaining control, the researchers employed ACLs (Access Control Lists). ACLs on macOS (based on BSD) are distinct from traditional Unix permissions and allow for more granular control. A key feature is the ability to set file_inherit and directory_inherit flags on a directory. By setting an ACL on the symlink target directory (the temporary directory the attacker controls before the race), the attacker could grant their user full permissions (read, write, execute, delete) that would inherit to any file created within it, even if that file was subsequently chowned by root. This meant that even after OS analytics helperd changed the file's ownership to the root user, the attacker's user would still retain full control over its content due to the inherited ACLs, making it effectively invisible to most user-space programs that only check standard Unix permissions. The transcript also mentions Csaba found a "very cool way to sidestep all of this by setting a flag" on the file itself, implying an immutable flag, further solidifying control against root's chown.

Demo / Proof of Concept

▶ Watch: Exploitation challenge: Discovering the XPC back channel mechanism (7:30)

The talk featured two significant demonstrations: a privilege escalation to root and a full macOS sandbox escape.

Privilege Escalation Demo:

The first demonstration showed the privilege escalation from a standard user to root. The exploit consisted of two main components:

1. A C program (the "trigger") responsible for handling the complex XPC client communication, generating and consuming sandbox extensions, and managing the back channel callbacks. This part was crucial for correctly interacting with OS analytics helperd.
2. A Python script that prepared the environment (e.g., creating the necessary symlinks for the race condition, setting ACLs) and then repeatedly executed the C trigger program. Since the exploit relied on a race condition, brute-forcing attempts were necessary.

The demo showed the Python script running, continuously attempting to win the race. After a few minutes (the video was sped up), the exploit successfully dropped a malicious file into /etc/sudoers.d/. The subsequent attempt to run sudo -l (list sudo privileges) from the attacker's shell showed that the user could now execute sudo commands without needing a password, confirming root privilege escalation.

Sandbox Escape Demo:

The second, more impactful demonstration showcased a full macOS sandbox escape, chained with the privilege escalation. The premise was to escape from a heavily sandboxed system process, such as a screensaver.

The attack flow for the sandbox escape was as follows:

1. Initial Compromise: The scenario assumes initial code execution within a sandboxed system binary (e.g., a vulnerable screensaver).
2. XPC Communication from Sandbox: Crucially, the researchers found that even sandboxed system binaries on macOS are permitted to communicate with OS analytics helperd via XPC. This meant the initial sandbox extension redirection trick could still be used.
3. DMG Dropping: Instead of targeting etc/sudoers.d directly from the sandbox, the strategy was to drop a malicious DMG (Disk Image) file into ~/Library/Logs/DiagnosticReports. This directory is writable by default for sandboxed processes.
4. Full File Control: Using the back channel mechanism, the attackers gained full control over the content of the DMG file being written, allowing them to populate it with a custom disk image containing an unsandboxed application. Furthermore, the XPC message allowed full file name control, which is critical for creating a valid DMG.
5. Unquarantined DMG: The key was to ensure the dropped DMG did not have a quarantine flag. A DMG without this flag, when opened, allows applications within it to run without Gatekeeper prompts or sandbox restrictions.
6. Chained Exploit: The sandboxed screensaver would then open this unquarantined DMG, mount it, and launch an application contained within. This launched application was unsandboxed and was designed to execute the previously developed privilege escalation exploit.
7. Root Shell: The demo concluded with the screensaver launching the unsandboxed application, which then performed the sudoers.d exploit, leading to a remote shell callback running with root privileges, demonstrating a complete escape from a sandboxed user context to an unsandboxed root shell.

Defensive Implications

▶ Watch: Understanding back channel: file descriptor and required return value (8:00)

The detailed analysis and exploitation of CVE-2025-24277 provide several critical lessons for macOS defenders and developers:

1. Sandbox Extension Vigilance: The most immediate implication is the inherent danger of dynamically expanding sandbox capabilities. Developers must be extremely cautious when designing XPC services that can consume sandbox extensions, especially if those services run with elevated privileges. Defenders should monitor for unusual sandbox_extension_create_file or sandbox_extension_consume calls, particularly from unexpected processes or targeting sensitive file system locations.

1. Secure File Operations: The rename race condition highlights a fundamental vulnerability in how file operations are often implemented in POSIX environments. Developers should be aware that rename is not always atomic in the context of directory changes and should prefer more secure, atomic alternatives when dealing with sensitive files or directories. Apple's fix, using renameatx_np with the RENAME_NO_FOLLOW_ANY flag, demonstrates the correct approach to prevent symlink following during rename operations. This flag explicitly disallows following symbolic links in the path, effectively mitigating the race.

1. ACL Awareness: The use of ACLs to maintain file control despite ownership changes is a sophisticated technique that can bypass traditional Unix permission checks. Defenders should consider integrating ACL checks into their security monitoring and auditing tools, as many user-space programs (including security tools) may overlook them, relying solely on standard Unix permissions. Unusual or overly permissive ACLs on system-critical directories or files could indicate compromise.

1. **Hardening etc/*.d Directories:** Directories like /etc/sudoers.d/, /etc/launchd.d/, or similar configuration directories that process arbitrary files without strict naming conventions are prime targets for privilege escalation. System administrators should ensure these directories have the most restrictive possible permissions and are constantly monitored for unexpected file creations or modifications. Immutable flags (like uchg) could also be considered for critical files.

1. XPC Service Hardening: Any XPC service that runs with elevated privileges or interacts with sensitive system resources should be thoroughly audited. Access to such services should be strictly controlled via entitlement checks, ensuring only authorized system binaries with specific, private entitlements can communicate with them. Apple's patch for OS analytics helperd, adding a private entitlement check, is a direct response to this vulnerability. Any process attempting to communicate without this entitlement is now immediately killed.

1. Sandbox Escape Chaining: The demonstration of chaining a sandbox escape with privilege escalation underscores the importance of a layered security approach. Even robust sandboxes can be bypassed if underlying system services have exploitable flaws. Defenders should assume that if code execution is achieved within a sandbox, attackers will attempt to leverage any available inter-process communication channels or file system access to further escalate privileges or break out.

Key Takeaways

• OS analytics helperd, a root-privileged macOS daemon, was vulnerable due to its ability to consume attacker-controlled sandbox extensions via XPC, leading to arbitrary file system write capabilities.
• The rename system call on POSIX-compliant systems can be subject to race conditions when used for "in-place renames," allowing an attacker to achieve an almost fully controlled file overwrite primitive by manipulating symlinks.
• Access Control Lists (ACLs) on macOS can be leveraged by attackers to maintain persistent control over files, even after their ownership has been changed by a root process, often bypassing standard permission checks by security tools.
• A full macOS sandbox escape was demonstrated by chaining the arbitrary file write with the ability to drop an unquarantined DMG file containing an unsandboxed application, which then executed the privilege escalation exploit.
• Apple's patch for CVE-2025-24277 involved two key mitigations: implementing a private entitlement check for OS analytics helperd's XPC interface and fixing the rename race condition using renameatx_np with the RENAME_NO_FOLLOW_ANY flag.
• Thorough analysis of sandbox profiles, especially for privileged daemons, and understanding the nuances of low-level file system operations are crucial for uncovering and mitigating critical vulnerabilities in operating systems.

About the Speaker(s)

Csaba Fitzl is currently a macOS security researcher at Kandji, a company specializing in MDM (Mobile Device Management) and EDR (Endpoint Detection and Response) solutions. Prior to Kandji, Csaba worked at Offensive Security, where he focused on writing macOS exploitation training. He is an active macOS bug hunter and has an impressive track record, credited with over 100 CVEs with Apple. Outside of his security research, he enjoys trail running and hiking.

Gergely Kalman (also known as "G" or "Greg") is an independent bug hunter. He brings a wealth of experience from his background as an Xstav and CIS admin. Gergely is a prolific vulnerability researcher, particularly within Apple's ASB (Apple Security Bounty) program, where he has discovered over 20 zero-day vulnerabilities. His research primarily focuses on logic bugs and in-depth follow-up research to uncover deeper exploitation paths.