This article is more than 1 year old
Shrootless: Microsoft found a way to evade Apple's SIP macOS filesystem protection
Flaw could have let miscreants slide rootkits onto your iDesktop
A vulnerability in MacOS that could let a malicious person install rootkits on Apple Macs has been patched, following its discovery and disclosure by Microsoft.
Tracked as CVE-2021-30-892, the vuln existed in MacOS' System Integrity Protection (SIP) feature. An Apple software installation daemon called system_installd allowed its child processes to bypass SIP's normal restrictions on filesystem access.
Unleashed on world+dog with 2015's El Capitan release, MacOS SIP is intended to ensure that system-level files on a Mac can only be modified by Apple-signed installers or the fruity firm's own update mechanism – locking out even root users. The idea is to prevent malware or malicious users who obtain root privileges from compromising the operating system, perhaps to install a rootkit or simply to trash it and deny users from accessing the device at all.
"We found that the vulnerability lies in how Apple-signed packages with post-install scripts are installed," said Microsoft in a blog post about its discovery.
"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."
SIP, in Microsoft's explanation, prevents root-privileged users from "performing operations that may compromise system integrity," although exceptions exist. One of those exceptions, naturally enough, is operating system updates. Copying new files into SIP-protected directories means having the ability to bypass SIP, implemented as two specific permissions.
One of those permissions, com.apple.rootless.install.inheritable, applied to the system_installd daemon, meaning its child processes could also completely bypass SIP. Microsoft found that Apple-signed installer packages (.pkg files) are executed by system_installd - and the daemon runs any post-installation scripts in the package with zsh. By default, Redmond's researchers reckoned that zsh on MacOS automatically runs commands from the file /etc/zshenv: "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."
- Bad news, AMD fans: This week's Windows 11 update didn't fix your performance woes (they may be worse)
- These couldn't wait for Patch Tuesday: Adobe issues bonus fixes for 92 security holes in 14 products
- Microsoft Patch Tuesday bug harvest festival comes to town
- Windows XP@20: From the killer of ME to banging out patches for yet another vulnerability
Jake Moore, a cybersecurity specialist at antivirus firm ESET, told The Register that if the vuln had been exploited in the wild (for which there's no evidence yet,) the outcomes could have been rather bad.
“It doesn’t get much more worrying than allowing an attacker to elevate their privileges to root an affected device," he said. "Installing a rootkit is something that Microsoft would be most fearful of and even embarrassed by hence the speedy response and requests to patch. As worrisome as it may be, the amount of attack vectors mounting up simply offers more reasons for users to make sure their devices are constantly up to date."
SIP has been a feature of MacOS going back to 2015 – and, thanks to the powerful privileges it exposes, has been a feature of security research. Back in 2018 an irritated chap discovered that SIP prevented him from fully deleting an Android emulator, while further back in time Apple was forced to patch SIP after a crafty person published a sub-140-character proof-of-concept that overwrote an OS X configuration file, in defiance of SIP.
Just for good measure, in 2019 Google had to halt a routine Chrome update after irate users found that on systems without SIP (i.e. had it disabled or pre-dated its release) the update would delete a crucial symbolic link needed by MacOS. No symlink, no boot. ®