Skip to content

CVE-2023-36036

Cloud Files Mini Filter -- heap overflow via crafted reparse data

Exploited in the Wild

This vulnerability was exploited in the wild before or shortly after patching.

Summary

Field Value
Driver cldflt.sys
Vulnerability Class Buffer Overflow / Bounds Check
Vulnerable Build 10.0.22621.2506 (KB5031455)
Fixed Build 10.0.22621.2715 (KB5032190)
Exploited ITW Yes

Affected Functions

  • HsmFltProcessReparse
  • HsmpRpReadBuffer
  • HsmpRpWriteBuffer

Root Cause

The Cloud Files Mini Filter (cldflt.sys) is the kernel component behind Windows' cloud file placeholder system, used by OneDrive and third-party cloud sync providers. It intercepts file system requests and manages the hydration and dehydration of files through NTFS reparse points. Each cloud-backed file carries a reparse point containing metadata about the file's cloud state, including length fields that describe the embedded data.

The vulnerability lives in HsmFltProcessReparse, which processes these reparse point structures. When the driver encounters a cloud file reparse point, it reads length fields from the reparse data to determine how much data to copy into kernel buffers via HsmpRpReadBuffer and HsmpRpWriteBuffer. The problem is that these length fields are taken directly from the on-disk reparse data without validation against the actual allocation size. A crafted reparse point can declare a data length larger than the buffer allocated to hold it. The memcpy that follows uses the declared (attacker-controlled) length rather than the allocated size, writing past the end of the heap buffer and corrupting adjacent kernel pool objects.

Since reparse points are set through FSCTL_SET_REPARSE_POINT, which is accessible from user mode, the entire overflow is triggerable by an unprivileged local user.

AutoPiff categorizes this as bounds_check with detection rules:

  • added_len_check_before_memcpy
  • added_bounds_check_on_offset

Exploitation

The heap overflow in the kernel non-paged pool is exploited through pool feng shui. The attacker first creates a file with a crafted reparse point, setting the data length fields to values that will overflow the destination buffer by a controlled amount. Before triggering the overflow, the attacker sprays the kernel pool with objects sized to fill the same pool bucket, creating a deterministic layout where known object types sit adjacent to the vulnerable buffer.

When the overflow fires, it corrupts the header or data fields of the adjacent sprayed object. The specific spray target determines the next primitive: corrupting a pipe attribute object provides a relative read/write, while corrupting a pool chunk header can redirect pool allocations. The attacker escalates from relative read/write to arbitrary kernel read/write, then performs the standard EPROCESS token swap to gain SYSTEM privileges.

The in-the-wild exploitation suggests that at least one threat actor had a reliable pool grooming strategy for this overflow before the patch shipped.

Patch Analysis

The fix in KB5032190 adds bounds checks in HsmFltProcessReparse before the memcpy calls. The declared data length in the reparse point is now compared against the allocated buffer size, and requests where the length exceeds the allocation are rejected with an error status. HsmpRpReadBuffer and HsmpRpWriteBuffer both received similar validation.

AutoPiff detects this via the added_len_check_before_memcpy and added_bounds_check_on_offset rules.

Detection

YARA Rule

rule CVE_2023_36036_CLDFLT {
    meta:
        description = "Detects vulnerable version of cldflt.sys (pre-patch)"
        cve = "CVE-2023-36036"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $driver_name = "cldflt.sys" wide ascii nocase
        $vuln_build = "10.0.22621.2506" wide ascii
        $reparse_func = "HsmFltProcessReparse" ascii
        $rp_read = "HsmpRpReadBuffer" ascii
        $rp_write = "HsmpRpWriteBuffer" ascii
    condition:
        $mz at 0 and $driver_name and $vuln_build and any of ($reparse_func, $rp_read, $rp_write)
}

ETW Indicators

Provider Event / Signal Relevance
Microsoft-Windows-CloudFiles Reparse point processing events Monitors the Cloud Files mini-filter for crafted reparse data that triggers the heap overflow
Microsoft-Windows-Kernel-Audit Token modification (Event ID 4672) Captures privilege escalation following successful heap corruption
Microsoft-Windows-Security-Auditing File system object access (Event ID 4663) Detects access to files with crafted reparse points targeting the cldflt.sys mini-filter
Microsoft-Windows-StorageSpaces-Driver Filter manager load/attach events Monitors mini-filter attachment state changes that may indicate exploitation attempts

Behavioral Indicators

  • A process creates files with crafted reparse point data (FSCTL_SET_REPARSE_POINT) where the reparse buffer length fields are inconsistent with the actual data size, targeting the HsmFltProcessReparse code path
  • Heap overflow in the kernel non-paged pool triggered during HsmpRpReadBuffer or HsmpRpWriteBuffer when the driver copies reparse data without proper bounds validation
  • Pool spray activity using objects sized to align with the overflowed allocation, enabling controlled overwrite of adjacent pool metadata or object headers
  • Abnormal DeviceIoControl or NtFsControlFile calls issuing reparse-related FSCTLs from a process with no legitimate cloud sync activity
  • Post-exploitation token swap observed as a low-privilege process suddenly operating with SYSTEM-level access after triggering the overflow

Broader Significance

CVE-2023-36036 was the first in-the-wild exploitation of cldflt.sys, but it would not be the last. The same driver was hit by CVE-2024-30084 (TOCTOU race), CVE-2024-30085 (another heap overflow in HsmIBitmapNORMALOpen), and CVE-2024-49114 (heap overflow in the cache read path) within the following year. The reparse point processing code in cldflt.sys performs complex data transformations with multiple length fields, offsets, and buffer copies, making it a rich target for bounds-check failures. The cluster of vulnerabilities in this single driver demonstrates how a complex data parsing surface in the kernel can yield repeated findings even after individual bugs are patched.

References