DICOM PS3.10 2020b - Media Storage and File Format for Media Interchange

7.5 Security Considerations for DICOM File Format (Current)
Prev | 7 DICOM File Format | Next

## 7.5 Security Considerations for DICOM File Format

The DICOM File Format has a potential security vulnerability when the 128-byte File Preamble contains malicious executable content. Such malicious executable content may also refer to other malicious content in the file hidden within Data Elements of the File Meta Information or the Data Set.

Depending upon the use and purpose of a particular application it may be appropriate to:

- Sanitize the preamble, such as by:

  - Verifying that the preamble is:

    - all zeroes, or

    - begins with a valid magic number for recognized dual format content (e.g., TIFF or BigTIFF), or

    - contains other known safe content.

  - Clearing the preamble regardless of its content

    ### Note

    This will prevent use by applications that depend on the non-DICOM format, if the dual format capability has been used.

  - Testing explicitly for executable preamble contents.

    ### Note

    The proper response to the presence of executable content depends upon the purpose of the application, but generally, legitimate executable content will not be found in a DICOM File. A hypothetical example of an exception would be if the file contained its own executable viewer; this is sufficiently unlikely as to be not worth considering.

- Test explicitly for executable content anywhere within the DICOM File.

- Validate that the DICOM values, structures and content comply with the standard encoding rules and the IOD of the specified SOP Class, including Private Data Elements.

  ### Note

  Validation that Data Element Values comply with their Value Representation may partially mitigate the risk of hidden malicious content, but it may be necessary to remove or analyze the contents of opaque binary data in OB or other binary numeric value Data Elements, whether they be Standard or Private Data Elements. The VR of Private Data Elements may not be known. Without an executable preamble, such hidden content may not be directly executable, but may still serve as a repository of malicious code to be activated by some other accompanying exploit.

- Validate that the contents are of the appropriate SOP Classes.

- Validate that DICOM File Format files created for HTTP requests and responses do not contain such malicious content.

  ### Note

  For example, it may be appropriate for an archive that stores and retrieves PS3.10 Files to verify and validate both input and output, rather than store and retrieve files without checking the content.

The proper response to a validation failure depends upon the purpose of the application. Validation might be performed on input, output, or both.

### Note

For example, an archive may choose to sanitize SOP Instances upon receipt, sanitize SOP Instances upon retrieval, validate the structure and fail storage requests for SOP Instances that fail validation, or other behavior based on the product purpose and the threat environment. This behavior is not specified by DICOM because the product purpose and the threat environment are highly dependent upon the application.

An implementation shall describe in its Conformance Statement its behavior with respect to sanitization of the preamble and any other validation performed.

Prev | Up | Next
7.4 Secure DICOM File Format | Home | 8 DICOM File Service

DICOM PS3.10 2020b - Media Storage and File Format for Media Interchange