{"id":130323,"date":"2023-05-30T09:00:00","date_gmt":"2023-05-30T16:00:00","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/?p=130323"},"modified":"2025-06-18T04:52:31","modified_gmt":"2025-06-18T11:52:31","slug":"new-macos-vulnerability-migraine-could-bypass-system-integrity-protection","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2023\/05\/30\/new-macos-vulnerability-migraine-could-bypass-system-integrity-protection\/","title":{"rendered":"New macOS vulnerability, Migraine, could bypass System Integrity Protection"},"content":{"rendered":"\n

A new vulnerability, which we refer to as \u201cMigraine\u201d for its involvement with macOS migration, could allow an attacker with root access to automatically bypass System Integrity Protection<\/a> (SIP) in macOS and perform arbitrary operations on a device. We shared these findings with Apple through Coordinated Vulnerability Disclosure<\/a> (CVD) via Microsoft Security Vulnerability Research<\/a> (MSVR). A fix for this vulnerability, now identified as <\/a>CVE-2023-32369<\/a>, was included in the security updates released by Apple<\/a> on May 18, 2023.<\/p>\n\n\n\n

SIP is a security technology in macOS that restricts a root user from performing operations that may compromise system integrity. Bypassing SIP could lead to serious consequences, such as increasing the potential for attackers and malware authors to successfully install rootkits, create persistent malware, and expand the attack surface for additional techniques and exploits. The technique uncovered in this blog post was discovered during routine malware hunting and is similar to the one used in the Shrootless vulnerability<\/a> (CVE-2021-30892) that we published in 2021. By focusing on system processes that are signed by Apple and have the com.apple.rootless.install.heritable<\/em> entitlement<\/a>, we found two child processes that could be tampered with to gain arbitrary code execution in a security context that bypasses SIP checks.<\/p>\n\n\n\n

In this blog post, we share some information about the relationship between SIP and entitlements, and we detail how the \u201cMigraine\u201d vulnerability could be exploited to bypass the SIP security enforcements. We\u2019re sharing this research with the larger security community to emphasize the importance of collaboration in the effort to secure platforms and devices.<\/p>\n\n\n\n

SIP and entitlements<\/h2>\n\n\n\n

As previously covered in our Shrootless vulnerability blog post<\/a>, System Integrity Protection (SIP)\u2014also known as \u201crootless\u201d\u2014was first introduced by Apple in macOS Yosemite. SIP essentially locks down the system from root by leveraging the Apple sandbox to protect the entire platform, conceptually similar to how SELinux<\/a> protects Linux systems. One of the most dominant features of SIP is the filesystem restriction capability, which protects entire files and directories from being overridden. The files and directories that are protected by SIP by default are commonly ones that are related to the system\u2019s integrity.<\/p>\n\n\n\n

There is no way to turn off SIP on a live system\u2014the user must use the recovery OS, which requires physical access to the device. A SIP bypass is a vulnerability that bypasses SIP restrictions, for example, bypassing restrictions to write to SIP-protected directories or create a SIP-protected file.<\/p>\n\n\n\n

Another important macOS concept is entitlements. According to documentation<\/a>, \u201can entitlement is a right or privilege that grants an executable particular capabilities\u201d. As entitlements take part in the app signing process, there is no legitimate way of forging them. Apple uses entitlements extensively to enforce security on macOS, and Apple grants internal entitlements to very specific processes. Specifically, certain processes are assigned entitlements that allow the process to bypass System Integrity Protection checks by design. One particularly interesting entitlement is the com.apple.rootless.install.heritable<\/em> entitlement that allows the process and the entire process tree rooted under it to bypass filesystem-based System Integrity Protection security enforcements.<\/p>\n\n\n\n

Discovering a SIP bypass by design<\/h2>\n\n\n\n

Our research team regularly looks for malware and suspicious activity. During a routine malware hunt, we discovered the execution of a binary called drop_sip<\/em> using the below advanced hunting<\/a> query in Microsoft 365 Defender:<\/p>\n\n\n

\nDeviceProcessEvents\n| where FileName =~ \"drop_sip\"\n| project InitiatingProcessFileName, ProcessCommandLine, SHA256\n<\/pre><\/div>\n\n\n
Thinking that we found an exploit in the wild, we found that it\u2019s an Apple-signed binary that resides natively under the \/System\/Library\/PrivateFrameworks\/SystemMigrationUtils.framework\/Resources\/Tools\/drop_sip<\/em> path.<\/p>\n\n\n\n
Upon analysis, the file appears to invoke the csops<\/em> system call (undocumented, but available here<\/a>) and starts a child process. The operation flag for the csops<\/em> call is 12 (CS_OPS_CLEARINSTALLER<\/em>), which re-enables SIP checks<\/strong> by clearing codesigning flags, specifically the CS_EXEC_INHERIT_SIP<\/em> flag:<\/p>\n\n\n
\"Code
Figure 1. drop_sip<\/em>’s functionality is to change the code signing flags and execute a child process<\/figcaption><\/figure>\n\n\n
\"Code
Figure 2. Modification of the p_csflags<\/em> member as a result of the csops <\/em>system call – re-enables SIP<\/figcaption><\/figure>\n\n\n\n
Because of this behavior, we concluded the drop_sip<\/em> process assumes it can bypass SIP. However, since drop_sip<\/em> is not entitled with any SIP-bypassing entitlements, we concluded that it must inherit that capability. We discovered its parent process is systemmigrationd<\/em>, which is a daemon designed to handle migration scenarios, but most importantly, it\u2019s entitled with the com.apple.rootless.install.heritable<\/em> entitlement that allows its child processes to bypass SIP security checks:<\/p>\n\n\n
\"Code
Figure 3. systemmigrationd <\/em>entitled with SIP-bypassing capabilities<\/figcaption><\/figure>\n\n\n\n
Developing a \u201cMigraine\u201d<\/h2>\n\n\n\n
After discovering the parent process of drop_sip<\/em>, we wondered if there are any other child processes of systemmigrationd<\/em>. Just as before, we used the below advanced hunting<\/a> query in Microsoft 365 Defender:<\/p>\n\n\n
\nDeviceProcessEvents\n| where InitiatingProcessFileName =~ \"systemmigrationd\"\n| summarize Hits=count(), Cmdline=any(ProcessCommandLine) by FileName\n<\/pre><\/div>\n\n\n
We found two interesting child processes of systemmigrationd<\/em>:<\/p>\n\n\n\n
FileName<\/strong><\/td>Hits<\/strong><\/td>Cmdline<\/strong><\/td><\/tr>
bash<\/strong><\/td>498<\/td>\/bin\/bash \/System\/Library\/PrivateFrameworks\/SystemMigration.framework\/Resources\/MigrationData\/Scripts\/firstbootDirectoryServer<\/td><\/tr>
perl<\/strong><\/td>171<\/td>\/usr\/bin\/perl \/usr\/libexec\/migrateLocalKDC –source “\/Volumes\/REDACTED\/Backups.backupdb\/REDACTED\/Macintosh HD – Data” –source-REDACTED<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The bash <\/em>and perl<\/em> binaries are interesting because they are both interpreters. Similar to how we tampered<\/a> with the zsh<\/em> codeflow<\/a> back in 2021, we found similar ways to tamper with the code flow of bash<\/em> and perl<\/em>:<\/p>\n\n\n
\"Code
Figure 4. The bash manual page states BASH_ENV<\/em> as a way to run arbitrary commands in bash instances<\/figcaption><\/figure>\n\n\n
\"Code
Figure 5. The “perlrun<\/em>” manual page states PERL5OPT <\/em>as a way to run arbitrary commands in perl instances<\/figcaption><\/figure>\n\n\n\n
Assuming an attacker first gains code execution capabilities as root, setting environment variables that affect systemmigrationd<\/em> and its child processes is straightforward using the launchctl<\/em><\/a> utility. For instance, to make perl<\/em> run our arbitrary code that resides under \/private\/tmp\/migraine.sh<\/em>, we use:<\/p>\n\n\n
\nlaunchctl setenv PERL5OPT '-Mwarnings;system(\"\/private\/tmp\/migraine.sh\")'\n<\/pre><\/div>\n\n\n
And indeed, after triggering systemmigrationd<\/em> to run perl,<\/em> we were able to bypass SIP:<\/p>\n\n\n
\"Code
Figure 6. Creating an undeletable file due to its SIP protection.<\/figcaption><\/figure>\n\n\n\n
Exploitation approach<\/h3>\n\n\n\n
Triggering migration normally requires using the Migration Assistant utility, which involves a complete sign-out from the system. While this works well for attackers with physical access (hands-on-keyboard), we wished to demonstrate that remote attackers can achieve a SIP bypass using this exploit. Therefore, we decided to research the migration flow and the interplay between the Migration Assistant and systemmigrationd<\/em>.<\/p>\n\n\n\n
Migration is a complicated procedure that involves several components. Here is the flow of key events:<\/p>\n\n\n\n
    \n
  1. Migration Assistant uses a utility called Setup Assistant to help start migration. However, it does so indirectly by using XPC<\/a> between itself and another process called MBSystemAdministration<\/em>. It also signs out by invoking a method named SACLOStartLogoutWithOptions<\/em>.<\/li>\n\n\n\n
  2. The MBSystemAdministration<\/em> utility proxies requests from Migration Assistant to Setup Assistant and also verifies that the caller (Migration Assistant) has the com.apple.private.mbsystemadministration<\/em> entitlement. Otherwise, it refuses serving migration requests. Additionally, MBSystemAdministration<\/em> runs as the hidden user _mbsetupuser<\/em>, which allows migration to perform GUI interactions after sign out.<\/li>\n\n\n\n
  3. Setup Assistant gets requests through MBSystemAdministration<\/em> and performs XPC to several Mach services that are served by the launch daemon systemmigrationd<\/em>. The systemmigrationd<\/em> daemon enforces that the caller (Setup Assistant) has the com.apple.private.systemmigration.daemonclient<\/em> entitlement. Otherwise, it refuses serving migration requests. The systemmigrationd<\/em> daemon uses the private framework SystemMigration.framework<\/em> and listens to new migration requests by invoking a method called startListeningForConnections<\/em>. Interestingly, the daemon examines the contents of the directory \/<\/em>Library\/SystemMigration\/Queue<\/em> (which is protected by SIP)\u2014requests appear as files in that directory. Once a file is dropped, systemmigrationd<\/em> renames the file to \u201cIn-Flight\u201d and serves it, including running required scripts, which can cause perl<\/em> or bash<\/em> to run.<\/li>\n<\/ol>\n\n\n\n
    This complex flow can be illustrated with the following schematic:<\/p>\n\n\n
    \"Flow
    Figure 7. Flow diagram of the macOS migration<\/figcaption><\/figure>\n\n\n
    \"Code
    Figure 8. systemmigrationd <\/em>using the private SystemMigration <\/em>framework to listen to incoming connections<\/figcaption><\/figure>\n\n\n\n
    Our first attempt at automating the exploit focused on patching Migration Assistant to prevent user sign-out:<\/p>\n\n\n
    \"Code
    Figure 9. Reverse engineering the Migration Assistant reveals the SACLOStartLogoutWithOptions <\/em>function,c which signs out<\/figcaption><\/figure>\n\n\n\n
    Simply patching Migration Assistant does not work due to codesign failure. Stripping the binary of signing information results in error (Figure 10) due to a kernel feature related to Pointer Authentication Codes<\/a> (PAC) that\u2019s available for the latest Apple Silicone<\/a> architecture. If an arm64e binary with pointer authentication is not a code-signed platform binary, the kernel prevents execution, as shown in Figure 9. Extracting, stripping, and patching the x64 portion of the multiarchitecture binary<\/a> avoids the arm64e issue, but it\u2019s not functional due to losing the required entitlement (com.apple.private.mbsystemadministration<\/em>).<\/p>\n\n\n
    \"Code
    Figure 10. Pointer Authentication Code requirements<\/figcaption><\/figure>\n\n\n
    \"Code
    Figure 11. Attempting to patch and run the Migration Assistant fails<\/figcaption><\/figure>\n\n\n\n
    After reaching an impasse with patching Migration Assistant, we wondered if we could initiate later stages in the flow diagram, thus avoiding user sign-out. We continued to map and reverse-engineer the system behavior, including using an in-house researcher tool which leverages the Endpoint Security Framework<\/a> that logs all relevant process and file events during migration, inspired by Patrick Wardle\u2019s <\/a>FileMonitor<\/a> and ProcessMonitor<\/a> tools for investigating system behaviors.<\/p>\n\n\n\n
    While mapping the sequence of events for Migration Assistant, MBSystemAdministration<\/em>, Setup Assistant, and systemmigrationd<\/em>, we noticed xpcproxy<\/em> executing Setup Assistant with the argument \u2011MiniBuddyYes<\/em>.<\/p>\n\n\n\n
    Running Setup Assistant with that argument had no effect on the UI layout or its functionality, but it did highlight the usage of arguments within Setup Assistant. Closely examining Setup Assistant, we discovered other interesting command-line arguments:<\/p>\n\n\n
    \"Code
    Figure 12. Setup Assistant’s usage of -MiniBuddyYes<\/em> within useDebugParameters<\/em><\/figcaption><\/figure>\n\n\n\n
    Additionally, we discovered a function called useDebugParameters<\/em> that parses an interesting command-line parameter \u2011MBDebug<\/em>.<\/p>\n\n\n
    \"Code
    Figure 13. Setup Assistant –MBDebug<\/em><\/figcaption><\/figure>\n\n\n\n
    Running the Setup Assistant with the \u2011MBDebug<\/em> parameter results in a successful migration with no sign out. We further used the -ResumeBuddyYes<\/em> parameter in conjunction with \u2011MBDebug<\/em> to automatically skip a few welcome screens.<\/p>\n\n\n
    \"Successful
    Figure 14. Running a migration without signing out<\/figcaption><\/figure>\n\n\n\n
    Since performing migration requires UI interaction, but no sign-out, we used AppleScript to automate the exploit.<\/p>\n\n\n\n
    Our final exploit does the following:<\/p>\n\n\n\n
      \n
    1. Prepares a small 1GB Time Machine backup and attaches it with hdiutil<\/em>.<\/li>\n\n\n\n
    2. Prepares an arbitrary payload that is designed to run without SIP filesystem restrictions.<\/li>\n\n\n\n
    3. Sets the environment variable PERL5OPT<\/em> using launchctl<\/em> to run the payload once perl<\/em> starts.<\/li>\n\n\n\n
    4. Runs Setup Assistant with the -MBDebug<\/em> and -ResumeBuddyYes<\/em> command-line flags.<\/li>\n\n\n\n
    5. Uses AppleScript to automate the Setup Assistant screens to migrate \u201cFrom a Mac, Time Machine backup or Startup disk\u201d, followed by automatically clicking \u201ccontinue\u201d.<\/li>\n<\/ol>\n\n\n\n
      \n\t<\/div>\n\n\n\n
      Implications of arbitrary SIP bypasses<\/h2>\n\n\n\n
      The implications of arbitrary SIP bypasses are serious, as the potential for malware authors is significant. Code that maliciously bypasses SIP could have considerable consequences, such as:<\/p>\n\n\n\n
        \n
      1. Create undeletable malware<\/strong>: The most straight-forward implication of a SIP bypass is that, by assigning files with the com.apple.rootless<\/em> extended attribute (or overriding existing ones), an attacker can create files that are protected by SIP and therefore undeletable by ordinary means. This is quite important for security solutions, such as Microsoft Defender for Endpoint<\/a>, that are required to quarantine malware but cannot quarantine files protected by SIP.<\/li>\n\n\n\n
      2. Expand the attack surface for userland and kernel attacker techniques<\/strong>: As pointed out by Mickey Jin\u2019s blog post<\/a> on a different SIP bypass, it\u2019s possible for attackers to gain arbitrary kernel code execution. As Apple slowly disallows third party kernel extensions and transitions the Mac ecosystem towards their Endpoint Security<\/a> framework, security solutions will no longer be able to monitor the kernel for malicious activity, including malicious code executions.<\/li>\n\n\n\n
      3. Tamper with the integrity of the system, effectively enabling rootkits<\/strong>: This is a derivation of arbitrary kernel code execution\u2014once kernel code execution is established by an attacker, certain rootkit techniques<\/a> are possible, such as hiding processes or files from all monitoring tools. These techniques might also include bypassing tamper protection<\/a>, which is important for Microsoft Defender for Endpoint to protect against threats.<\/li>\n\n\n\n
      4. Full TCC bypass<\/strong>: As pointed out by Mickey Jin\u2019s blog post<\/a> on a different SIP bypass, attackers could replace databases that control Transparency, Consent, and Control (TCC) policies (TCC.db<\/em>), effectively granting arbitrary applications access to private data and peripherals. For further explanation about the implications, we\u2019ve demonstrated a TCC bypass in the past called \u201cPowerdir<\/a>\u201d.<\/li>\n<\/ol>\n\n\n\n
        Hardening device security through collaboration and research-driven protection<\/h2>\n\n\n\n
        Attackers continue to seek new footholds into increasingly secure devices and networks, oftentimes by leveraging unpatched vulnerabilities and misconfigurations to access valuable systems and data. Gaining the ability to bypass SIP and similar security technology in macOS devices can be an attractive and even necessary capability for adversaries. Given SIP\u2019s position as both a device\u2019s built-in baseline protection and the last line of defense against malware and other threats, bypassing SIP can have considerable consequences for users. As such, it\u2019s crucial that we strive to enrich our protection technologies across platforms against such issues through research-driven protection and collaboration with partners, customers, and industry experts.<\/p>\n\n\n\n
        This case displays how collaborative research and responsible vulnerability disclosure informs our comprehensive protection capabilities across platforms to provide organizations a complete picture of their security posture. Microsoft Defender Vulnerability Management<\/a> quickly discovers and remediates such vulnerabilities while Microsoft Defender for Endpoint<\/a> detects and alerts on anomalous device activities, including setting perl<\/em> and bash<\/em> environment variables through the launchctl<\/em> utility, as shown below in Figure 15. Additionally, Defender for Endpoint has similar detections for sensitive file access, including system launch daemons, various sensitive configuration files, and many more.<\/p>\n\n\n
        \"Microsoft
        Figure 15. Microsoft Defender for Endpoint detecting the PERL5OPT <\/em>environment variable being suspiciously set<\/figcaption><\/figure>\n\n\n\n
        This case further emphasizes the need for responsible vulnerability disclosures and expert cross-platform collaboration to mitigate issues such as CVE-2023-32369<\/a>, regardless of the vulnerable device or platform in use. We wish to thank the Apple product security team again for their efforts and responsiveness in addressing the issue.<\/p>\n\n\n\n
        Defending against the evolving threat landscape requires the ability to protect and secure users\u2019 computing experiences, whatever the platform. As cross-platform threats continue to grow, we will continue to share vulnerability discoveries and threat intelligence in addition to working with the security community to improve upon solutions that protect users and organizations each day.<\/p>\n\n\n\n
        Jonathan Bar Or, Michael Pearse, Anurag Bohra<\/em><\/strong><\/strong><\/p>\n\n\n\n
        Microsoft Threat Intelligence Community<\/em><\/p>\n\n\n\n
        References   <\/h2>\n\n\n\n