Remote Code Execution über Vendor-Data-Extraktion

Beschreibung

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);
}

Auswirkung

• Codeausführung im Archivprozess bringt den Zugriff mit sich, den das Archiv selbst auf den von ihm verwalteten Bildbestand hat. Der Prozess verwahrt die gespeicherten DICOM-Objekte und die Datenbank, die sie indexiert. Studien und die daran hängenden Patientenkennungen lassen sich daher lesen, verändern oder löschen, und die Zugangsdaten, die das Archiv für seine eigenen Backend-Dienste hält, sind in diesem Kontext lesbar.
• Unabhängig vom Deployment-Schritt ist dasselbe Primitiv ein beliebiger Schreibzugriff im Dienstkonto des Archivs. Dateien außerhalb des Deployments-Verzeichnisses lassen sich anlegen oder ersetzen, was die Konfiguration des Applikationsservers sowie jedes Startskript und jeden Trust Store erreicht, die das Konto schreiben kann.
• Die Bewertung bezieht sich auf die Bereitstellung, die die Projektdokumentation zuerst vorstellt und in der die Konfigurationsschnittstelle ohne Authentifizierung antwortet. Wird stattdessen der abgesicherte Build betrieben, verlangt die Konfigurationsschnittstelle lediglich die Basisrolle, die das mitgelieferte Konto mit geringen Rechten ohnehin besitzt. Die Kette bleibt dort für jeden authentifizierten Nutzer erreichbar und ist nicht geschlossen.

Abhilfe

Auf dcm4chee-arc-light 5.35.1 oder neuer aktualisieren, wo Vendor-Data-ZIP-Einträge außerhalb des Entpackverzeichnisses zurückgewiesen und das Entpackverzeichnis auf den temporären Bereich des Applikationsservers oder einen Ort vollständig außerhalb des Applikationsserver-Homes begrenzt wird. Zu beachten: 5.35.0 schließt nur die erste Variante. Bis dahin lässt sich die Angriffsfläche verringern, indem dcmUnzipVendorDataToURI ungesetzt bleibt, was das Entpacken vollständig abschaltet, indem Konfigurations- und Steuerungsschnittstellen sowie das LDAP-Konfigurationsbackend auf vertrauenswürdige Netze beschränkt werden, und indem der Deployment-Scanner des Applikationsservers auf Installationen ohne Hot-Deployment deaktiviert wird.

Checkliste für Betreiber

• Prüfen, ob die Vendor-Data-Extraktion überhaupt aktiv ist.

  Entpackt wird nur, wenn dcmUnzipVendorDataToURI am Archivgerät gesetzt ist. Nutzt die Installation keine Vendor-Data, entfällt der Code-Pfad, wenn der Wert ungesetzt bleibt. Den aktuellen Wert im LDAP- oder JSON-Konfigurationsbackend nachsehen, statt die Voreinstellung anzunehmen.

• Auf 5.35.1 aktualisieren, nicht auf 5.35.0.

  5.35.0 behebt den traversierenden Eintragsnamen, erlaubt aber weiterhin, das Entpackverzeichnis über die Konfiguration umzubiegen. Erst 5.35.1 schränkt ein, wohin dieses Verzeichnis zeigen darf, und die Form der Einschränkung ist zu beachten: Ein Verzeichnis außerhalb des Applikationsserver-Homes bleibt zulässig, sodass eine Installation, die Vendor-Data an einen eigenen Pfad anderswo im Dateisystem entpackt, weiterhin funktioniert. Wer wegen der übrigen Funde dieser Reihe bereits auf 5.35.0 gegangen ist, hat diesen hier noch offen.

• Konfigurations- und Steuerungsschnittstellen einschränken.

  Beide Varianten beginnen mit einem Konfigurationsschreibzugriff und einem Reload. Das Archiv bietet keine Möglichkeit, seine Geräte- und Steuerungsressourcen getrennt von gewöhnlichen Nutzern auf Administratoren zu beschränken, weshalb die Grenze außerhalb der Anwendung gezogen werden muss, an einem Reverse Proxy oder im Netz. Das LDAP-Konfigurationsbackend braucht dieselbe Behandlung, da ein Schreibzugriff dort denselben Code-Pfad erreicht.

• Den Deployment-Scanner abschalten, wo er nicht gebraucht wird.

  Der Schritt, der aus einem Schreibvorgang Codeausführung macht, ist die Aufnahme eines Archivs aus dem Deployments-Verzeichnis durch den Applikationsserver. Installationen, die einmal deployen und kein Hot-Deployment nutzen, können den Scanner abschalten. Das entfernt diesen Schritt für diesen Fund und für den im verwandten Advisory beschriebenen Storage-Descriptor-Schreibzugriff.

• Ein exponiertes Archiv als offengelegt behandeln.

  War die Konfigurationsschnittstelle aus einem nicht vertrauenswürdigen Netz erreichbar, ist davon auszugehen, dass die in der Archivkonfiguration hinterlegten Zugangsdaten für Datenbank, Storage-Backends und LDAP-Backend bekannt sind. Diese sollten gewechselt werden.

Bewertung im Detail

Referenzen

• GHSA-hxq8-xgh3-4f76 (dcm4che)
• dcm4chee-arc-light Issue 4985 (Einträge außerhalb des Entpackverzeichnisses zurückweisen)
• dcm4chee-arc-light Issue 5034 (Entpackverzeichnis eingrenzen)
• dcm4chee-arc-light 5.35.1 Release
• dcm4chee-arc-light Repository
• Verwandt: Storage-Descriptor File Write in dcm4chee-arc-light
• Verwandt: XSLT-Attribute-Coercion in dcm4chee-arc-light
• Verwandt: XML External Entity Injection in dcm4chee-arc-light

So können wir helfen

• MDR-Penetrationstests
• §17 MPBetreibV