Attacking File System Minifilters - A Case Study of cldflt.sys

Attacking File System Minifilters - A Case Study of cldflt.sys

Speakers: Ali Ahmad, Security Researcher, Margin Research

Conference: DistrictCon

YouTube: https://www.youtube.com/watch?v=GoXi6ea7-KY

Overview

In this insightful talk, Ali Ahmad, a Security Researcher at Margin Research, delves into the intricacies of attacking Windows file system minifilters, with a particular focus on cldflt.sys, the Cloud Filter driver. Ahmad's research was initially driven by a desire to compete in Pwn2Own with his team, HT3 Labs, leading him to select a target with existing public research to build upon. The Cloud Filter driver, a core component of Windows' hierarchical storage management (HSM) responsible for functionalities like OneDrive, presented a compelling and complex target due to its critical position within the operating system's I/O stack and its history of vulnerabilities.

The talk systematically breaks down the Windows kernel architecture, the role of minifilters, and the specific mechanisms of cldflt.sys. Ahmad meticulously details the driver's attack surface, covering both intercepted file system operations and asynchronous message port communications. He shares his bug hunting methodologies, including targeted fuzzing and reverse engineering, alongside a comprehensive review of historical vulnerabilities. Crucially, Ahmad reflects on the lessons learned from his initial research phase, offering valuable insights into more effective strategies for uncovering bugs in such complex kernel drivers, making this presentation an essential resource for kernel exploit developers and security researchers.

Background

▶ Watch: Windows architecture and file system mini-filter fundamentals (2:00)

To understand the attack surface of cldflt.sys, it's essential to first grasp its foundational role within the Windows operating system. The Windows architecture is fundamentally divided into user mode and kernel mode, separated by a dotted line. Applications reside in user mode, and when they perform operations requiring system resources, such as file access, they initiate syscalls. These calls traverse through DLLs, notably NTDLL, transitioning into kernel mode via the Executive layer and eventually reaching the I/O Manager.

Minifilters are kernel-mode drivers that sit strategically between the I/O Manager and the core file system driver. Their primary function is to intercept and inspect file system operations, such as CreateFile, DeleteFile, and RenameFile. Each minifilter possesses an altitude, a numerical value determining its position in the driver stack; higher altitudes indicate closer proximity to the I/O Manager, while lower altitudes are closer to the file system. Minifilters serve various critical functions, including security (e.g., EDR software, encryption), data management (e.g., backups, compression), and most pertinently for this talk, hierarchical storage management (HSM).

The cldflt.sys driver specifically implements HSM, which allows data to reside on different storage sources, such as local disk and cloud storage. This functionality is most prominently seen in Microsoft OneDrive. Key terminology for cloud synchronization includes:

• Sync root: The local folder managed by the cloud service (e.g., the OneDrive folder).
• Sync root provider: The user-mode application that manages the sync root (e.g., the OneDrive application).
• Placeholder files: Files that exist in the cloud but are not yet fully present on the local disk.
• Hydration: The process of downloading the actual data for a placeholder file to the local disk.
• Dehydration: The reverse process, where a file's data is removed from local disk, leaving only a placeholder.

The Cloud Filter driver, with an altitude of approximately 180,000, sits as middleware within the I/O operation stack, making it a critical interception point. User-mode components like the sync provider (OneDrive.exe) interact with cldflt.sys via the cloudapi.dll and filterlib.dll libraries. Registering a sync root requires setting a reparse point on a folder and typically involves a medium integrity process, which is a common requirement for Pwn2Own exploits aiming for system-level privileges.

Communication with cldflt.sys occurs through two main callback types:

• Filter callbacks: These are synchronous pre- and post-operation hooks for standard file system operations. For instance, a PreCreate callback occurs before a file handle is opened, and a PostCreate callback after.
• Sync root callbacks: These are asynchronous mechanisms where the kernel, upon encountering a placeholder file that needs data (e.g., during a read operation), queries the user-mode sync root provider for the necessary content. This asynchronous interaction, involving multiple steps between kernel and user mode, presents an interesting attack surface.

The Cloud Filter driver utilizes several filter contexts to store information, including instance, file, stream, and stream handle contexts, each providing specific data about the driver's state and the files it manages.

Key Findings

▶ Watch: Deep dive into Cloud Filter's callback and message port attack surfaces (9:00)

The core of Ali Ahmad's presentation revolves around dissecting the attack surface of the Cloud Filter driver, cldflt.sys. He identifies two primary channels for interaction, each presenting distinct opportunities for vulnerability research: intercepted operations (filter callbacks) and the message port (asynchronous communication).

The filter callback surface encompasses approximately 15 registered file system operations, some with both pre- and post-callbacks, and others with only pre-callbacks. While operations like PreRead, PreWrite, and PreCreate are significant, Ahmad highlights Pre-file system control as the most critical callback. This callback acts as a kernel-mode equivalent to DeviceIoControl for files, internally calling NtFsControlFile. It exposes 15 distinct FS control codes, akin to IOCTLs for drivers. Of these, 11 use buffered I/O, where user buffers are copied to kernel buffers, and 4 use neither I/O. The "neither I/O" method is particularly interesting for bug hunting because it passes raw user-mode pointers directly to the kernel, minimizing data sanitization and increasing the risk of memory corruption if not handled carefully.

Within the Pre HSM control code, which governs the driver's hierarchical storage management functionalities, several sub-operations exist:

• Environment operations: These allow for creating, converting, updating, and querying placeholder files. For example, converting a regular file into a placeholder or querying a directory for its placeholder contents.
• Sync root information: Used to retrieve various levels of information about the sync root, from basic to standard.
• Placeholder operations: These enable querying the hydration state of specific byte ranges within a file (range states), as well as explicit dehydrate and hydrate commands. They also allow manipulation of a file's sync and pin states, indicating whether a file is fully synchronized or locally retained.
• Property operations: Ahmad specifically identifies these four APIs as a highly promising area for bug hunting. At the time of his research, these APIs were largely undocumented, harder to reach, and crucially, had no publicly discovered bugs. This lack of prior scrutiny suggested a higher likelihood of uncovering new vulnerabilities. These operations include setting and getting correlation vectors, which are used for telemetry tracking.

The message port attack surface facilitates asynchronous communication between the user-mode sync root provider and the kernel driver. It exposes several families of commands:

• Filter control: Used to query the progress of an operation or abort ongoing hydration processes.
• Service commands: Essential for managing the sync root's lifecycle, including setup, deletion, connection, and disconnection. These operations handle critical state changes for the driver.
• Range info: Provides specific details about which file offsets are hydrated, typically stored as bitmaps within the stream context.
• Acknowledging notifications: Allows the user-mode provider to confirm receipt of kernel-initiated events, such as file renames, deletions, or dehydrations.
• Transfer: A crucial mechanism for data exchange not handled by FS control file. This includes Transfer Placeholders (operation 105), where the sync root provider sends information about placeholders to the kernel, and Transfer Data, where actual file content for hydration is passed from user mode to the kernel. This direct data transfer path between user and kernel modes is another prime area for input validation issues.

Ahmad’s analysis clearly delineates a complex attack surface where both synchronous I/O operations and asynchronous message passing offer distinct avenues for exploitation, with the undocumented Property operations and raw pointer handling in "neither I/O" being particularly highlighted as high-value targets.

Technical Deep Dive

▶ Watch: Review of historical bugs and recurring vulnerability patterns (26:00)

Ahmad's bug hunting journey involved two primary strategies: fuzzing and reverse engineering, both of which he critically self-assessed for their effectiveness.

His fuzzing architecture was inspired by Synaptics' Pwn2Own 2023 entry, which also targeted this driver. It comprised a watchdog process, an operation fuzzer, and an HSM control fuzzer. The watchdog's role was to periodically kill and restart the subprocesses, aiming to trigger use-after-free (UAF) conditions. The HSM control fuzzer was built by reversing user-mode cloudapi.dll calls down to DeviceIoControl to reconstruct valid kernel-mode packets. Mutations were applied randomly 25% of the time, specifically adding values up to 0x100 to lengths and offsets. This approach was chosen because cldflt.sys has a historical susceptibility to heap overflows and out-of-bounds (OOB) bugs related to size parameters. The message port was less thoroughly fuzzed, primarily focusing on environmental changes rather than complex packet mutations. The operation fuzzer performed basic file operations (create, delete, rename) on placeholder files without complex manipulation. Ahmad later acknowledged the fuzzer's limitations, particularly its failure to test negative values for sizes, which would have been critical for finding integer overflows.

Reverse engineering techniques included:

• Cross-referencing memmove: Identifying 111 cross-references to memmove (equivalent to memcpy) served as a quick win strategy. Often, the allocation, memmove operation, and relevant size information were co-located within the same function, making heap overflows easier to spot.
• Variant hunting: This involved studying documented bugs and looking for similar patterns. A notable example was a CVE in SetPinState involving an integer truncation bug. When querying file paths, a 64-bit integer was returned for 64-bit file paths, but the driver's logic used a WORD (16-bit) to store this value, leading to truncation and a subsequent overflow.
• Use-after-free hunting: Ahmad focused on dangling pointers, missing locks, and incorrect lock types, specifically shared locks being used on write/free operations. He noted that while he didn't find this particular bug in cldflt.sys, he did observe it in another filter driver, validating the hunting strategy.
• General process review: Tracing execution paths from interesting function entry points to their conclusion.

The history of vulnerabilities in cldflt.sys is extensive and highlights recurring patterns:

• 2020 (James Forshaw): Arbitrary file creation via CreatePlaceholders due to access check issues, and arbitrary registry key creation.
• 2021: Pool overflow in reparse point decompression, an ACL bypass via SetReparsePointEX (which the driver failed to intercept), and an out-of-bounds read in GetStandardInfo due to unchecked sizes.
• 2022: A race condition related to bitmaps and an integer overflow when processing sync root names.
• 2023: A significant year with six bugs, including a use-after-free due to IRP cancellation (discovered by Synaptics), missing ACLs on placeholder creation, a stack overflow in PopulationContext (fixed by moving it to the heap), an out-of-bounds read from poor MDL arithmetic, and another out-of-bounds read related to correlation vector generation differences.
• 2024: Six more bugs.
• 2025 (start of Ahmad's research): One bug in ProcessCommands (message port).

A recurring theme in many cldflt.sys vulnerabilities concerns file identity and reparse point buffers. The file identity is a 0x1000 byte buffer stored within the reparse point, a tagging mechanism used by minifilters. A specific CVE involved an integer underflow where 12 bytes were subtracted from a reparse buffer's size. If the initial size was less than 12, it would underflow, leading to a large value and a heap overflow when used in an allocation. Microsoft's patch for this introduced a new function, ReparsePointDecompressBuffer, but inadvertently created a new bug with similar logic (value + 8 for allocation, then -12 for decompression). The driver's use of static buffer sizes (0x1000 for file identity, 0x4000 for reparse points) combined with unchecked user-controlled size values frequently led to heap overflows via memmove operations. For instance, FileIdentityCompare involved an allocation of 0x1000, but if the user-controlled size was not properly validated, a memmove could lead to an overflow. Patches often involved adding explicit checks like if (size > 0x1000).

Ahmad’s research recap provides critical self-reflection. Despite spending 1.5 months without finding bugs, subsequent patch diffing provided invaluable context. He identified key changes he would make:

• Reverse Engineering: Focus UAF hunting on driver-managed objects (e.g., population context, bitmaps, sync root state) rather than filter manager-managed contexts, which are out of scope. Broaden variant hunting beyond a single bug type. Thoroughly review all memmove operations, a strategy validated by a recently discovered heap overflow in the properties operations.
• Fuzzer Tuning: More precise packet generation for HSM control. Tune the fuzzer to rediscover historical bugs, particularly by introducing negative values for size parameters to uncover integer overflows. Add support for fuzzing callbacks and reparse point logic, given the high concentration of bugs in these areas.

Ahmad then listed seven bugs discovered since his research period: a time-of-check time-of-use (TOCTOU) vulnerability in placeholder name processing, two instances of information disclosure (e-process leak), a heap overflow in properties operations (validating his earlier hypothesis about undocumented APIs), a UAF in sync root disconnection, and out-of-bounds bugs in placeholder updates. This confirmed the ongoing vulnerability of the driver and the efficacy of his refined hunting strategies.

Demo / Proof of Concept

▶ Watch: How patch diffing uncovered recurring vulnerabilities in reparse point logic (31:00)

Unfortunately, due to a battery issue, the planned live demonstration could not be presented. However, Ali Ahmad provided a detailed explanation of a time-of-check time-of-use (TOCTOU) vulnerability he would have demonstrated, which effectively re-exploited an arbitrary file creation bug originally discovered by James Forshaw in 2020.

Forshaw's original bug allowed arbitrary file creation by leveraging reparse points during placeholder creation. A user could set a reparse point within a sync root folder to redirect file creation to an arbitrary location. Microsoft's initial patch to address this involved checking for file path separators (like \ or /) in the provided file name, aiming to prevent path traversal.

The TOCTOU vulnerability arises from a misunderstanding of the MmProbeAndLockPages function. Ahmad initially believed this function rendered the user-mode buffer immutable in kernel mode. However, its actual purpose is to ensure that the memory pages backing the user-mode buffer are locked in physical memory and do not get paged out, rather than preventing modification of the data itself. This distinction is crucial.

The exploit works by exploiting the window between the driver's check and its use of the file path. An attacker could:

1. Provide a file path without a separator, passing Microsoft's check.
2. In the brief moment after the check but before the file creation operation uses the path, quickly modify the user-mode buffer to add a file path separator and a malicious path via a race condition.
3. Because MmProbeAndLockPages only locks the memory pages, not their content, the kernel would then operate on the modified, malicious path, leading to arbitrary file creation.

Ahmad highlighted that this specific TOCTOU bug remained undiscovered for five years until September of the previous year, underscoring the subtle complexities and persistent vulnerabilities that can exist even after initial patches.

Defensive Implications

▶ Watch: Analysis of recently discovered bugs and a critical TOCTOU exploit (39:00)

The detailed analysis of cldflt.sys and its extensive vulnerability history provides several critical defensive implications for both driver developers and security practitioners:

1. Prioritize Input Validation for Lengths and Offsets: The recurring theme of heap overflows and out-of-bounds bugs stemming from unchecked user-controlled sizes, lengths, and offsets is paramount. Developers must implement rigorous validation for all input parameters, especially when dealing with fixed-size kernel buffers like the 0x1000 byte file identity or 0x4000 byte reparse point buffers. This includes checks for both excessively large and maliciously small (leading to integer underflows) values.
2. Handle Reparse Points with Extreme Caution: Reparse points are a powerful and frequently abused mechanism. Any driver logic that interacts with reparse points or stores user-controlled data within them must be meticulously reviewed for path traversal, arbitrary file operation, and information disclosure vulnerabilities. Intercepting all relevant FS control codes (e.g., SetReparsePoint and SetReparsePointEX) and applying consistent access control logic is essential.
3. Implement Robust Concurrency Control: Race conditions and use-after-free vulnerabilities are common in kernel drivers. Developers must ensure proper locking mechanisms are in place. This includes distinguishing between exclusive locks (for write, delete, and modification operations) and shared locks (for read operations) to prevent data corruption or UAFs. The example of a shared lock on a free operation highlights a specific pattern to avoid.
4. Audit Undocumented APIs and Less-Traversed Code Paths: As demonstrated by the heap overflow found in the Property operations area, undocumented or less-frequently used code paths are often fertile ground for vulnerabilities. These areas receive less scrutiny from both developers and security researchers, making them high-risk targets. Thorough code review and targeted testing should be applied to such functions.
5. Adopt Advanced Fuzzing and Tuning Strategies: Generic fuzzing is often insufficient. Defenders should employ targeted fuzzing campaigns that incorporate:

• Historical Bug Patterns: Tune fuzzers to rediscover known bug classes (e.g., integer overflows by injecting negative values, out-of-bounds by testing edge cases like 0x0 or MAX_INT).
• Stateful Fuzzing: Account for the driver's state (e.g., connected/disconnected sync root, hydrated/dehydrated files) to trigger complex race conditions or UAFs.
• Callback and Message Port Coverage: Ensure all interaction surfaces, including asynchronous message ports and various filter callbacks, are comprehensively fuzzed.

1. Understand Memory Management Primitives: A deep understanding of kernel memory management functions, such as MmProbeAndLockPages, is crucial. Misinterpretations of their exact behavior (e.g., confusing memory locking with immutability) can lead to subtle but exploitable TOCTOU vulnerabilities.
2. Prompt Patching and Monitoring: Given cldflt.sys's critical role and frequent targeting in events like Pwn2Own, organizations must prioritize applying security updates promptly. Monitoring for unusual activity related to this driver, especially in conjunction with cloud synchronization features, is also advisable.
3. Focus on Driver-Managed Objects for UAF Hunting: When reviewing code for UAFs, particular attention should be paid to objects whose lifecycle is solely managed by the driver itself (e.g., population contexts, bitmaps, sync root state) rather than those managed by the Filter Manager.

By addressing these defensive implications, developers can significantly enhance the security posture of kernel-mode minifilters, mitigating the risks posed by sophisticated attacks.

Key Takeaways

• Minifilters are a critical and complex attack surface: Windows file system minifilters, particularly those like cldflt.sys involved in core OS functionality, represent a high-impact target for kernel-mode vulnerabilities due to their position in the I/O stack.
• cldflt.sys is historically vulnerable: The Cloud Filter driver has a consistent track record of vulnerabilities, including heap overflows, out-of-bounds reads, UAFs, and access control issues, making it a persistent target for security researchers and exploit developers.
• Input validation is paramount, especially for sizes and offsets: A recurring pattern of vulnerabilities stems from insufficient validation of user-controlled lengths and offsets, particularly when interacting with statically sized kernel buffers, leading to memory corruption.
• Undocumented APIs and less-traversed code paths are high-value targets: Areas of the driver with minimal public documentation or less frequent code execution, such as the Property operations in cldflt.sys, are often where undiscovered vulnerabilities reside.
• Effective fuzzer tuning is crucial for complex targets: Generic fuzzing may not suffice. Tuning fuzzers based on historical bug patterns (e.g., testing negative values for sizes, focusing on reparse point logic) is essential to uncover specific classes of vulnerabilities like integer overflows.
• Concurrency issues (TOCTOU, UAF, race conditions) remain a significant challenge: Kernel drivers require meticulous handling of concurrent operations and memory lifecycles, as subtle misunderstandings of primitive behavior (e.g., MmProbeAndLockPages) can lead to sophisticated TOCTOU exploits.

About the Speaker(s)

Ali Ahmad is a Security Researcher at Margin Research. Prior to his current role, he held positions at Atratus Partners and Optiv, contributing to his expertise in security research. His personal interests include lifting weights and photography. Ahmad is also actively involved in security research with HT3 Labs, the team with which he aimed to compete in Pwn2Own, which motivated his in-depth analysis of the cldflt.sys driver.