Home Exploiting WinDbg's Source Indexing

Exploiting WinDbg's Source Indexing

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:

  1. Generation of crash dump at user side
  2. Sending the crash dump to some dump collection server
  3. Automatic triage
  4. Notify developers about new bug
  5. Developer doing manual triage

This process is already very complex and prone to vulnerabilities, but today we will focus on stage #5.


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.


Products affected

  • WinDbg 10.0.19041.685
  • Microsoft Source Server (srcsrv.dll) 10.0.19041.685


  • Security feature bypass
  • Local privilege elevation
  • Remote code execution
  • Code injection


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. Srcsrv stream content example

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: Source server consent dialog

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.

Vulnerable code

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=\\\box\1337\

Example setting

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.

Default value of PDB path in CV_INFO_PDB70 structure

 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.

WinDbg loads attacker-supplied DLL

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
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Trending Tags




Post comment
Trending Tags