7.8 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.1 High
AI Score
Confidence
High
0.059 Low
EPSS
Percentile
93.5%
Windows Error Reporting Service Elevation of Privilege Vulnerability
Recent assessments:
bwatters-r7 at January 17, 2024 4:54pm UTC reported:
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.
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.
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:
Create a WER
report in C:\arbitrary_dir\ProgramData\Microsoft\Windows\WER\ReportArchive\Report\<report_dir>\Report.wer
Place any executable in C:\arbitrary_dir\system32\
named wermgr.exe
Create a symbolic link between C:\ProgramData\Microsoft\Windows\WER\ReportArchive\<reportdir>\
and C:\arbitrary_dir\ProgramData\Microsoft\Windows\WER\ReportArchive\Report\<report_dir>\
Create the IWerReport
COM object
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
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 the
Report.werfiles outside the proper structure. Another option might be to prevent symbolic link calls with
system32` as a directory destination.
Assessed Attacker Value: 4
Assessed Attacker Value: 4Assessed Attacker Value: 3
7.8 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.1 High
AI Score
Confidence
High
0.059 Low
EPSS
Percentile
93.5%