Microsoft finds new macOS vulnerability, Shrootless, that could bypass System Integrity Protection
Microsoft has discovered a vulnerability that could allow an attacker to bypass System Integrity Protection (SIP) in macOS and perform arbitrary operations on a device. We also found a similar technique that could allow an attacker to elevate their privileges to root an affected device. We shared these findings with Apple through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). A fix for this vulnerability, now identified as CVE-2021-30892, was included in the security updates released by Apple on October 26, 2021.
SIP is a security technology in macOS that restricts a root user from performing operations that may compromise system integrity. We discovered the vulnerability while assessing processes entitled to bypass SIP protections. We found that the vulnerability lies in how Apple-signed packages with post-install scripts are installed. A malicious actor could create a specially crafted file that would hijack the installation process. After bypassing SIP’s restrictions, the attacker could then install a malicious kernel driver (rootkit), overwrite system files, or install persistent, undetectable malware, among others.
This OS-level vulnerability and others that will inevitably be uncovered add to the growing number of possible attack vectors for attackers to exploit. As networks become increasingly heterogeneous, the number of threats that attempt to compromise non-Windows devices also increases. Microsoft Defender for Endpoint on Mac enables organizations to gain visibility and detect threats on macOS devices. Such visibility rolls up to Microsoft Defender for Endpoint, which provides organizations with a “single pane of glass” where they can detect, manage, respond, and remediate vulnerabilities and threats across different platforms.
In this blog post, we will share some information about SIP, examine the common types of SIP bypasses previously disclosed, and present the unique ones we discovered.
SIP overview
First introduced by Apple in macOS Yosemite, SIP—also known as “rootless”—essentially locks down the system from root by leveraging the Apple sandbox to protect the entire platform. Internally, it is controlled by the following NVRAM variables:
- csr-active-config: bitmask of enabled protections
- csr-data: stores netboot configuration
These variables cannot be legitimately modified in non-recovery mode. Therefore, the only legitimate way to disable SIP is by booting into recovery mode and turning SIP off. Turning SIP on or off is done using the built-in csrutil tool, which can also display the SIP status:
Figure 1: csrutil showing the SIP status. Note that SIP cannot be disabled from non-recovery OS.
The csr-active-config bitmask NVRAM variable describes the different protections SIP offers. While not an exhaustive list, below are a few honorable mentions; the rest can be freely examined in the XNU source code:
| csr-active-config NVRAM bit | Description |
| CSR_ALLOW_UNTRUSTED_KEXTS | Controls the loading of untrusted kernel extensions |
| CSR_ALLOW_UNRESTRICTED_FS | Controls write access to restricted filesystem locations |
| CSR_ALLOW_TASK_FOR_PID | Controls whether to allow getting a task port for Apple processes (that is, invoke the task_for_pid API) |
| CSR_ALLOW_UNRESTRICTED_NVRAM | Controls unrestricted NVRAM access |
| CSR_ALLOW_KERNEL_DEBUGGER | Controls whether to allow kernel debugging |
Compromising any of these protections could enable attackers to bypass SIP completely. Some scenarios include the following:
- Loading untrusted kernel extensions could compromise the kernel and allow the said extensions to perform operations without any checks
- Bypassing filesystem checks could allow a kernel extension to enforce SIP to itself completely
- Freely modifying the NVRAM could control SIP itself
Filesystem restrictions
Over the years, Apple has hardened SIP against attacks by improving restrictions. One of the most notable SIP restrictions is the filesystem restriction. This is especially important for red teamers and malicious actors, as the amount of damage one can do to a device’s critical components is directly based on their ability to write unrestricted data to disk.
The file /System/Library/Sandbox/rootless.conf generally controls which files are SIP-protected. While the said file itself is also SIP-protected, one can run it using ls with the -O flag to list which files are similarly protected. SIP-protected files have the “restricted” marker.
Figure 2: Listing /usr with the -O option. /usr/local is not SIP protected, but /usr/sbin is.
Files with the extended attribute com.apple.rootless are likewise SIP-protected. Of course, there’s no way to add that extended attribute to a file legitimately. Otherwise, malware could use SIP for its own protection. The filesystem restrictions are a great way of restricting attackers. For instance, many of the /System directory and its subdirectories are SIP-protected.
Figure 3: SIP blocking a malicious LaunchDaemon registration that is frequently used for persistence.
Rootless entitlements
Since the filesystem restrictions are so powerful, Apple must consider a few exceptional cases. For example, system updates require unrestricted access to SIP-protected directories. Therefore, Apple introduced a particular set of entitlements that bypass SIP checks by design. These entitlements are fine-tuned to specific SIP checks, and only Apple can assign them. So naturally, Apple only assigns these entitlements to its processes.
In our research, we focused on two powerful entitlements, which have also been targets of vulnerability hunters:
| Entitlement | Description |
| com.apple.rootless.install | Completely bypasses SIP filesystem checks |
| com.apple.rootless.install.inheritable | Inherits com.apple.rootless.install to child processes |
Figure 4: An example of a “com.apple.rootless.install” entitled process
A quick rundown of notable SIP bypasses
Before our discovery, there had been several interesting SIP bypass vulnerabilities already reported in the past. In this section, we categorize these vulnerabilities into several classes and provide an example for each. Note that this is not a complete list; for instance, we excluded vulnerabilities involving the kernel itself because SIP only protects userland.
Abusing dynamic libraries
Previously, entitled processes could still load arbitrary dynamic libraries. One such example was presented in 2016, where libBaseIA.dylib, which is local to the app, was used by an entitled binary and could be infected with malicious code. At that point, the SIP bypass could be completely implemented in the malicious dylib.
Mounting
In a security update for OSX 10.11.2, Apple fixed a security bug that was also abused by the MacDefender malware. The said vulnerability could allow a malicious .dmg file to be mounted (using hdiutil) over a SIP-protected folder, therefore completely bypassing SIP filesystem restrictions.
Abusing entitlements
Entitled processes have also been sources of security bypasses. One notable example is a bypass that used the entitled fsck_cs utility. The bypass exploited the fact that fsck_cs would follow symbolic links and attempt to fix the filesystem presented to it.
Therefore, an attacker could create a symbolic link pointing from /dev/diskX to /System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist and invoke fsck_cs on the former. As the Info.plist file gets corrupted, the operating system could no longer control kernel extension exclusions, therefore bypassing SIP.
The ‘Shrootless’ vulnerability
While assessing macOS processes entitled to bypass SIP protections, we came across the daemon system_installd, which has the powerful com.apple.rootless.install.inheritable entitlement. With this entitlement, any child process of system_installd would be able to bypass SIP filesystem restrictions altogether.
Figure 5: system_installd entitlements. Note the “com.apple.rootless.install.inheritable”
Since Microsoft Defender for Endpoint has a post-breach component, we decided to examine all the child processes of system_installd. To our surprise, we saw a few cases that could allow attackers to abuse its functionality and bypass SIP.
For instance, when installing an Apple-signed package (.pkg file), the said package invokes system_installd, which then takes charge of installing the former. If the package contains any post-install scripts, system_installd runs them by invoking a default shell, which is zsh on macOS. Interestingly, when zsh starts, it looks for the file /etc/zshenv, and—if found—runs commands from that file automatically, even in non-interactive mode. Therefore, for attackers to perform arbitrary operations on the device, a fully reliable path they could take would be to create a malicious /etc/zshenv file and then wait for system_installd to invoke zsh.
To create a fully functional proof-of-concept (POC) exploit, we implemented the following algorithm:
- Download an Apple-signed package (using wget) that is known to have a post-install script
- Plant a malicious /etc/zshenv that would check for its parent process; if it’s system_installd, then it would write to restricted locations
- Invoke the installer utility to install the package
As seen in Figure 6 below, the POC exploit was able to override the kernel extension exclusion list:
Figure 6: Our POC exploit overriding the kernel extension exclusion list with arbitrary data
zshenv as an attack technique
During our research, we also found out that zshenv could also be used as a general attack technique besides being used for a SIP bypass. We discovered that /etc/zshenv has an equivalent for each user profile under ~/.zshenv, which has the same function and behavior but doesn’t require root permissions to write to.
Generally, zshenv could be used as the following:
- A persistence mechanism. It could simply wait for zsh to start (either globally under /etc or per user).
- An elevation of privilege mechanism. The home directory doesn’t change when an admin user elevates to root using sudo -s or sudo <command>. Thus, placing a ~/.zshenv file as the admin and waiting for the admin to use sudo later would trigger the ~/.zshenv file, hence elevating to root.
We shared our findings to Apple through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). We want to thank the Apple product security team for their professionalism and responsiveness in fixing the issue.
Hardening device security through vulnerability management and behavioral monitoring
Security technology like SIP in macOS devices serves both as the device’s built-in baseline protection and the last line of defense against malware and other cybersecurity threats. Unfortunately, malicious actors continue to find innovative ways of breaching these barriers for these very same reasons. They can take complete control of the device and run any files or processes they wish without getting detected by traditional security solutions.
Our research on the CVE-2021-30892 vulnerability exemplifies this. It highlights the need for organizations to have a security solution like Microsoft Defender for Endpoint that empowers them to quickly discover and remediate vulnerabilities through threat and vulnerability management. This allows defenders to detect vulnerabilities and misconfigurations on devices in real time and prioritize which need to be addressed immediately based on the threat landscape, business context, and other factors.
In addition, Microsoft Defender for Endpoint uses advanced behavioral analytics and machine learning to detect anomalous activities on a device, such as overwriting arbitrary SIP-protected files that our POC exploit is capable of. In the example provided in the previous section, it is anomalous for zsh to override the kernel extension exclusion list. As such, Defender for Endpoint detects it. Extending the concept, Defender for Endpoint has similar detections for sensitive file access, including system launch daemons, the rootless.conf file, and many more.
Finally, this research underscores the importance of collaboration among security researchers, software vendors, and the larger security community. As cross-platform threats continue to increase, vulnerability discoveries, coordinated response, and other forms of threat intelligence sharing help enrich our protection technologies that secure users’ computing experience regardless of the platform or device they’re using.
Jonathan Bar Or
Microsoft 365 Defender Research Team
READ MORE HERE
