Insider Microsoft releasing security mitigation for Common Log Filesystem (CLFS) to Windows 11 Insiders

Microsoft will soon be releasing a new security mitigation for the Common Log File System (CLFS) to the Windows Insiders Canary channel. In the past five years, 24 CVEs impacting CLFS have been identified and mitigated, making it one of the largest targets for vulnerability research in Windows. Rather than continuing to address single issues as they are discovered, the Microsoft Offensive Research & Security Engineering (MORSE) team has worked to add a new verification step to parsing CLFS logfiles, which aims to address a class of vulnerabilities all at once. This work will help protect our customers across the Windows ecosystem before they are impacted by potential security issues.

CLFS Overview

CLFS is a general-purpose logging service that can be used by software clients running in user-mode or kernel-mode. This service provides the transaction functionality for the Kernel Transaction Manager of the Windows kernel, which Transactional Registry (TxR) and Transactional NTFS (TxF) are built upon. While used in multiple places in the Windows kernel, a public user-mode API is also offered and can be utilized for any application wanting to store log records on the file system.

CLFS stores all log information and log records in a set of files, referred to as a “logfile”, which persists at a user-defined location on the file system. While the logfile is comprised of multiple files, the CLFS driver manages them as a single unit by creating a file handle for the whole set. The logfile is made up of one “Base Log File” (BLF), which holds the necessary metadata for the log, and two or more “container files”, which is where user-supplied log records are stored.

The custom file format used for the logfile is mostly undocumented, however, some high level information about the internal structures can be found at CLFS Stable Storage. Like many binary file formats, the internal data structures are read into memory, mapped to C/C++ structures, and later operated against by application code. For both the CLFS user-mode and kernel-mode API, it is the responsibility of the driver to read, parse, and ensure the validity of the data structures that make up this custom file format.

Attack Surface

It has proven to be a difficult task to validate all data read from the logfile due to the complexity of the data structures and how they are used. Out of the 24 CVE’s reported in the past 5 years, 19 have involved exploiting a logic bug in the CLFS driver caused by improper validation of one of its data structures. Included in these 19 CVEs are vulnerabilities with known exploits, such as CVE-2022-37969, CVE-2023-23376, and CVE-2023-28252. To trigger such a bug, an attacker can utilize the file system API (e.g. CreateFileW and WriteFile) to either craft a new malicious logfile or corrupt an existing logfile.

Mitigation Overview

Instead of trying to validate individual values in logfile data structures, this security mitigation provides CLFS the ability to detect when logfiles have been modified by anything other than the CLFS driver itself. This has been accomplished by adding Hash-based Message Authentication Codes (HMAC) to the end of the logfile. An HMAC is a special kind of hash that is produced by hashing input data (in this case, logfile data) with a secret cryptographic key. Because the secret key is part of the hashing algorithm, calculating the HMAC for the same file data with different cryptographic keys will result in different hashes.

Just as you would validate the integrity of a file you downloaded from the internet by checking its hash or checksum, CLFS can validate the integrity of its logfiles by calculating its HMAC and comparing it to the HMAC stored inside the logfile. As long as the cryptographic key is unknown to the attacker, they will not have the information needed to produce a valid HMAC that CLFS will accept. Currently, only CLFS (SYSTEM) and Administrators have access to this cryptographic key.

Anytime CLFS wants to make a modification to a logfile, such as adding a new log record to a container file or updating its metadata in the BLF, a new HMAC will need to be calculated using the contents of the entire file. Modifications to logfiles occur frequently, so it would be infeasible for CLFS to be repeatedly reading the file for HMAC calculation anytime a modification occurs, especially since CLFS container files can be upwards to 4GB in size. To reduce the overhead required for maintaining a HMAC, CLFS utilizes a Merkle tree (also known as a hash tree), which drastically lowers the amount of file reading needed to be done whenever a new HMAC needs to be calculated. While the Merkle tree makes HMAC maintenance feasible, it requires additional data to be stored on the file system. Refer to the “User Impact” section of this article for estimates on the storage overhead introduced by this mitigation.

Mitigation Adoption Period / Learning mode

A system receiving an update with this version of CLFS will likely have existing logfiles on the system that do not have authentication codes. To ensure these logfiles get transitioned over to the new format, the system will place the CLFS driver in a “learning mode”, which will instruct CLFS to automatically add HMACs to logfiles that do not have them. The automatic addition of authentication codes will occur at logfile open and only if the calling thread has write access to the underlying files. Currently, the adoption period lasts for 90 days, starting from the time in which the system first booted with this version of CLFS. After this 90-day adoption period has lapsed, the driver will automatically transition into enforcement mode on its next boot, after which CLFS will expect all logfiles to contain valid HMAC. Note that this 90-day value may change in the future.

For new installs of Windows, CLFS will start in enforcement mode, as we do not expect there to be any existing logfiles that need to be transitioned over to the new format.