How Much Code Does Anti-Malware Software Push Into Kernel Mode?

Table of contents

??Nature of the topic

??The results of the study

??References

??Appendix

Nature of the topic

The recent CrowdStrike incident has raised concerns about the necessity of involving Windows drivers in antivirus, anti-malware (AM) and EDR products. Whilst IT pros and security experts know that any serious Windows AM solution can't function without drivers, this industry practice remains a mystery to ordinary users.

In July of this year CrowdStrike, a renowned cybersecurity company with tens of millions of customers worldwide, released an update for one of its drivers, which caused a BSoD on all Windows machines running their brand EDR solution, Falcon. This update pertained to a so-called rule file intended for parsing by the core Falcon driver named CSAgent.sys. The rule files incorporate bytecode to be executed by a VM engine implemented in CSAgent. An error in dispatching bytecode led to the notorious mass crash.

This architectural solution of executing instructions from supplied files in kernel mode is reminiscent of an old antivirus practice of operating an AV engine directly in kernel mode. Despite its performance advantages, this method raises serious concerns regarding reliability and security. Antivirus engines include powerful PE parsers, unpackers, and emulators, which can cause memory addressing errors when dealing with malformed executables. Compared to AV engines, the bytecode execution engine from CSAgent receives only trusted input in the form of rule files in a proprietary format. It also has more limitations on code execution, not allowing the bytecode to access memory by absolute addresses.

Unfortunately, a simple error in one of the rule files could have a severe impact. If this VM engine had operated in a Falcon's user mode process, it could have been simply restarted without affecting stability of the entire system. AM manufacturers switched to loading the AV engine into a separate user mode process instead of kernel mode long ago. Therefore, when the information about the cause of the CSAgent crash emerged, it was an unpleasant surprise, raising concerns about similar problems in the future.

Historically, Windows antiviruses required at least one Windows driver to implement on-access scan (OAS) protection also known as file monitor. The core component of any file monitor is the File System Filter Driver (FSD Filter), which monitors access to files at a low level and can block access if the files contain malicious code. As the Windows ecosystem evolved, antiviruses expanded the number of protection features to respond to the changing threat landscape. Today, the following components of classic anti-malware products are based on drivers: OAS, firewall, HIPS or application control, web protection, and rootkit protection.

The results of the study

To be honest, the statistics below actually reflects nothing... and is purely informative in nature. In fact, there's no direct correlation between the number of Windows drivers of the specified AM product and potential negative impact for the entire system. It depends more on the quality of the drivers' code and updates than on their number. The information below doesn't provide any specific details about the purpose of the drivers. I've taken only consumer AM products with the exception of CrowdStrike Falcon EDR.

By summing up the size of all drivers for each product, we can get the following statistics.

Each tested product includes the following number of drivers.

If you want to read more about the history of the topic, you might want to check out my earlier post.

References

Tech Analysis: CrowdStrike’s Kernel Access and Security Architecture

https://www.crowdstrike.com/blog/tech-analysis-kernel-access-security-architecture/

Appendix

Tested products:

Kaspersky 21.3.10.391, Trend Micro Internet Security 17.8, CrowdStrike Falcon, McAfee Total Protection 16.0, ESET Smart Security 17.2.7.0, Norton Antivirus 22.20.5.39, Avast Premium Security 24.7.9311.0