Andreus / Getty Images
The Microsoft 365 Defender Research Team released a blog post yesterday detailing a newly found macOS vulnerability that could exploit the rights inheritance in macOS’s System Integrity Protection (SIP) to allow execution of arbitrary code with root privileges. The vulnerability is listed as CVE-2021-30892 and has been nicknamed “Shrootless”.
To explain how Shrootless works, let’s take a look at how SIP works. Introduced in 2015 with OS X 10.11 El Capitan (and explained in detail on pages eight and nine of our review), SIP attempts to eliminate an entire class of vulnerabilities (or at least neutralize their effectiveness) by adding kernel-level protection. against modifying certain files on disk and certain processes in memory, even with root privilege. These protections are (more or less) inviolable unless one disables SIP, which cannot be done without rebooting into recovery mode and running a terminal command.
The Shrootless exploit takes advantage of the fact that while root privileges are no longer enough to modify important system files, the kernel itself can still – and will – change secure locations as needed. The most obvious example is when installing an application. Apple-signed application installation packages have the ability to do things normally prohibited by SIP, which is where Shrootless comes in handy.
Unintended Consequences
As explained by Microsoft Senior Security Researcher Jonathan Bar Of in a blog post, SIP needs to be able to grant installation packages temporary immunity from SIP in order to install things, and it does this by passing that temporary immunity through a built-in inheritance system:
While reviewing macOS processes entitled to bypass SIP protections, we came across the daemon system_installdwho has the powerful com.apple.rootless.install.inheritable straight. With this right, any child trial of system_installd could bypass the limitations of the SIP file system altogether.
That in itself is not at terrifying, because on a normal day there shouldn’t be anything scary about the system_installd demon. However, as Bar Or’s post points out, some installation packages contain post-install scripts, and macOS executes those post-install scripts by spawning an instance of the default system shell, which, as of Catalina, is zsh. When a zsh instance is spawned by the installer, the startup file is automatically run on /etc/zshenv-and that’s the problem, because if an attacker has previously modified that file, all the changes the attacker made will be executed by zsh with the com.apple.rootless.install.inheritable straight.
Bar Of sums things up like this:
Generally, zshenv can be used as follows:
- A persistence mechanism. It can just wait for zsh to start (either globally under /and so forth or per user).
- An increase in privilege mechanism. The home directory does not change when an admin user goes to root with sudo -s or sudo
† So, placing a ~/.zshenv file as the administrator and wait for the administrator to use it sudo later would activate the ~/.zshenv file, so elevate it to root.
According to the CVE, the vulnerability has already been fixed in all three currently supported versions of macOS (Monterey 12.0.1, Catalina with security update 2021-007, and Big Sur 11.6.1). Older unsupported versions of OS X with SIP – meaning OS X 10.11 and above – may still be vulnerable, though that probably depends on whether post-install scripts run with bash behave the same as with zsh .
Bar Or’s blog post does not mention whether Apple paid Microsoft a bug bounty.