Micropatches for Two Similar Remote Code Execution Issues (CVE-2022-21971*, CVE-2022-21974*)



by Mitja Kolsek, the 0patch Team


Twelve days ago, security researcher Axel Souchet published detailed analyses with associated proofs-of-concept for two remotely exploitable vulnerabilities in Windows that were fixed by Microsoft with February Windows Updates. Both vulnerabilities are similar and are caused by an uninitialized pointer that a malicious RTF file can get freed while having an illegal value.

Exploitability of such issues depends on whether the attacker can get the uninitialized value to point to a chosen address and thus control the resulting memory corruption. We don't know if this is possible but following the worst-case assumption principle (and historical track record showing that to be generally possible with sufficient motivation), unexplored memory corruption issues are assumed to allow for a remote code execution.

The two vulnerabilities are:

  1. CVE-2022-21971* - see Axel's POC with analysis
  2. CVE-2022-21974* - see Axel's POC with analysis

* A quick note on CVE IDs here: While Axel found these vulnerabilities, he was not the only one: Microsoft had fixed them before he reported them so he was not acknowledged in Microsoft's advisories. This introduces a level of uncertainty on whether the above CVE IDs really match his findings. We can be sure that February Windows Updates fixed both these issues, but it is quite possible that they were fixed silently without having CVE IDs assigned at all, or that just one of them got a CVE ID. Quoting Axel's tweet: "Yeah it very well might be wrong - I theorized that if you found the former you'd find the latter so I looked for findings from the same finders." His reasoning makes sense to us but we'll continue trying to get confirmation about CVE IDs and will update this blog post as needed.

It was trivial to reproduce both issues by simply enabling Page Heap for WordPad.exe and opening Axel's RTF documents with WordPad. While WordPad requires the user to unblock content in a security warning, opening the same document in Microsoft Word produces no warnings. We preferred using WordPad for our analysis, however, as it is present on Windows by default.

Our analysis of Microsoft's fixes for these issues revealed that, unsurprisingly, they just added pointer initialization to constructor code. The image below shows a diff between vulnerable (left) and fixed constructor (right) in RMSRoamingSecurity.dll., and something similar was done in prauthproviders.dll as well.


Our micropatches are logically equivalent to Microsoft's. They were written for the following Windows versions that don't receive official patches from Microsoft:

  1. Windows 10 v1803 updated to May 2021
  2. Windows 10 v1809 updated to May 2021
  3. Windows 10 v2004 updated to December 2021

Note that Windows 7 and Server 2008 R2 are not affected as the vulnerable functionalities do not exist there. 


Here is a video showing how 0patch blocks exploitation of these vulnerabilities:


These micropatches have already been distributed to all online 0patch Agents with a PRO or Enterprise license. To obtain them and have them applied on your computers along with our other micropatches, create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center

We'd like to thank Axel Souchet for publishing their analyses and providing proofs-of-concept that allowed us to reproduce these vulnerabilities and create micropatches for them. We also encourage security researchers to privately share their analyses with us for micropatching.

Article Link: 0patch Blog: Micropatches for Two Similar Remote Code Execution Issues (CVE-2022-21971*, CVE-2022-21974*)