Skip to content

CVE-2024-35250

Kernel Streaming -- untrusted pointer dereference in IOCTL dispatch allows EoP

Exploited in the Wild

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

Summary

Field Value
Driver ks.sys
Vulnerability Class IOCTL Hardening
Vulnerable Build 10.0.22621.3672 (KB5037853)
Fixed Build 10.0.22621.3733 (KB5039212)
Exploited ITW Yes

Affected Functions

  • DispatchDeviceControl
  • KsDispatchDeviceControl

Root Cause

ks.sys is the core Kernel Streaming driver that underpins the entire Windows multimedia subsystem. It manages KS filter and pin objects representing audio, video, and other streaming devices. User-mode applications interact with these objects via IOCTLs for property queries, stream control, and event management.

Several KS IOCTL handlers use METHOD_NEITHER, a transfer type where the I/O manager passes raw user-mode pointers directly to the driver without buffering, mapping, or probing. The driver is expected to validate these pointers itself before use. In the vulnerable code path within KsDispatchDeviceControl, the handler retrieves a pointer from the user-supplied KSSTREAM_HEADER or KS property request structure and dereferences it without calling ProbeForRead or ProbeForWrite.

Because the pointer comes directly from user input and is not validated, a kernel-mode virtual address can be supplied in place of a user-mode buffer pointer. The driver follows it at PASSIVE_LEVEL with kernel privileges. Depending on the IOCTL code path, the driver either reads from the supplied kernel address (leaking kernel memory to user mode) or writes attacker-controlled data to it. The operation is deterministic: no race condition, no heap grooming, no information leak needed as a prerequisite.

AutoPiff categorizes this as ioctl_hardening with detection rules:

  • method_neither_probe_added
  • ioctl_input_size_validation_added

Exploitation

This bug was demonstrated at Pwn2Own Vancouver 2024 by both DEVCORE (Angelboy) and Star Labs for local privilege escalation from standard user to SYSTEM. The exploit is remarkably clean.

The attacker opens a handle to a KS device (these are accessible to low-privileged users since any process that plays audio or video interacts with kernel streaming). The exploit constructs a METHOD_NEITHER IOCTL request with a kernel-mode address as the buffer pointer and sends it via DeviceIoControl. The driver dereferences the pointer at kernel privilege, providing either a read (kernel memory leaked to user space) or a write (attacker data written to kernel address) depending on the IOCTL path chosen.

No separate information leak is needed because the read primitive from the same bug provides kernel address disclosure. The attacker reads kernel memory to locate the current process's EPROCESS structure, then uses the write primitive to overwrite the process's token pointer with the SYSTEM token. The entire exploit is a handful of DeviceIoControl calls with crafted buffers.

Patch Analysis

The patch in KB5039212 (build 10.0.22621.3733) added ProbeForRead and ProbeForWrite calls in the METHOD_NEITHER IOCTL dispatch paths within ks.sys. Each user-supplied pointer is now validated to confirm it falls within the user-mode address range and is properly aligned; failures are rejected with STATUS_ACCESS_VIOLATION. The patch also introduced input buffer size validation, ensuring the IOCTL input buffer meets the minimum size for the expected property request structure.

AutoPiff detects these via the method_neither_probe_added rule (insertion of ProbeForRead/ProbeForWrite in handlers that previously lacked them) and ioctl_input_size_validation_added (new comparisons of input buffer length against expected structure sizes).

Detection

YARA Rule

rule CVE_2024_35250_ks_sys {
    meta:
        description = "Detects vulnerable version of ks.sys (pre-patch)"
        cve = "CVE-2024-35250"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $driver_name = "ks.sys" wide ascii nocase
        $version = "10.0.22621.3672" wide ascii
        $dispatch = "KsDispatchDeviceControl" ascii
        $method_neither = { 83 ?? 03 }  // METHOD_NEITHER comparison
    condition:
        $mz at 0 and $driver_name and $version and ($dispatch or $method_neither)
}

ETW Indicators

Provider Event / Signal Relevance
Microsoft-Windows-KSVC KS IOCTL dispatch events Kernel Streaming control requests to ks.sys, including METHOD_NEITHER property requests
Microsoft-Windows-Kernel-Audit Privilege escalation events Token manipulation following R/W primitive exploitation
Microsoft-Windows-Security-Auditing Event 4672 -- Special privileges assigned SYSTEM token privilege acquisition after token swap
Microsoft-Windows-Kernel-IoTrace IOCTL dispatch tracing DeviceIoControl calls to KS filter/pin objects with METHOD_NEITHER transfer type
Microsoft-Windows-Kernel-Process Process token change Unexpected token replacement on a user-mode process

Behavioral Indicators

  • Low-privileged process opens a handle to a Kernel Streaming device (\Device\KSENUM#...) and issues METHOD_NEITHER IOCTLs with kernel-range buffer pointers
  • IOCTL input buffer contains pointer values above 0xFFFF800000000000 on x64, directing the driver to dereference arbitrary kernel memory
  • Process EPROCESS.Token field changes from a low-privilege token to the SYSTEM token mid-execution without a corresponding logon event
  • NtQuerySystemInformation calls (SystemHandleInformation or SystemModuleInformation) precede the IOCTL exploitation, leaking kernel object addresses for the R/W primitive
  • Single process escalates from medium/low integrity to SYSTEM without spawning a child process or invoking a privileged service

Broader Significance

CVE-2024-35250 is arguably the highest-impact kernel streaming vulnerability found during the 2024 research wave. Its clean, deterministic exploitation (no race, no spray, read and write from the same bug) made it the centerpiece of multiple Pwn2Own chains. The root cause, missing ProbeForRead/ProbeForWrite in METHOD_NEITHER handlers, is a known anti-pattern that the Windows Driver Frameworks documentation explicitly warns against. Yet it persisted in ks.sys, one of the most widely loaded kernel drivers on Windows. This suggests that core framework drivers may receive less security scrutiny than their ubiquity warrants.

References