CrowdStrike and kernel-level access: a deep dive

The CrowdStrike incident in July 2024, where a faulty software update led to the fateful Blue Screen of Death (BSOD) affecting around 8.5 million Windows systems around the world, has once again brought to light the critical issue of kernel-level access for security vendors and reignited debates surrounding the necessity and risks of granting such privileged access.

Understanding the kernel

The kernel is the core component of an operating system, responsible for controlling and managing access to hardware resources, processes, and memory. It acts as a bridge between the critical system resources and the applications running on the system.

Kernel-level access grants a program or process the ability to interact directly with the kernel and resources, bypassing the usual security restrictions. To perform its functions efficiently, the kernel requires a high level of control and privileges. As the kernel is closest to the hardware resources, it is able to monitor all interactions between applications and the system resources and to detect when abnormal behaviour is occurring.

As writing kernel-level code is complex and requires a deep understanding of the operating system's internals, most applications can achieve their goals without direct kernel access by using approaches such as operating system application programming interfaces (APIs) which interact with the system in a controlled and secure manner. These APIs abstract away the complexities of the kernel, making it easier for developers to write applications without needing to understand the underlying kernel mechanisms.

It is normally best to avoid kernel-level access unless it's absolutely necessary, as it can introduce significant risks and complexities. If an application can achieve its goals using APIs or other mechanisms, it's generally preferable to do so. However there are a few scenarios where kernel-level access may be necessary:

• Device drivers: device drivers, which control specific hardware devices, often require kernel-level access to communicate directly with the hardware
• Virtualisation: virtualisation software, which allows multiple operating systems to run on a single physical machine, typically requires kernel-level access to manage the allocation of resources between the virtual machines
• Performance optimisation: in some cases, kernel-level optimisations can be used to improve the performance of certain applications

Why security vendors need kernel-level access

A number of security solutions, such as antivirus programs or intrusion detection systems, often need kernel-level access to monitor system activity at a granular level and detect threats, and to implement effective protection mechanisms for the system. By operating at the kernel level, and seeing all of the interactions between applications and the resources protected by the kernel, the solution is able to better detect and prevent malicious activity from occurring.

Typical security solutions with kernel access include:

• Network security solutions
• Real-time threat detection
• File system monitoring

Microsoft's approach to kernel access

Historically, Microsoft has been much more permissive than other operating systems when it comes to granting kernel-level access to third-party vendors.

This open approach has been driven by several factors:

• Ecosystem development: Microsoft has encouraged the development of an ecosystem of third-party software developers, and kernel-level access has been seen as a necessary tool for creating innovative solutions for many Windows users
• Security market: Microsoft has recognised the importance of a robust security market and has sought to attract leading security vendors to its platform
• Trust in partners: Microsoft has generally trusted its partners to develop and distribute secure kernel-level software

While granting kernel-level access to third-party vendors can provide significant benefits, it also carries inherent risks:

• Privilege escalation: if a security solution is compromised, an attacker could potentially gain privileges, allowing them to take control of the system
• Performance impact: if the solution is poorly designed or resource-intensive, the software can have a negative impact on system performance
• Compatibility issues: the software may not be compatible with all hardware or software configurations, leading to stability problems or system crashes
• Data theft: an attacker with kernel-level access could potentially steal sensitive data directly from the system's memory
• System instability: kernel-level access can introduce instability if not implemented carefully, potentially leading to crashes or performance issues

It is the last issue which resulted in the CrowdStrike incident.

Linux and macOS: a different approach

Unlike Microsoft, Linux and macOS operating systems have generally adopted the ‘walled garden’ approach, a more restrictive approach to kernel-level access, restricting it to a limited number of trusted modules.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

This requires third-party software to be signed by a trusted authority before it can be loaded into the kernel. While this reduces the risk of privilege escalation and data theft, it can also limit the capabilities of security solutions.

Although Microsoft doesn’t adopt this approach, it has been gradually implementing measures to limit kernel access through the various releases of Windows:

• Digital signatures: introduced in Windows XP requiring all drivers to be digitally signed by a trusted certification authority
• Windows Driver Model: became the standard for driver development in Windows 2000
• User Account Control: introduced in Windows Vista
• Secure boot: became available in Windows 8
• Windows Defender System Guard: introduced in Windows 10

While kernel-level access is often considered essential for certain security solutions, there are some possible alternatives:

• User-mode hooks: similar functionality can sometimes be achieved by using these to intercept system calls or API functions
• Hypervisors and sandboxing: these operate at a lower level than the operating system but provide a controlled environment which is isolated from the host system

Conclusions

The CrowdStrike incident has once again raised important questions about the risks and benefits of kernel-level access for security vendors. While it is clear that this approach can provide significant value, it is also essential to carefully consider the potential risks and take steps to mitigate them.

Kernel-level access for security vendors is a complex issue with no easy answers. While it is often necessary, it also carries significant risks. The recent CrowdStrike incident serves as a reminder of the importance of careful oversight and regulation in this area. As the security landscape continues to evolve, it is likely that new approaches and technologies will emerge, offering alternative ways to achieve the same goals without the same level of risk.