The Next Generation of Windows Exploitation: Attacking the Common Log File System

## Overview

Security researchers from the Qihoo Vulnerability Research Institute—focused primarily on Windows platform bug bounties—presented research on the attack surface of the Windows Common Log File System (CLFS). Introduced in Windows Vista, CLFS is a universal logging subsystem that provides high-performance logging and recovery support for dedicated or multiplexed user-mode applications.

Applications interact with CLFS via APIs such as `CreateLogFile` and `CloseHandle`. Drawing prior insights from research by Alice, Uniscod Lab, and Cisco Talos, the authors divided the CLFS attack surface into two primary categories within the CLFS system driver: 1. Base log file (`.blf`) parsing vulnerabilities. 2. Error handling of file code vulnerabilities.

---

## Fuzzing Methodology

To uncover vulnerabilities in CLFS, the researchers engineered a structure-aware file format fuzzer targeting `.blf` files:

1. **Log Generation**: Created base `.blf` files (either dedicated or multiplexed, with optional container additions) using `CreateLogFile` and container-related APIs. 2. **Reverse Engineering & Target Structures**: Identified driver parsing logic using IDA Pro, noting that functions prefixed with `Get*` and `Acquire*` read file contents directly (e.g., `GetBaseLogRecord`, `GetControlRecord`, `AcquireMetadataBlock`, and `AcquireTraceContent`). 3. **CRC Check Bypass**: Reversing revealed that CLFS performs a CRC check whenever a `.blf` file is parsed. The fuzzer systematically recalculates or bypasses this CRC check after mutating structured file data. 4. **Driver Invocation**: Executed various CLFS operational functions documented in MSDN or recovered from the driver (including log storage, record reservation, archive, and restore functions) to force the driver to read and parse the mutated `.blf` files.

---

## Vulnerability Analysis & Findings

The fuzzer triggered multiple crashes, from which two specific out-of-bounds (OOB) vulnerabilities were detailed:

### 1. CVE-2022-21916 (CLFS Control Record OOB Index) * **Structure & Location**: Located in the `CLFS_CONTROL_RECORD` structure at offset `0x70` of the `.blf` file. * **Key Fields**: * `eExtensionState`: Set to `CLFS_EXTEND_STATE_FLUSH_BLOCK` (`true`), which guides execution into the vulnerable function `ShiftMetadataBlockDescriptor`. * `iExtensionBlock`: Identifies the block index being extended (e.g., value `24`). * `iFlushBlock`: Identifies the block index being flushed (e.g., value `3`). * **Root Cause**: When parsing metadata in `ShiftMetadataBlockDescriptor`, the driver fails to properly validate `iExtensionBlock` and `iFlushBlock`. When `iFlushBlock` is utilized directly as an index, it triggers an out-of-bounds access. The issue was reported to MSRC and assigned CVE-2022-21916.

### 2. CLFS Log FCB Pool Overflow * **Vulnerable Context**: Resides within the `ClfsLogFcbPhysicalOverflowReversal` function, associated with owner page operations. * **Mechanism**: The function `CClfsBaseFile::HighWaterMarkSanitizing` calculates a client ID by reading the `cNextClient` field from the `CLFS_BASE_RECORD_HEADER` structure and subtracting 1 (`cNextClient - 1`). * **Root Cause**: Mutating `cNextClient` in the `.blf` file to an unexpected value leads to an invalid index calculation. When the resulting client ID exceeds `0x70`, an out-of-bounds condition occurs. * **Impact**: Results in a kernel pool overflow with a page pool size of `0x1000`. The driver writes CLFS internal values (such as CLFS ALS) and stale owner page data directly into the header of the adjacent kernel pool.