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::InitializeContextFsContextReg
Root Cause
The mskssrv.sys driver is the Kernel Streaming Service Proxy, which 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.
The vulnerability is a type confusion between two distinct file context structures: FsContextReg (a registration context) and FsStreamReg (a stream context). Both structure types are stored in the same FILE_OBJECT.FsContext field but have entirely different layouts and semantics. An attacker can open two different types of handles to the mskssrv device -- one that causes the driver to allocate an FsContextReg and another that causes it to allocate an FsStreamReg. By sending IOCTLs that are designed for one context type to a handle associated with the other context type, the driver misinterprets the structure layout.
Because fields at the same offset in the two structures have different meanings (e.g., a length field in one may correspond to a pointer field in the other), an attacker who controls the values written into one structure type effectively controls what the driver interprets as pointers, sizes, or flags when it processes that memory as the other structure type. This is the core of the type confusion: the driver blindly trusts that FsContext points to the expected structure without verifying its actual type.
AutoPiff categorizes this as type_confusion with detection rules:
object_type_validation_added
Exploitation
The type confusion yields controlled pointer dereferences in kernel mode. When the driver reads fields from the FsContext structure assuming it is an FsStreamReg but the underlying memory is actually an FsContextReg, the values the driver follows as kernel pointers or buffer lengths are attacker-controlled values that were written through the registration interface.
Exploitation proceeds as follows: the attacker creates both context types by opening separate handles, then manipulates values in the FsContextReg to place controlled data at offsets that correspond to pointer or size fields in the FsStreamReg layout. The attacker then sends IOCTLs on the handle whose context is the manipulated FsContextReg, but which the driver processes using FsStreamReg semantics. The driver dereferences attacker-controlled values as kernel pointers.
By carefully crafting the context contents, the confused pointer dereferences can be turned into an arbitrary kernel read/write primitive. From there, the standard privilege escalation path applies: the attacker locates the current process token and overwrites it with the SYSTEM token (token swapping), achieving local elevation of privilege to SYSTEM.
Patch Analysis
The patch shipped in KB5030219 (build 10.0.22621.2283) added explicit object type validation on the FsContext structure before processing IOCTLs. In the vulnerable version, the driver cast FILE_OBJECT.FsContext directly to the expected structure type without any verification. The patched code now checks a type tag embedded in the context structure to confirm that the FsContext type matches the expected context type for the requested IOCTL operation, returning an error if the types do not match.
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\MSKSSRVwith different creation parameters to instantiate bothFsContextRegandFsStreamRegcontext 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
EPROCESSstructure, observable as a low-integrity process suddenly holding the SYSTEM token without going through standard elevation mechanisms - Abnormal
NtDeviceIoControlFilecall patterns targeting the MSKSSRV device from a process that is not a media application or streaming service