Maddie Stone & James Forshaw

The Basics

Disclosure or Patch Date: November 08, 2022

Product: Windows

Advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-41073

Affected Versions: pre-KB5019980 (Win 11), pre-KB5019959 (Win 10)

First Patched Version: KB5019980 (Win 11), KB5019959 (Win 10)

Issue/Bug Report: N/A

Patch CL: N/A

Bug-Introducing CL: N/A

Reporter(s): Microsoft Threat Intelligence Center (MSTIC)

The Code

Proof-of-concept: See exploit sample

Exploit sample: https://www.virustotal.com/gui/file/e8a94466e64fb5f84eea5d8d1ba64054a61abf66fdf85ac160a95b204b7b19f3/details

Did you have access to the exploit sample when doing the analysis? Yes

The Vulnerability

Bug class: Logic vulnerability in activation context generation

Vulnerability details:

The root vulnerability is that a user can remap the root drive (C:\) for privileged processes during impersonation, a design flaw that has been known about since at least 2015. While Microsoft described this vulnerability as a "Print Spooler" vulnerability that was simply how this vulnerability was exploited, not the root vulnerability.

In this case, the root vulnerability was abused during Activation Context generation. On Windows, an activation context tells an application what files to load: the path, file version, etc. Activation contexts can be populated by manifests which may be included in a PE as a resource, or as a separate file. Manifests can also declare that an application is dependent on a specific side-by-side assembly. CSRSS is the process responsible for activation context generation.

Impersonation is used by many privileged processes in Windows. During impersonation, all file accesses are performed using the DOS device map of the impersonated process. This means if the user has used symbolic linking to re-map the C: drive, the privileged drive will now use the remapped path. In this case, that means the CSRSS will use a user-modified side-by-side manifest for generating the activation context, rather than the manifest in C:\Windows\WinSxS, a location not writeable by regular users. The manifest is modified to define an additional dependentAssembly.

Patch analysis:

This bug was patched in multiple parts: the first patch in November 2022 broke the exploit, in December a broader mitigation was added to CSRSS though it was not enabled for this bug yet, and in January 2022 it was enabled for this exploit sample by enabling the mitigation for the printfilterpipelinesvc.exe process. As of May 2022, the CSRSS mitigation is only enabled for spoolsv.exe and printfilterpipelinesvc.exe. In addition, the CSRSS mitigation is only able to be enabled for “system” services.

The patch in November patched winspool.drv. The patch simply stopped any impersonation prior to the call to LoadLibraryExW in winspool!LoadNewCopy and then resumed it after the LoadLibraryExW call had returned.

+ if (RevertToProcess(&TokenHandle, x) >= 0) {
	lib = LoadLibraryExW(arg1, 0, dwFlags);
+ 	ResumeImpersonation(TokenHandle);
+ }

In December 2022, a broader mitigation was added to CSRSS. If checks pass, the mitigation would call NtOpenFile with OBJ_IGNORE_IMPERSONATED_DEVICEMAP which tells NtOpenFile to use the process's own device map, not the impersonated one. The mitigation is only enabled if the process calling into CSRSS explicitly enables the mitigation. In December, spoolsv.exe is the only process that explicitly enables it. In January 2022, printfilterpipelinesvc.exe also enabled the mitigation.

Thoughts on how this vuln might have been found (fuzzing, code auditing, variant analysis, etc.): CVE-2022-41073 is the same bug as CVE-2022-29104, which was fixed in May 2022 and whose POC was available on VirusTotal in July 2022. It's likely that this bug was found via that POC (or earlier).

(Historical/present/future) context of bug:

The Exploit

(The terms exploit primitive, exploit strategy, exploit technique, and exploit flow are defined here.)

Exploit strategy (or strategies):

To exploit this bug, a privileged process that loads a DLL under impersonation that is dependent on a side-by-side assembly is needed.

This exploit uses printfilterpipelinesvc.exe as the target process. printfilterpipelinesvc is a local service that runs with SYSTEM integrity. After starting the printfilterpipelinesvc process, the exploit will create a symbolic link to the C: drive, changing the C: drive root. When the exploit calls printfilterpipelinesvc!SplPipeline::SplFilterPipelineCallObject::Begin_Print this will ultimately lead to winspool!LoadNewCopy running. LoadNewCopy calls LoadLibraryExW("C:\Windows\System32\DriverStore\FileRepository\prnms003.inf_amd64_378cd1cfb571f1b/Amd64/PrintConfig.dll"). Due to the fix for CVE-2015-1644 where Microsoft introduced a new flag, OBJ_IGNORE_IMPERSONATED_DEVICEMAP which turns off impersonation during LoadLibrary, the legitimate PrintConfig.dll will be loaded. However, during the loading process CSRSS will create the activation context for PrintConfig.dll. The PrintConfig manifest is dependent on the SxS (side-by-side) manifests. When looking for these manifests, impersonation is NOT taken into account so CSRSS will read the manifests that were modified by the exploit rather than the legitimate ones. The exploit modified the manifest to include a dependency to its custom path which includes a new custom manifest. This custom manifest then loads modified DLLs which are now running at the SYSTEM integrity level.

Exploit flow:

This bug is used to change the root C: drive such that an arbitrary DLL is loaded by a privileged process.

Known cases of the same exploit flow: Many cases, but the closest is CVE-2022-29104 that was patched in May 2022.

Part of an exploit chain? Yes, this bug is an LPE so there would have likely been an initial RCE paired with it.

The Next Steps

Variant analysis

Areas/approach for variant analysis (and why):

The CSRSS mitigation is only enabled for spoolsv.exe and printfilterpipelinesvc.exe. Look for any other vulnerable processes.

Found variants:

Structural improvements

What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.?

Ideas to kill the bug class: Stop allowing the user to remap the root C: drive

Ideas to mitigate the exploit flow: Enable the CSRSS mitigation for all processes

Other potential improvements:

0-day detection methods

What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected as a 0-day?

Looking for applications that remap the 'C:' drive.

Other References