CVE-2024-26229

Client-Side Caching -- missing access check allows EoP

Summary

Field	Value
Driver	csc.sys
Vulnerability Class	Authorization / Access Check
Vulnerable Build	10.0.22621.1 (RTM)
Fixed Build	10.0.22621.3447 (KB5036893)
Exploited ITW	No

Affected Functions

• CscDevFcbXXXControlFile
• R0Ioctl

Root Cause

The Client-Side Caching driver (csc.sys) implements Windows Offline Files functionality. It manages a local cache of network files, allowing users to work with SMB shares while disconnected. The driver creates a device object (\Device\CSC) that user-mode components interact with via DeviceIoControl.

The vulnerability is a missing authorization check in the IOCTL dispatch path. When CscDevFcbXXXControlFile or R0Ioctl receives a request, it processes the operation at kernel privilege level without verifying the caller's token, checking PreviousMode, or validating that the caller holds the privileges necessary for the requested operation. Any user-mode process can open a handle to \Device\CSC and issue IOCTLs that the driver executes with full kernel authority.

This is not a memory corruption bug. The driver's logic works exactly as coded; it simply never asks "should this caller be allowed to do this?" The vulnerability has existed since the Windows 11 RTM build, meaning every Windows 11 system shipped with this open authorization gap until the April 2024 patch.

AutoPiff categorizes this as authorization with detection rules:

• added_access_check
• added_previous_mode_gate
• added_privilege_check

Exploitation

The attacker opens a handle to \Device\CSC and issues IOCTLs through the CscDevFcbXXXControlFile and R0Ioctl paths. Because no authorization check gates these operations, the driver processes them at kernel privilege regardless of the caller's actual privilege level. The specific IOCTLs provide operations that, when abused, yield a kernel-level primitive sufficient for privilege escalation.

A weaponized exploit (published by RalfHacker on GitHub) uses this to escalate from standard user or medium-integrity context to SYSTEM. The key advantage of this vulnerability class is simplicity: there is no memory corruption to stabilize, no race to win, and no heap to groom. The driver simply does what you ask without checking if you should be asking.

Patch Analysis

The fix in KB5036893 adds three layers of authorization to the IOCTL dispatch path. First, an explicit access check validates the caller's token against the required privileges. Second, a PreviousMode gate ensures that kernel-mode callers are distinguished from user-mode callers, preventing user-mode processes from masquerading as kernel callers. Third, specific privilege checks verify that the caller holds necessary privileges for sensitive operations.

AutoPiff detects these via added_access_check, added_previous_mode_gate, and added_privilege_check.

Detection

YARA Rule

rule CVE_2024_26229_csc_sys {
    meta:
        description = "Detects vulnerable version of csc.sys (pre-patch)"
        cve = "CVE-2024-26229"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $driver_name = "csc.sys" wide ascii nocase
        $version_rtm = "10.0.22621.1" wide ascii
        $fcb_control = "CscDevFcbXXXControlFile" ascii
        $r0_ioctl = "R0Ioctl" ascii
    condition:
        $mz at 0 and $driver_name and ($version_rtm or $fcb_control or $r0_ioctl)
}

ETW Indicators

Provider	Event / Signal	Relevance
Microsoft-Windows-Security-Auditing	Event 4688 -- Process creation	Processes spawned with elevated privileges after csc.sys exploitation
Microsoft-Windows-Security-Auditing	Event 4672 -- Special privileges assigned	SYSTEM-level privilege acquisition through the missing authorization gate
Microsoft-Windows-Kernel-Audit	IOCTL dispatch authorization events	DeviceIoControl calls to the CSC device bypassing privilege verification
Microsoft-Windows-Kernel-IoTrace	I/O request tracing on CSC device	IOCTL requests to \Device\CSC from unprivileged callers
Microsoft-Windows-Kernel-Process	Process token modification	Token manipulation following authorization bypass

Behavioral Indicators

• Unprivileged user-mode process opens a handle to \Device\CSC and issues IOCTLs through CscDevFcbXXXControlFile / R0Ioctl without required privileges
• The IOCTL handler in csc.sys processes the request at kernel privilege level without validating the caller's token or PreviousMode, allowing user-mode callers to perform kernel-only operations
• Process escalates from standard user or medium-integrity context to SYSTEM without UAC, service creation, or a privileged parent process
• Activity on the CSC device object from processes other than the Offline Files service (CscService) or SMB redirector
• Post-exploitation: access to protected system resources, security policy modification, or SYSTEM-integrity child processes

Broader Significance

CVE-2024-26229 has been present since Windows 11 RTM, meaning it was a day-one vulnerability in every Windows 11 installation. The bug class, missing authorization on a kernel device IOCTL, is among the simplest to exploit and among the most impactful. It requires no memory corruption expertise, no heap grooming, and no race condition management. The existence of this bug in a shipping driver for over two years before patching highlights the gap between the kernel's immense IOCTL attack surface and the resources dedicated to auditing it. The CSC driver is a relatively obscure component that most security researchers would not prioritize, which is precisely why it went unnoticed for so long.

References

• MSRC Advisory
• Writeup
• PoC