# CVE-2022-41073: Windows Activation Contexts EoP
*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](https://learn.microsoft.com/en-us/windows/win32/sbscs/activation-contexts) 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](https://learn.microsoft.com/en-us/windows/win32/sbscs/about-side-by-side-assemblies-). 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`](https://learn.microsoft.com/en-us/windows/win32/sbscs/assembly-manifests?source=recommendations#:~:text=No-,dependentAssembly,-No). 

**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. 

```c
+ 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](https://msrc.microsoft.com/update-guide/en-us/vulnerability/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:** 

* 2015 - DosDevices Impersonation bug reported: https://bugs.chromium.org/p/project-zero/issues/detail?id=240
* May 2022: [CVE-2022-29104](https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2022-29104) is patched
* July 2022: [CVE-2022-22047](https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2022-22047), an in-the-wild 0-day in activation contexts is patched
* Nov 2022: 1st patch for CVE-2022-41073 released

## The Exploit

(The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).)

**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](https://bugs.chromium.org/p/project-zero/issues/detail?id=240) 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 

* https://bugs.chromium.org/p/project-zero/issues/detail?id=240
* https://www.zerodayinitiative.com/blog/2023/1/23/activation-context-cache-poisoning-exploiting-csrss-for-privilege-escalation