CVE-2023-36802

Kernel Streaming Server -- FsContextReg/FsStreamReg object type confusion leads to EoP

Exploited in the Wild

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

Summary

Field	Value
Driver	mskssrv.sys
Vulnerability Class	Type Confusion
Vulnerable Build	10.0.22621.1848 (KB5027231)
Fixed Build	10.0.22621.2283 (KB5030219)
Exploited ITW	Yes

Affected Functions

• FSRendezvousServer::InitializeContext
• FsContextReg

Root Cause

The Kernel Streaming Service Proxy (mskssrv.sys) acts as a rendezvous server for media streaming between user-mode applications and kernel-mode components. It manages connections by creating context structures that are attached to file objects via the FILE_OBJECT.FsContext field. Two distinct structure types exist for this purpose: FsContextReg (a registration context used during connection setup) and FsStreamReg (a stream context used for active data transfer). Both types get stored in the same FsContext pointer, but they have different layouts, different field semantics, and different sizes.

The driver determines which type of context to create based on the parameters used when opening the device handle. Opening two different handles with different creation parameters produces one of each context type. The vulnerability is that when the driver later processes IOCTLs on these handles, it casts FsContext directly to the expected structure type without checking which type the pointer actually refers to.

This creates a classic type confusion. Fields at the same offset in the two structures have entirely different meanings. A length field in FsContextReg might correspond to a pointer field in FsStreamReg, and vice versa. When the driver processes an IOCTL using FsStreamReg semantics on a handle whose FsContext is actually an FsContextReg, it interprets attacker-controlled registration values as kernel pointers, buffer lengths, or flags.

AutoPiff categorizes this as type_confusion with detection rules:

• object_type_validation_added

Exploitation

The attacker opens two handles to \Device\MSKSSRV with different creation parameters, producing both an FsContextReg and an FsStreamReg context. Values in the FsContextReg are set through the registration interface to place controlled data at offsets that correspond to pointer or size fields in the FsStreamReg layout.

The attacker then sends IOCTLs designed for stream operations on the handle whose FsContext is the manipulated FsContextReg. The driver processes these as if the context were an FsStreamReg, following the controlled values as kernel pointers. This yields controlled pointer dereferences in kernel mode, which the attacker shapes into an arbitrary kernel read/write primitive.

With read/write established, the exploit performs the standard EPROCESS token swap: locate the current process's EPROCESS, copy the SYSTEM token pointer, and overwrite the current process token. The result is SYSTEM-level privilege escalation.

Google Project Zero's root cause analysis (linked below) provides a detailed walkthrough of the structure layouts and the specific offset overlaps that make this confusion exploitable.

Patch Analysis

The patch shipped in KB5030219 (build 10.0.22621.2283) added object type validation on the FsContext structure before processing IOCTLs. The vulnerable version cast FILE_OBJECT.FsContext directly to the expected structure type without verification. The patched code checks a type tag embedded in the context structure to confirm it matches the expected context type for the requested IOCTL, returning an error on mismatch.

AutoPiff detects this change via the object_type_validation_added rule, which identifies cases where a patch introduces a type or tag check on a structure pointer that was previously used without validation.

Detection

YARA Rule

rule CVE_2023_36802_MSKSSRV {
    meta:
        description = "Detects vulnerable version of mskssrv.sys (pre-patch)"
        cve = "CVE-2023-36802"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $driver_name = "mskssrv.sys" wide ascii nocase
        $vuln_build = "10.0.22621.1848" wide ascii
        $init_ctx = "InitializeContext" ascii
        $fsctxreg = "FsContextReg" ascii
    condition:
        $mz at 0 and $driver_name and $vuln_build and any of ($init_ctx, $fsctxreg)
}

ETW Indicators

Provider	Event / Signal	Relevance
Microsoft-Windows-Streaming	Device handle creation on \Device\MSKSSRV	Monitors access to the Kernel Streaming Service device used to trigger the type confusion
Microsoft-Windows-Kernel-Audit	Token modification (Event ID 4672)	Captures privilege escalation when the attacker swaps the process token to SYSTEM
Microsoft-Windows-Kernel-Process	Process token change	Detects the moment the exploiting process replaces its token with the SYSTEM token
Microsoft-Windows-Security-Auditing	Special privileges assigned (Event ID 4672)	Alerts on a low-privilege process suddenly acquiring SYSTEM-level privileges

Behavioral Indicators

• A low-privilege user-mode process opens multiple handles to \Device\MSKSSRV with different creation parameters to instantiate both FsContextReg and FsStreamReg context objects simultaneously
• Rapid alternation of IOCTL calls on handles with mismatched context types, causing the driver to dereference controlled pointer values at unexpected structure offsets
• Kernel pool spray activity to groom the non-paged pool and position controlled data at predictable addresses adjacent to context allocations
• Process token replacement in the EPROCESS structure, observable as a low-integrity process suddenly holding the SYSTEM token without going through standard elevation mechanisms
• Abnormal NtDeviceIoControlFile call patterns targeting the MSKSSRV device from a process that is not a media application or streaming service

Broader Significance

CVE-2023-36802 is the second vulnerability in mskssrv.sys within a few months (following CVE-2023-29360), and it was exploited in the wild. The Kernel Streaming subsystem, which processes multimedia data at kernel privilege, turned out to be a treasure trove of exploitable bugs throughout 2023 and 2024. The type confusion pattern here is instructive: when a driver stores different structure types through the same pointer without tagging, every IOCTL handler that casts that pointer becomes a potential type confusion target. The fix (adding a type tag check) is simple, but the fact that it was missing in the first place reflects the challenge of maintaining type safety in C-based kernel code where polymorphism is done through void pointers and convention.

References

• MSRC Advisory
• Writeup
• PoC