The Microsoft 365 Defender Research Team released a blog post yesterday describing a newly found macOS vulnerability that can abuse entitlement inheritance in macOS’s System Integrity Protection (SIP) to allow execution of arbitrary code with root-level privilege. The vulnerability is listed as CVE-2021-30892 and has been given the nickname “Shrootless.”

To explain how Shrootless works, we need to review how SIP functions. Introduced back in 2015 with OS X 10.11 El Capitan (and explained in detail on pages eight and nine of our review), SIP attempts to do away with an entire class of vulnerabilities (or at least neuter their effectiveness) by adding kernel-level protections against changing 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 executing a terminal command.

The Shrootless exploit takes advantage of the fact that, while root privilege is no longer sufficient to change important system files, the kernel itself still can—and does—alter protected locations as needed. The most obvious example is when installing an application. Apple-signed application install packages have the ability to do things normally prohibited by SIP, and that’s where Shrootless slides in.

Unintended consequences

As explained by Microsoft Senior Security Researcher Jonathan Bar Or in a blog post, SIP must be able to temporarily grant installer packages immunity from SIP in order to install stuff, and it does this by handing down that temporary immunity through a built-in inheritance system:

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.

That on its own isn’t too terrifying, since on a normal day, there shouldn’t be anything scary forked off of the system_installd daemon. However, as Bar Or’s post notes, some install packages contain post-install scripts, and macOS runs 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, it automatically runs its startup file at /etc/zshenv—and that’s the problem, because if an attacker has previously modified that file, whatever modifications the attacker made are executed by zsh with the com.apple.rootless.install.inheritable entitlement.

Bar Or sums things up thusly:

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 . 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.

Per the CVE, the vulnerability has already been patched 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—which means OS X 10.11 and later—might still be vulnerable, though that likely hinges on whether post-install scripts executed with bash behave the same way they do with zsh.

Bar Or’s blog post does not mention whether Apple paid Microsoft a bug bounty.

https://arstechnica.com/?p=1808830