Security mitigation for the Common Log Filesystem (CLFS)

Microsoft will soon be releasing new security mitigations. Common Log File System (CLFS) Windows Insiders Canary Channel. Over the past five years, 24 CVEs affecting CLFS have been identified and mitigated, making it one of the largest targets of vulnerability research on Windows. Rather than continue to address single issues as they are discovered, the Microsoft Offensive Research & Security Engineering (MORSE) team has added a new validation step that parses CLFS log files, with the goal of addressing the entire class of vulnerabilities at once. This work will help protect customers across the Windows ecosystem before they are affected 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. It provides transactional capabilities for: Kernel Transaction Manager It is the foundation upon which the Windows kernel’s Transactional Registry (TxR) and Transactional NTFS (TxF) are built. It is used in many places in the Windows kernel, but it also provides a public user-mode API and can be utilized by any application that wants to store log records in the file system.

CLFS stores all log information and log records in a set of files called “log files”, which are persisted in a user-defined location on the file system. A log file consists of multiple files, but the CLFS driver creates a file handle for the entire set and manages it as a single unit. A log file consists of one “base log file” (BLF), which holds the metadata required for the log, and two or more “container files”, which store user-supplied log records.

The custom file formats used for log files are largely undocumented, but some advanced information about their internal structure can be found at: CLFS Stable Storage. As with many binary file formats, the internal data structures are read into memory, mapped to C/C++ structures, and later operated on by application code. In both the CLFS user-mode and kernel-mode APIs, the driver is responsible for reading, parsing, and validating the data structures that make up this custom file format.

Attack Surface

Due to the complexity of the data structures and how they are used, validating all data read from the log files has proven to be a difficult task. Of the 24 CVEs reported in the last five years, 19 involved exploiting logic bugs in the CLFS driver that were caused by improper validation of one of the data structures. These 19 CVEs contained vulnerabilities with known exploits. CVE-2022-37969, CVE-2023-23376and CVE-2023-28252. To trigger these bugs, an attacker must exploit a file system API (e.g. CreateFileW and Write file) creates a new malicious log file or corrupts an existing log file.

Relief Overview

Instead of validating individual values ​​in the log file data structure, this security mitigation provides CLFS with the ability to detect when a log file has been modified by something other than the CLFS driver itself. This is achieved by adding a Hash-based Message Authentication Code (HMAC) to the end of the log file. An HMAC is a special kind of hash that is generated by hashing the input data (in this case, the log file data) with a secret encryption key. Since the secret key is part of the hashing algorithm, computing an HMAC on the same file data with a different encryption key will produce a different hash.

Just as you can verify the integrity of a file downloaded from the Internet by checking its hash or checksum, CLFS can verify the integrity of a log file by computing its HMAC and comparing it to the HMAC stored inside the log file. Without knowing the encryption key, an attacker cannot obtain the information necessary to generate a valid HMAC that CLFS accepts. Currently, only CLFS (SYSTEM) and administrators have access to this encryption key.

Whenever CLFS wants to modify a log file, such as by adding a new log record to the container file or updating metadata in the BLF, it must compute a new HMAC using the contents of the entire file. Since modifications to log files occur frequently, it is impractical for CLFS to repeatedly read the file to compute the HMAC every time a modification occurs, especially since CLFS container files can be up to 4 GB in size. To reduce the overhead required to maintain the HMAC, CLFS Merkle tree (also known as a hash tree) greatly reduces the amount of file reads that must be performed each time a new HMAC needs to be computed. A Merkle tree enables HMAC maintenance, but requires additional data to be stored on the file system. For an estimate of the storage overhead caused by this mitigation, see the “User Impact” section of this document.

Relaxation adoption period/learning mode

Systems receiving updates to this version of CLFS will likely have legacy log files on the system that lack authentication codes. To allow these log files to transition to the new format, the system switches the CLFS driver into “learning mode”, which instructs CLFS to automatically add HMACs to log files that do not have HMACs. The automatic addition of authentication codes occurs when a log file is opened, and only if the calling thread has write access to the underlying file. The current adoption period lasts for 90 days, starting from the time the system is first booted with this version of CLFS. After this 90-day adoption period has elapsed, the driver will automatically switch to enforcement mode on the next boot, after which CLFS will expect all log files to contain valid HMACs. This 90-day value may change in the future.

If you are performing a fresh Windows installation, CLFS will start in force mode since there is no need to convert existing log files to the new format.

FSUTIL command

that fsutil clfs authentication The command line utility can be used by administrators to add or modify authentication codes to existing log files. This command is useful in the following scenarios:

1. If your log files are not opened during the migration adoption period and are not automatically converted to the new format, you can use this command to add an authentication code to the log files.
2. The authentication code is generated using the local system’s encryption key, using a system-specific encryption key, so you can open log files generated on other systems.

usage:

PS D:\> fsutil.exe clfs authenticate
Usage: fsutil clfs authenticate 
   Eg: fsutil clfs authenticate "C:\example_log.blf"

Add authentication support to a CLFS logfile that has invalid or
missing authentication codes. Authentication codes will be written
to the Base Logfile (.blf) and all containers associated with the logfile.

It is required that this command be executed with administrative
privileges.

composition

There are a few ways to configure this mitigation. Whichever approach you take, you must be an administrator.

1. Registry settings

Settings for this mitigation are stored in the registry under the key: HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication. There are two registry values ​​that administrators can view and modify:

• method: Mode of operation of relief
  • 0: Mitigation applies. CLFS will not open log files with missing or invalid authentication codes. CLFS will automatically switch to enforcement mode after 90 days of running the system with this version of the driver.
  • 1: The mitigation is in learning mode. CLFS always opens the log file. If there is no authentication code in the log file, CLFS generates one and writes it to the file (assuming the caller has write access).
  • 2: The administrator has disabled the mitigation feature.
• Transition period: The time (in seconds) that the system spends during the adoption period. If this value is 0, the system will not automatically switch to enforcement.

To disable the mitigation feature, an administrator can run the following PowerShell command:

Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\CLFS\Authentication” -Name Mode -Value 2

To extend the adoption period for a mitigation measure, administrators can run the following PowerShell command:

Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\CLFS\Authentication” -Name EnforcementTransitionPeriod -Value 2592000

2. Group Policy

Relaxation can be controlled using: Clfs authentication confirmation Group Policy setting (“Enable/Disable CLFS Log File Authentication”). This policy setting can be found in “Administrative Templates\System\File System.” zipedit.exe.

Figure 1: Local Group Policy Editor

Like all Group Policy settings, the CLFS log file authentication setting can be in one of three states:

• “Not configured” (default) – Allows mitigation to be enabled. CLFS checks the local registry mode (HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication [Mode]).
• “Enabled” – Same as “Not Configured”. Mitigation can be enabled, but CLFS will check the local registry settings first.
• “Disabled” – Mitigation is disabled. CLFS will attempt to open potentially corrupt log files without verifying the authentication code.

When a mitigation feature is switched from disabled to enabled (via Group Policy), the mitigation rollout period will automatically repeat itself, as there will likely be log files on the system that were generated without authentication codes while the mitigation feature was disabled.

User Impact

This mitigation may impact CLFS API consumers in the following ways:

• The encryption key used to generate the authentication code is system-specific, so the log file is no longer portable between systems. To open a log file generated on another system, an administrator must first use: fsutil clfs authentication A utility that authenticates log files using the local system’s encryption key.
• A new file with the extension “.cnpf” is saved along with the BLF and data container. If the BLF for the log file is in “C:\Users\User\example.blf”, the “patch file” should be in “C:\Users\User\example.blf.cnpf”. If the log file is not closed cleanly, the patch file contains data that CLFS needs to recover the log file. The patch file is created with the same security attributes as the file that provides the recovery information. This file is approximately the same size as the “FlushThreshold” (HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Parameters). [FlushThreshold]).
• Additional file space is required to store the authentication codes. The amount of space required for the authentication codes will vary depending on the file size. For an estimate of the amount of additional data required for the log file, see the list below.
  • A 512KB container file requires an additional ~8192 bytes.
  • A 1024KB container file requires an additional ~12288 bytes.
  • A 10MB container file requires an additional ~90112 bytes.
  • A 100MB container file requires an additional ~57344 bytes.
  • A 4GB container file requires an additional ~2101248 bytes.
• The time taken to create, open, and write log files increased due to the increased I/O operations required to maintain the authentication code. The increase in the time taken to create and open log files is entirely dependent on the size of the container, with larger log files having a much more noticeable effect. On average, the time taken to write a record to a log file doubled.

CLFS API Changes

To avoid breaking changes to the CLFS API, we report integrity check failures to callers using legacy error codes.

• If CreateLogFile If it fails, Get the last error Will return ERROR_LOG_METADATE_CORRUPTED This error code occurs when CLFS cannot verify the integrity of a log file.
• For ClfsCreateLogFilethat Status log metadata corruption If CLFS cannot verify the integrity of the log file, a status of 0 is returned.