Common Log File System (CLFS) Authentication Mitigation

In this article 

Summary

Mitigation adoption period

User impact

Configuration

Update Group Policy setting using the Local Group Policy Editor

Update Group Policy/MDM setting using Intune

Changes to the CLFS API

Frequently asked questions (FAQ)

Glossary

Summary

A new hardening authentication mitigation has been introduced for the Common Log File System (CLFS) driver which adds a hash-based message authentication code (HMAC) to the underlying files of a CLFS logfile. Authentication codes are created by combining file data with a system-unique cryptographic key, which is stored in the registry and only accessible to Administrators and SYSTEM. The authentication codes will allow CLFS to check the integrity of the file, ensuring file data is safe prior to parsing its internal data structures. CLFS assumes that this file was externally modified, maliciously or otherwise, if the integrity check fails and will refuse to open the logfile. To proceed, either a fresh logfile must be created or an Administrator will need to manually authenticate it using the fsutil command.

Mitigation adoption period

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 authentication codes 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 the required access to write to the file. Currently, the adoption period lasts for 90 days, starting from the time in which the system was first started with this version of CLFS. After this 90-day adoption period has lapsed, the driver will automatically transition into enforcement mode on its next start, after which CLFS will expect all logfiles to contain valid authentication codes. Note that this 90-day value may change in the future.

If a logfile is not opened during this adoption period and therefore was not automatically transitioned over to the new format, the fsutil clfs authenticate command line utility can be used to add authentication codes to the logfile. This operation requires the caller to be an Administrator.

User impact

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

• Because the cryptographic key used to make the authentication codes is system-unique, logfiles are no longer portable between systems. To open a logfile that was created on a remote system, an Administrator must first use the fsutil clfs authenticate utility to authenticate the logfile by using the local systems cryptographic key.

• A new file, with the extension “.cnpf” will be stored alongside the Binary Logging File (BLF) and data containers. If the BLF for a logfile is located at “C:\Users\User\example.blf”, its “patch file” should be located at “C:\Users\User\example.blf.cnpf”. If a logfile is not cleanly closed, the patch file will hold data needed for CLFS to recover the logfile. The patch file will be created with the same security attributes as the file it provides recovery information for. This file will at most be the same size as “FlushThreshold” (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Parameters [FlushThreshold]).

• Additional file space is required to store authentication codes. The amount of space needed for authentication codes depends on the size of the file. Refer to the following list for an estimate about how much additional data will be required for your logfiles:

  • 512KB container files require an additional ~8192 bytes for authentication codes.

  • 1024KB container files require an additional ~12288 bytes for authentication codes.

  • 10MB container files require an additional ~90112 bytes for authentication codes.

  • 100MB container files require an additional ~57344 bytes for authentication codes.

  • 4GB container files require an additional ~2101248 bytes for authentication codes.

• Due to the increase in I/O operations for maintaining authentication codes, the time it takes to perform the following operations has increased:

  • logfile creation

  • logfile open

  • writing of new records

  The increase in time for logfile creation and logfile open depends entirely on the size of the containers, with larger logfiles having a much more noticeable impact. On average, the amount of time it takes to write to a record in a logfile has doubled.

Configuration

The settings related to this mitigation are stored in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication. The following is a list of key registry values and their purpose:

• Mode: The operating mode of the mitigation

  • 0: The mitigation is enforced. CLFS will fail to open logfiles that have missing or invalid authentication codes. After 90 days of running the system with this version of the driver, CLFS will automatically transition into enforcement mode.

  • 1: The mitigation is in learning mode. CLFS will always open logfiles. If a logfile is missing authentication codes, then CLFS will generate and write the codes to the file (assuming caller has Write access).

  • 2: An Administrator disabled the mitigation.

  • 3: The mitigation was disabled automatically by the system. An Administrator should not set the Mode to this value but should use “2”if they wish to disable the mitigation.

• EnforcementTransitionPeriod: The amount of time, in seconds, that the system will spend in the adoption period. If this value is zero, then the system will not automatically transition into enforcement.

• LearningModeStartTime: The timestamp at which learning mode started on the system. This value, in combination with “EnforcementTransitionPeriod” will determine when a system should transition into enforcement mode.

• Key:The cryptographic key used to create authentication codes (HMACs). Administrators should not modify this value.

Administrators can disable the mitigation altogether by changing the Mode value to 2. To prolong the mitigation adoption period, an Administrator can change the EnforcementTransitionPeriod (seconds) to any value you choose (or 0 if you want to disable automatic transition into enforcement mode).

Update Group Policy setting using the Local Group Policy Editor

CLFS Authentication can be enabled or disabled using the Group Policy Setting:​​​​​​​

1. Open the Local Group Policy Editor in Windows Control Panel.
   
   

2. Under Computer Configuration, select Administrative Template > System > Filesystem and in the Setting list, double-click Enable / disable CLFS logfile authentication.
   
   ​​​​​​​

3. Select Enable or Disable and then click OK. If Not Configured is selected, the mitigation is enabled by default.
   
   ​​​​​​​​​​​​​​

Update Group Policy/MDM setting using Intune

To update Group Policy and configure CLFS Authentication using Microsoft Intune:

1. Open the Intune portal (https://endpoint.microsoft.com) and log in with your credentials.

2. Create a profile: 

   1. Select Devices > Windows > Configuration > Create > New Policy.

   2. Select Platform > Windows 10 and later.

   3. Select Profile type > Templates.

   4. Search for and select Custom​​​​.
      
      ​​​​​​​

3. Set a name and description:
   
   ​​​​​​​

4. Add a new OMA-URI setting:
   
   ​​​​​​​

5. Edit OMA-URI setting: 

   1. Add a name such as ClfsAuthenticationCheck.

   2. Optionally add a description.

   3. Set the OMA-URI path to the following:
      
      ./Vendor/MSFT/Policy/Config/FileSystem/ClfsAuthenticationChecking

   4. Set the Data type to String.

   5. Set the Value to <enabled/> or <disabled/>.

   6. Click Save.
      
      ​​​​​​​

6. Complete the remaining configuration of Scope tags and Assignments, and then select Create. ​​​​​​​

Changes to the CLFS API

To avoid breaking changes to the CLFS API, existing error codes are used to report integrity check failures to the caller:

• If CreateLogFile fails, then GetLastError will return the ERROR_LOG_METADATA_CORRUPT error code.

• For ClfsCreateLogFile, the STATUS_LOG_METADATA_CORRUPT status is returned when CLFS fails to verify the integrity of the logfile.

Frequently asked questions (FAQ)​​​​​​​

Glossary

Hardening is a process that helps protect against unauthorized access, denial of service, and other threats by limiting potential weaknesses that make systems vulnerable.

Security attributes are used to store information and enforce fine-grained access control over specific resources.