XML External Entity Injection über DICOMweb-Metadaten

Beschreibung

public static Attributes parse(InputStream is, Attributes attrs)
        throws ParserConfigurationException, SAXException, IOException {
    if (attrs == null)
        attrs = new Attributes();
    SAXParserFactory f = SAXParserFactory.newInstance();
    SAXParser parser = f.newSAXParser();
    parser.parse(is, new ContentHandlerAdapter(attrs));
    return attrs;
}

Auswirkung

• Eine textförmige Datei, die das Dienstkonto des Archivs lesen kann, lässt sich von einem Aufrufer abholen, der sich nie authentifiziert hat. Auf einer Standardinstallation gehören dazu Konfigurationsdateien, die Zugangsdaten für die Backend-Dienste des Archivs im Klartext enthalten. Derselbe Mechanismus erreicht Hosts im internen Netz, die der Aufrufer nicht direkt adressieren kann, wobei das Archiv als Ursprung der Anfrage auftritt. Binärdateien sind auf diesem Weg nicht zu gewinnen, weil der Inhalt das XML-Parsing überstehen muss.
• Die Bewertung bezieht sich auf die Bereitstellung, die die Projektdokumentation zuerst vorstellt und in der die DICOMweb-Endpunkte ohne Authentifizierung antworten. Wird stattdessen der abgesicherte Build betrieben, verlangen diese Endpunkte die Basisrolle, die das mitgelieferte Konto mit geringen Rechten ohnehin besitzt. Der Fund bleibt dort bei entsprechend niedrigerer Bewertung für jeden authentifizierten Nutzer erreichbar.

Abhilfe

Auf dcm4chee-arc-light 5.35.0 oder neuer aktualisieren, wo der gemeinsam genutzte Parser externe Entities nicht mehr auflöst. Bis dahin lässt sich die Angriffsfläche verringern, indem die DICOMweb-Endpunkte auf vertrauenswürdige Netze beschränkt werden. Zugangsdaten, die auf einem exponierten Archiv in der Konfiguration liegen, sollten als offengelegt behandelt und gewechselt werden.

Checkliste für Betreiber

• Aktualisieren, und dabei die Bibliotheksversion prüfen, nicht die Archivversion.

  Der Fix sitzt in der gemeinsam genutzten Parser-Factory der dcm4che-Bibliothek, nicht an den Aufrufstellen des Archivs. Wer das Archiv selbst baut oder die Bibliothek unabhängig pinnt, sollte prüfen, ob das dcm4che-Core-Artefakt tatsächlich mitgezogen ist und nicht nur das Archiv-Release.

• Zugangsdaten aus der Archivkonfiguration wechseln.

  Auf einer Standardinstallation umfasst der lesbare Bestand die Konfiguration mit Datenbank-, Storage- und LDAP-Zugangsdaten im Klartext. Waren die DICOMweb-Endpunkte auf einer betroffenen Version aus einem nicht vertrauenswürdigen Netz erreichbar, sind diese als offengelegt zu behandeln und zu wechseln.

• Egress-Filterung nicht als die Maßnahme betrachten.

  Die Netzwerkvariante dieses Funds ist ein nützliches Signal, aber nicht das Hauptrisiko. Der Dateilesezugriff kommt im selben Kanal über die Abrufschnittstelle des Archivs zurück, braucht also gar keine ausgehende Verbindung, und das Sperren von Egress ändert daran nichts.

• Prüfen, was sonst den gemeinsamen Parser nutzt.

  Die freizügige Factory lag in der dcm4che-Bibliothek, die Exposition war also nicht auf den DICOMweb-Pfad beschränkt. Wer weitere Software auf derselben Bibliothek betreibt, sollte prüfen, ob auch dort die gehärtete Version angekommen ist.

Bewertung im Detail

Referenzen

• GHSA-9g23-9gp3-gcq8 (dcm4che)
• dcm4chee-arc-light Issue 4988 (Hersteller-Fix)
• dcm4che Issue 1595 (Härtung der Bibliothek)
• dcm4chee-arc-light 5.35.0 Release
• dcm4chee-arc-light Repository
• Verwandt: XSLT-Attribute-Coercion in dcm4chee-arc-light
• Verwandt: Storage-Descriptor File Write in dcm4chee-arc-light
• Verwandt: Vendor-Data-Extraktion in dcm4chee-arc-light

So können wir helfen

• MDR-Penetrationstests
• §17 MPBetreibV