Remote Code Execution via Vendor-Data Extraction

Description

Path basePath = Paths.get(URI.create(StringUtils.replaceSystemProperties(unzipTo)));
ZipInputStream input = new ZipInputStream(new ByteArrayInputStream(vendorData[0]));
ZipEntry entry;
try {
    while ((entry = input.getNextEntry()) != null) {
        if (!entry.isDirectory()) {
            Path filePath = basePath.resolve(entry.getName());
            Files.createDirectories(filePath.getParent());
            Files.copy(input, filePath, StandardCopyOption.REPLACE_EXISTING);
        }
    }
} catch (IOException e) {
    LOG.error("Failed to extract Device Vendor Data", e);
}

Impact

• Code execution in the archive process carries the archive's own access to the imaging record it holds. The process is the custodian of the stored DICOM objects and of the database that indexes them, so studies and the patient identifiers attached to them can be read, altered, or deleted, and the credentials the archive holds for its own backing services are readable in that context.
• Independently of the deployment step, the same primitive is an arbitrary file write as the archive service account. Files outside the deployment directory can be created or replaced, which reaches application server configuration and any startup script or trust store the account can write.
• Severity is rated against the deployment the project's own documentation presents first, in which the configuration interface answers without authentication. Where the secured build is deployed instead, the configuration interface requires only the base role that the shipped low-privilege account already holds, so the chain remains reachable by any authenticated user rather than being closed.

Mitigation

Upgrade to dcm4chee-arc-light 5.35.1 or later, which rejects vendor-data ZIP entries resolving outside the unpack directory and constrains the unpack directory to the application server's temporary subtree or to a location entirely outside the application server home. Note that 5.35.0 closes only the first variant. Until upgraded, operators can reduce exposure by leaving dcmUnzipVendorDataToURI unset, which disables extraction entirely, by restricting the configuration and control interfaces and the LDAP configuration backend to trusted networks, and by disabling the application server's deployment scanner on installations that do not hot-deploy.

Defender's Checklist

• Check whether vendor-data extraction is switched on at all.

  Extraction only happens when dcmUnzipVendorDataToURI is set on the archive device. If your deployment does not rely on vendor data, leaving it unset removes the code path. Confirm the current value in your LDAP or JSON configuration backend rather than assuming the default.

• Upgrade to 5.35.1, not 5.35.0.

  5.35.0 fixes the traversing entry name but still allows the unpack directory to be redirected through configuration. Only 5.35.1 constrains where that directory may point, and note the shape of the constraint: a directory outside the application server home is still permitted, so a deployment that unpacks vendor data to its own path elsewhere on the filesystem keeps working. If you already moved to 5.35.0 for the other findings in this batch, this one is still open.

• Restrict the configuration and control interfaces.

  Both variants start from a configuration write and a reload. The archive provides no way to restrict its device and control resources to administrators separately from ordinary users, so the boundary has to be enforced outside the application, at a reverse proxy or on the network. The LDAP configuration backend needs the same treatment, since writing configuration there reaches the same code path.

• Turn off the deployment scanner where it is not needed.

  The step that converts a file write into code execution is the application server picking up an archive from its deployments directory. Installations that deploy once and do not hot-deploy can disable the scanner, which removes that step for this finding and for the storage-descriptor write covered in the related advisory.

• Treat an exposed archive as having disclosed its configuration secrets.

  If the configuration interface was reachable from an untrusted network, assume the credentials held in archive configuration for the database, the storage backends, and the LDAP backend are known, and rotate them.

Severity Reasoning

References

• GHSA-hxq8-xgh3-4f76 (dcm4che)
• dcm4chee-arc-light issue 4985 (reject entries outside the unpack directory)
• dcm4chee-arc-light issue 5034 (constrain the unpack directory)
• dcm4chee-arc-light 5.35.1 release
• dcm4chee-arc-light Repository
• Related: Storage-Descriptor File Write in dcm4chee-arc-light
• Related: XSLT Attribute-Coercion Injection in dcm4chee-arc-light
• Related: XML External Entity Injection in dcm4chee-arc-light

How We Can Help

• MDR Penetration Testing
• §17 MPBetreibV Compliance