Microsoft's Response to Kernel Access: Ensuring Safe Deployments Post-CrowdStrike Incident

 

Microsoft’s Perspective on Kernel Access and Safe Deployment After the CrowdStrike Incident

Overview of the CrowdStrike Incident

In February 2024, CrowdStrike launched a new InterProcess Communication (IPC) Template Type with its Falcon sensor version 7.1, introducing 21 input fields. Their rapid response mechanism utilizes content delivered via Channel Files. However, the interpreter for Channel File 291 only accounted for 20 values. On July 19, 2024, when two additional IPC Template Instances were deployed, the attempt to access the 21st value led to an out-of-bounds memory read, ultimately causing system crashes.

David Weston, Microsoft’s VP of Enterprise and OS Security, emphasized that Microsoft, in this case, was a victim. The CrowdStrike kernel driver had passed rigorous evaluation and was signed by Microsoft’s Windows Hardware Quality Labs (WHQL). The problem arose from the external content sent to the driver, not the driver itself.

Weston stated, “That’s something Microsoft would never have seen. It traversed Microsoft. It’s not documented. Microsoft doesn’t know what’s in that file. It’s a binary code that only CrowdStrike knows how to interpret.”

The MVI Summit: Addressing Key Issues

In response to the incident, Microsoft convened the MVI summit on September 10, 2024, to discuss lessons learned and strategies to prevent similar occurrences in the future. The summit focused on two critical areas: kernel access and safe software deployment practices.

Kernel Access: Balancing Benefits and Risks

The advantages of third-party drivers operating within the kernel are evident—enhanced security and performance. However, Weston noted the inherent risks: “If you crash in the kernel, you take down the whole machine. If you crash an app in user mode, we can generally recover it.” This highlights the need to consider minimizing kernel mode usage in favor of user mode for greater stability.

Concerns were raised about potential restrictions on kernel access for third-party vendors. ESET, one of the summit participants, expressed the importance of maintaining kernel access for cybersecurity products. In response, Weston reassured attendees, stating that there are currently no plans to revoke kernel access but emphasized the goal of developing comparable options for user mode.

The Importance of Safe Deployment Practices (SDP)

While kernel access remains a focal point, Weston underscored the larger issue of effective software testing and deployment. He noted that “whether your security product is in the kernel or operating as an app, you can still destroy the machine or make it unavailable.” This reinforces the necessity of Safe Deployment Practices (SDP) to prevent operational failures.

The concept of SDP isn’t new; concerns about existing deployment systems have been discussed for decades. Weston pointed to the need for structured SDPs to facilitate safer updates across the diverse Windows ecosystem. “A core SDP principle is gradual and staged deployment of updates sent to customers,” he remarked, emphasizing collaboration among MVI partners to establish best practices.

Ensuring Compliance Among Partners

Agreeing on a set of safe deployment practices is one thing, but enforcing compliance is another challenge. Weston acknowledged the difficulties of technical enforcement but highlighted the importance of transparency and accountability. Microsoft can withdraw the signing of kernel drivers from partners who fail to adhere to agreed-upon SDPs, similar to how it collaborates with root certificate authorities.

Weston concluded, “SDP is the best tool we have in the toolbox for stopping outages. Kernel mode, user mode—these are not invalid concerns, but they are a smaller part of the problem. SDP can help prevent outages both inside and outside of the kernel.”