When a C++ developer receives a crash dump from a user, the natural response is to open it immediately in whatever analysis tool is at hand. The dump came from the user's machine. It is a diagnostic file. What could go wrong?
Quite a lot, as it turns out. A crash dump is a raw copy of process memory, and some of that memory is attacker-controlled. The format itself has fields a malicious actor can craft to trigger exploits in the tool reading it. This post covers the three most realistic attack vectors and what CrashCatch v1.0.0 does to defend against each one.
Attack 1: Parser exploits via crafted dump files
The Windows minidump format (MDMP) is not simple. It is a binary format with streams, directories, memory descriptors, and nested structures that point into the file. A parser must follow pointers, read lengths from attacker-controlled data, and allocate memory based on values it reads from the file.
Vulnerabilities in dump parsers are not theoretical. DbgHelp.dll, the Windows library used to parse minidumps, has had CVEs. Third-party crash analysis tools have had them too. The attack surface is any tool that opens an untrusted .dmp file without first validating that it is actually a minidump.
The most basic defense is magic byte validation: check that the first four bytes of the file are 4D 44 4D 50 (the ASCII string "MDMP") before parsing begins. If the bytes are not present, the file is not a minidump and should be rejected. This eliminates the entire class of attacks that involve disguising a non-dump file with a .dmp extension.
CrashCatch enforces magic byte validation as the first step before any parsing. Files that do not match are rejected with an error message, and no further bytes of the file are read.
Attack 2: Memory exhaustion via oversized dumps
Legitimate minidumps are small. A full minidump with heap data from a typical application is under 200 MB. A MiniDumpWithFullMemory dump of a large application might reach a few hundred megabytes. Anything over 500 MB is almost certainly not a legitimate dump from a normal application.
An attacker who can get you to open a crafted file can craft a dump with a header claiming the file is several gigabytes. A naive parser will attempt to allocate that memory. On a 32-bit process this causes an immediate crash. On a 64-bit process it can exhaust available RAM and virtual address space, causing the analysis tool and potentially other running processes to fail.
CrashCatch enforces a 500 MB size cap checked against the file's actual size on disk before any parsing begins. Files above the cap are rejected. This prevents the parser from ever attempting to allocate attacker-controlled amounts of memory.
Attack 3: NTLM credential theft via UNC symbol paths
This attack is subtler and specific to crash analysis tools that support symbol loading. It works as follows.
When CrashCatch analyzes a dump, it reads the module list embedded in the dump. Each module entry can contain a path where the module's PDB file was located at build time. This path is written into the dump by the compiler and linker at build time and is typically something like C:\src\MyApp\x64\Release\MyApp.pdb.
But nothing in the MDMP format requires the PDB path to be a local path. An attacker who can control the build process, or who can modify a dump file after it is generated, can set the PDB path to a UNC path: \\attacker.example.com\fake\MyApp.pdb.
When the analysis tool tries to load symbols, Windows attempts to connect to attacker.example.com over SMB. SMB connections on Windows use NTLM authentication by default. Your machine sends an NTLM challenge response to the server. The server logs it. With a captured NTLM hash and a GPU cluster, the hash can be cracked offline. On a domain machine, the hash can often be used directly in a pass-the-hash attack without cracking.
The attacker never needs code execution. They just need you to open a dump file while your symbol loader is configured to follow UNC paths.
How CrashCatch blocks this
CrashCatch v1.0.0 blocks UNC paths at the settings level. When you configure symbol search paths, any path beginning with \\ is rejected with an error. You cannot save a UNC path to settings, and the symbol loader will not follow UNC paths embedded in dump module entries.
This block applies regardless of whether the UNC path came from your settings or from data inside a dump file. If the resolved PDB path for any module is a UNC path, it is skipped.
What about dumps you receive from users
The most common scenario where these attacks are relevant: a user submits a crash dump by email or through a support channel, and a developer on your team opens it directly.
For dumps from your own application collected by the CrashCatch Runtime SDK, the risk is low. The SDK writes dumps in a controlled environment, and the PDB paths come from your own build system. You know where those paths point.
For dumps collected by your users' own crash collectors, or dumps submitted through arbitrary channels, treat the file as untrusted. The protections in CrashCatch v1.0.0 are designed for exactly this scenario: magic byte validation, size cap enforcement, and UNC path blocking all apply before and during analysis of any dump file, regardless of its source.