Remote Code Execution über Storage-Descriptor File Write

Ein Storage-Descriptor legt fest, wohin das Archiv die empfangenen Objekte legt. Zwei seiner Felder bestimmen das Ziel: die Storage-URI als Wurzelverzeichnis im Dateisystem und das Storage-Path-Format, eine Vorlage, die gegen die Attribute des gespeicherten Objekts ausgewertet wird. Beide sind gewöhnliche Konfiguration. Der Setter für das Wurzelverzeichnis übernimmt, was er bekommt, ohne Positivliste zulässiger Schemata und ohne Prüfung, ob das Ergebnis den vorgesehenen Bereich verlässt:

public void setStorageURIStr(String str) {
    this.storageURI = URI.create(StringUtils.replaceSystemProperties(str));
    this.storageURIStr = str;
}

Beim Schreiben werden Wurzelverzeichnis und ausgewertete Pfadvorlage zusammengesetzt und direkt geöffnet:

protected OutputStream openOutputStreamA(WriteContext ctx) throws IOException {
    Path path = Paths.get(rootURI.resolve(ctx.getStoragePath()));
    Path dir = path.getParent();
    createDirectories(dir);
    while (true)
        try {
            ctx.setStoragePath(rootURI.relativize(path.toUri()).toString());
            return Files.newOutputStream(path, descriptor.getFileOpenOptions());

Es gibt nichts, woraus man ausbrechen müsste, weshalb in diesem Fund an keiner Stelle eine Traversal-Sequenz vorkommt. Wer die Konfiguration schreiben kann, setzt das Wurzelverzeichnis auf das gewünschte Verzeichnis und die Pfadvorlage auf den gewünschten Dateinamen, und das Archiv schreibt dorthin, weil es genau das angewiesen bekommen hat. Die Pfadvorlage greift auf Attribute des gespeicherten Objekts zu, die derselbe Aufrufer liefert, sodass auch Dateiname und Endung steuerbar sind.

Der Schritt vom gesteuerten Schreibvorgang zur Codeausführung nutzt dieselbe Eigenschaft des Applikationsservers wie der im verwandten Advisory beschriebene Vendor-Data-Fund: Ein Archiv, das im Deployments-Verzeichnis auftaucht, wird aufgenommen und deployt. Damit dort eine deploybare Datei landet, braucht es zwei Eigenschaften des Speicherpfads. Ein Encapsulated-PDF-Objekt trägt sein Dokument in einem Bulk-Data-Attribut, und das Archiv kodiert das Objekt beim Speichern zwar neu, reicht dieses Attribut aber unverändert durch, statt es durch einen Bild-Codec zu schicken. Ein eingebettetes Archiv übersteht das also unversehrt, und als Element mit der höchsten Nummer folgt ihm im geschriebenen Dataset nichts mehr. Auf der Platte landet damit das vollständige DICOM-Objekt und nicht nur das Archiv. Deploybar bleibt es trotzdem, weil ein Archiv-Reader das ZIP-Inhaltsverzeichnis vom Dateiende her sucht und die vorangestellte DICOM-Präambel samt Element-Headern deshalb als führender Ballast toleriert wird.

Dieser Ballast kostet den Angreifer allerdings etwas, und das gehört zur genauen Darstellung dazu: Der Deployment-Scanner des Applikationsservers führt eine Vollständigkeitsprüfung durch und liest eine Datei mit vorangestelltem Ballast als noch im Kopiervorgang befindlich. Der erste Schreibvorgang deployt also für sich genommen nicht. Dazu kommt es erst, wenn eine passende Marker-Datei den Scanner zum Fortfahren veranlasst, die dasselbe Primitiv aus Konfiguration und Speichervorgang erzeugen kann. Die Kette besteht aus zwei Schreibvorgängen statt aus einem, weshalb die Angriffskomplexität niedrig bleibt, der Fund aber kein einzelner Request ist.

Codeausführung ist der schwerste, aber nicht der einzige Ausgang. Dasselbe Primitiv schreibt ohne den Deployment-Schritt wohlgeformte und vollständig lesbare DICOM-Studien an gewählte Orte, was genügt, um Bildmaterial in ein Archiv zu legen, das kein bildgebendes Gerät erzeugt hat. Die File-Open-Options sind selbst ein Konfigurationsfeld; werden sie über dieselbe Schnittstelle von der Voreinstellung (nur anlegen, wenn nicht vorhanden) auf einen überschreibenden Modus umgestellt, wird aus dem Anlegen neuer Dateien das Überschreiben bestehender.

Der Fix löst jeden Speicherpfad gegen sein Wurzelverzeichnis auf und weist jedes Ergebnis zurück, das dieses verlässt. Zusätzlich verweigert er ein Wurzelverzeichnis, das innerhalb des Home-Verzeichnisses des Applikationsservers außerhalb des nun dafür vorgesehenen Speicherbereichs liegt. Die Standard-Storage-Location wurde im selben Release in diesen Bereich verschoben.

dcm4chee-arc-light ist das DICOM-Archiv und der Image Manager des dcm4che-Projekts und wird von Kliniken, Forschungsgruppen und Herstellern als offene Infrastruktur für Speicherung und Austausch medizinischer Bilddaten eingesetzt. Wir schätzen die langjährige Arbeit des Projekts an dieser Infrastruktur und die Sorgfalt, mit der die Maintainer diesen Bericht behandelt haben. Wir haben den Fund im Juni 2026 vertraulich an J4Care gemeldet; das Projekt hat konstruktiv reagiert und einen Fix veröffentlicht.