Apple’s new Secure Kernel Extension Loading (SKEL) security feature, set to be implemented in the upcoming macOS 10.13 High Sierra, can be easily bypassed, a security researcher claims.
The issue, according to Patrick Wardle, Chief Security Researcher at Synack, is with the current implementation of the feature, which does almost nothing to stop hackers or malware, although it does hamper the efforts of third-party macOS developers such as those that design security products.
According to Wardle, while SKEL is designed to counter the direct loading of malicious kernel extensions such as rootkits, no signed kernel-mode macOS malware has emerged to date.
“Since OS X Yosemite, any kexts have to be signed with a kernel code-signing certificate. And unlike user-mode Developer IDs, Apple is incredibly ‘protective’ of such kernel code-signing certificates – only giving out a handful to legitimate 3rd-party companies that have justifiable reasons to create kernel code,” he points out.
Thus, SKEL’s main goal would be to block the loading of legitimate but (known) vulnerable kexts, given that attackers can exploit them to gain arbitrary code execution within the context of the kernel. Apple can blacklist these vulnerable kexts via the OSKextExcludeList dictionary, but the operation is often delayed, because it can break functionality until the user has upgraded to a non-blacklisted version of the kext.
According to Wardle, the exploitable kernel heap-overflow in Little Snitch’s kernel driver that he discovered last year, can be abused by a local privileged attacker to bypass macOS’s kernel code-signing requirements.
An attacker with root privileges can load a vulnerable copy of the LittleSnitch.kext (versions earlier than 3.61), which would be allowed, given that the vulnerable driver is still validly signed, and then exploit the heap-overflow to gain arbitrary code execution within the kernel. Next, the attacker can bypass system integrity protection (SIP), load unsigned kexts, and perform other nefarious operations.
SKEL can block the direct loading of maliciously signed kexts, but it is mainly designed to “thwart the loading of known vulnerable drivers for malicious purposes,” Wardle claims. Thus, when a signed third-party kernel extension is loaded on High Sierra for the first time, SKEL blocks it and alerts the user. The user, however, can manually approve the (signed) kernel extension to load.
However, the blocking doesn’t happen if the kernel extension was “already installed at the time of upgrading to macOS High Sierra,” if it is signed with the same Team ID as a previously approved extension, is “replacing a previously approved extension,” or is being loaded on a Mac that is enrolled with an MDM solution.
The researcher discovered that, when blocking the kext and alerting the user, the system policy daemon accesses a ‘kernel policy’ database, and notes that this is what tells SKEL to block or allow the loading. Due to an implementation vulnerability in SKEL, Wardle was able to load a new unapproved kext, without user interaction.
Wardle didn’t provide technical details on the vulnerability as of now, but did publish a demo of a full SKEL bypass. He says that High Sierra’s SKEL’s flawed implementation is a perfect example of how new security features can often just complicate the lives of third-party developers.
“Of course though, as attackers we have the easier job – a single implementation flaw in SKEL may allow us to fully bypass it. Apple on the other hand, has to protect against everything,” the researcher points out.
