CVE-2023-36874 is a filesystem redirection vulnerability that relies on a trusted process using relative filepath data and poor file validation to allow a malicious actor to escalate privilege on Windows 10 hosts.

How it is supposed to work

The Windows Error Reporting Service (WER) is a privileged (SYSTEM) process that handles errors on Windows systems. It is not meant for user interaction, so many of the ways to interact with it are undocumented COM interfaces.
Through a non-trivial set of calls to COM objects, a user can create an IWerReport COM object. Once the user has that object, they can make a call to submit a report file associated with that object. The file must be located in %PROGRAMDATA%\Microsoft\Windows\WER\ReportArchive\<reportdir>\.
As part of the report submission process, the WER service calls CreateProcess and passes it the executable responsible for handling the WER report, %WINDIR%\system32\wermgr.exe. This results in the wermgr.exe process launching as SYSTEM and handling the reporting.

The Vulnerability

There are two issues at play fort his vulnerability: one is that rather than using the absolute filepath to the wermgr.exe file as above, the CreateProcess function is handed a relative filepath to the wermgr.exe executable based on the location of the error report, so the WER service launches ..\..\..\..\..\..\system32\wermgr.exe with the origination directory as the directory containing the WER report to submit, and the second is that neither file is checked for a symbolic link before it is opened.
That means that a user can:

1. Create a WER report in C:\arbitrary_dir\ProgramData\Microsoft\Windows\WER\ReportArchive\Report\<report_dir>\Report.wer
   
2. Place any executable in C:\arbitrary_dir\system32\ named wermgr.exe
   
3. Create a symbolic link between C:\ProgramData\Microsoft\Windows\WER\ReportArchive\<reportdir>\ and C:\arbitrary_dir\ProgramData\Microsoft\Windows\WER\ReportArchive\Report\<report_dir>\
   
4. Create the IWerReport COM object
   
5. Submit the COM object paired with the report in C:\ProgramData\Microsoft\Windows\WER\ReportArchive\<reportdir>\
   This results in ..\..\..\..\..\..\system32\wermgr.exe being opened as system, and as the symlink created a redirect, it will launch whatever executable we have stored as C:\arbitrary_dir\system32\wermgr.exe
   

Mitigation

Microsoft released a patch for this vulnerability, so the first suggestion is to patch. Alternatively and additionally, because this vulnerability requires an executable file named wermgr.exe and a report named Report.wer, a host-based protection might be simply to ensure that any file named wermgr.exeoutside the legitimate%WINDIR%\system32directory flagged and quarantined. The same tactic could be applied to theReport.werfiles outside the proper structure. Another option might be to prevent symbolic link calls withsystem32` as a directory destination.