OS Command Injection via Placeholder Substitution

The --exec-on-reception and --exec-on-eostudy flags configure storescp to execute a shell command when a DICOM object is received. Placeholder tokens in the command string are substituted with values from the incoming DICOM association and passed to /bin/sh -c.

Three placeholder tokens accept attacker-controlled input: #f (filename, derived from SOP Instance UID), #p (path, derived from Study Instance UID when using --sort-on-study-uid), and #r (reverse DNS hostname of the caller).

The #f and #p placeholders are processed by sanitizeFilename(), which replaces path separator characters:

void OFStandard::sanitizeFilename(OFString& fname)
{
    const size_t len = fname.length();
    for (size_t i = 0; i < len; ++i)
    {
        if (fname[i] == PATH_SEPARATOR) fname[i] = '_';
    }
}

Shell metacharacters such as semicolons, pipes, backticks, and dollar signs are not affected by this sanitization. The substituted command is passed to the shell:

execl("/bin/sh", "/bin/sh", "-c", cmd.c_str(),
      OFreinterpret_cast(char *, 0));

The #r placeholder (reverse DNS hostname) is not sanitized before substitution. An attacker who controls the PTR record for their IP address can inject shell metacharacters through the resolved hostname.

In February 2024, the #a and #c placeholders (AE title tokens) received allowlist-based sanitization via sanitizeAETitle() (issue #1109). The #f, #p, and #r placeholders were not included in that change.

DICOM UID fields have a maximum length of 64 characters and whitespace is stripped by the parser. These constraints limit payload length but can be worked around using shell parameter expansion.

Note: VulDB currently lists this vulnerability at CVSS 7.3 (C:L/I:L/A:L). We believe the impact metrics should be C:H/I:H/A:H given the confirmed code execution capability, and have contacted VulDB regarding this scoring.