|
|
Last year, with the release of macOS Catalina, Apple introduced a new technology with the intention of replacing kernel extensions (aka “kexts”). This year, with the forthcoming release of macOS Big Sur, Apple have continued the phasing out of kexts and further developed their alternative technologies. Although kernel extensions will continue to be allowed on macOS Big Sur and possibly later versions of the operating system, SentinelOne fully supports Apple’s move to a “kextless” architecture, and SentinelOne intends to support macOS Big Sur as early as possible after Apple’s public release, and once we ensure the product meets our high standards of protection, quality and performance. In this post, we explain why moving away from kernel extensions is an important development for macOS endpoint security products and describe some of the advantages that the new architecture brings.
What Are Kexts and Why Are They Problematic?
For those unfamiliar, kernel extensions or kexts are a kind of third-party, system-level plug-in that developers can use to provide functionality that is not typically available from “user space”. Examples of such functionality include controlling hardware devices, querying low-level file events, and inspecting network traffic. Moreover, with kexts, developers can tap into kernel-level APIs that are not available to ordinary user-level applications and achieve things like code injection, memory mapping and authentication. With access to the kernel, programs can access data or files from other applications and users.
With such power, kernel extensions have been vital for endpoint security products in the fight against malware, but kernel extensions themselves can, if not developed with great care, cause security issues of their own.
Apple’s own documentation on developing kexts has plenty of warning to this effect, with statements even so bold as this:
As noted, kernel extension programming errors can cause all sorts of problems, from crashing the system to local privilege escalation and data leakage. Moreover, minor changes in kernel APIs can have profound effects on an application’s functionality and performance, even rendering it useless or worse, such as causing kernel panics that bring the entire device down. It’s probably fair to say that few developers really enjoy the added complications of trying to maintain and debug kernel extension code. For these reasons, Apple’s decision to move away from kexts is one both users and developers should welcome and benefit from.
However, without kernel extensions, there would be no access to some of the low-level APIs that security products rely on. Fortunately, from 10.15 onwards, Apple have provided an alternative specifically for vendors of security software: meet the new Endpoint Security Framework.
Introducing Apple’s New Endpoint Security Framework
In order to replace the work done by kernel extensions, Apple introduced System Extensions, Network Extensions and DriverKit in macOS Catalina, along with a framework specifically for security solutions, called – appropriately enough – the Endpoint Security Framework. We won’t get into the thorny details too much, but we do need to scratch the surface a little to understand the benefits (for those interested in a deeper dive, take a look here and here).
Essentially, the Endpoint Security (ES) Framework means that security products can tap into event streams from the kernel without directly interacting with the kernel itself. This alone solves a number of problems. It means that bugs in third-party developer code aren’t going to crash the kernel or the device (just themselves), and more importantly it means malicious code cannot now circumvent system-level protections by abusing access to the kernel itself.
Borrowing from Apple’s recent WWDC 2020 presentation, we can visualize the relationship like this, where the two ES Applications represent 3rd party apps utilizing the Endpoint Security Framework:
© Apple, Inc.
What’s of particular interest in this model is the messages that are passed between the kernel and the third party applications. Apple provides two broad kinds of messages, notifications (NOTIFY events) and authorizations (AUTH events). These effectively allow a security application to receive enriched data from the kernel about other processes and file actions, to perform analysis, and ultimately decide whether to block or allow those actions. It is then the kernel’s responsibility to safely enforce any action requested by the third party application.
Kextless Brings First Class Protection to Fight Malware
Now at this point you might be thinking: well, what’s to stop a malicious process jumping on that bandwagon and using the ES Framework itself to either override or bypass the ES security tool?
First of all, not just any application can request access to the Endpoint Security Framework. With kernel extensions, any registered developer could create and distribute a kext, but the ES Framework is locked down by a specific entitlement that registered developers must request directly from Apple, citing good reasons why their application needs it (SentinelOne was among the first to request and be approved for this entitlement when it initially became available last year). This kind of control means Apple always has an overview of who can actually use the ES Framework and can just as quickly revoke that entitlement should it be abused.
Secondly, security tools that possess the entitlement can also reap other benefits that put them in a better position to detect and block malware on a device. These benefits include the ability to boot before other third-party code via the NSEndpointSecurityEarlyBoot property list key and being protected by the operating system’s own System Integrity Protection features.
This means that malware cannot tamper with the security product just as it cannot tamper with the macOS system itself. Even if running with root privileges, neither a malicious process nor a malicious user would be able to interfere with the security product or unload it’s launchd jobs.
SentinelOne Will Support Kextless on macOS Catalina and Big Sur
SentinelOne is fully committed to supporting Apple’s transition away from kernel extensions and to implementing the Endpoint Security Framework as part of our solution.
Our team has been working tirelessly with Apple’s macOS Big Sur beta builds and, as with last year’s release of macOS Catalina, SentinelOne intends to support macOS Big Sur after Apple’s public release. This support will include an updated, kextless agent that will replace the kernel extension-based solution on macOS 10.15 Catalina and macOS 10.16/11.0 Big Sur.
For SentinelOne customers who are interested in testing our kextless agent prior to public release of macOS Big Sur, we are today announcing a SentinelOne Beta testing program for selected customers. Please contact the Beta support team for details of how to join the program.
Conclusion
As we’ve noted recently, threat actors targeting Mac users continue to invest in learning and understanding the platform, and long gone are the days when the only macOS malware to be found in-the-wild was poorly-coded by malware authors unfamiliar with the details of the operating system. Today, macOS malware threats show that actors use and abuse low-level APIs and are fluent in Apple’s native programming languages, AppleScript, Objective-C and Swift.
With this transition away from kernel extensions and the move to a kextless, ES Framework-based architecture, SentinelOne will continue to stay ahead of all threats targeting macOS and offer best-in-class protection to enterprises with Mac devices in their fleet. If you’d like to find out more about how SentinelOne can protect your enterprise or apply to join our macOS Big Sur Beta program, request a demo or contact the Beta support team today.
