Speichererschöpfung durch gefälschte ZIP-Metadaten

Beschreibung

if (ZipReader::IsZipMemoryBuffer(call.GetBodyData(), call.GetBodySize()))
{
  std::unique_ptr<ZipReader> reader(ZipReader::CreateFromMemory(...));
  std::string filename, content;
  while (reader->ReadNextFile(filename, content))  // löst resize aus
  {
    // ... verarbeitet die entpackte Datei als DICOM
  }
}

unz_file_info64_s info;
if (unzGetCurrentFileInfo64(pimpl_->unzip_, &info, ...) != 0)
{
  throw OrthancException(ErrorCode_BadFileFormat);
}

content.resize(info.uncompressed_size);  // vertraut den ZIP-Metadaten, keine Obergrenze

Auswirkung

• Denial-of-Service: Eine Welle von ~20 parallelen Uploads à 126 Byte gefälschter ZIPs beendet den Orthanc-Prozess über den Linux-OOM-Killer (Exit-Code 137).
• Der gesamte Angriffs-Payload umfasst 2.520 Bytes (20 × 126-Byte-ZIPs). Keine gültigen DICOM-Daten erforderlich, nur eine valide ZIP-Struktur mit gefälschten Größenmetadaten.
• Der Server muss nach jedem Absturz neu gestartet werden und ist sofort wieder gegen denselben Angriff anfällig.

Abhilfe

Aktualisieren Sie Orthanc auf Version 1.12.11 oder höher. Der Patch begrenzt das Resize gegen eine konfigurierbare maximale Eintragsgröße und weist Einträge oberhalb dieses Limits mit BadFileFormat ab. Als Defense-in-Depth konfigurieren Sie an Ihrem Reverse-Proxy eine harte Content-Length-Obergrenze passend zu Ihrer DICOM-Workload — typischerweise einige hundert MB — was zusätzlich die Content-Length-Bombe in CVE-2026-5440 und die gzip-Bombe in CVE-2026-5438 eindämmt.

Checkliste für Betreiber

• Version prüfen.

  curl -u <user>:<pass> http://<orthanc>:8042/system | jq .Version — der gepatchte Bereich beginnt bei 1.12.11.

• Request-Größe am Reverse-Proxy begrenzen.

  Konfigurieren Sie eine Content-Length-Obergrenze passend zu Ihrer DICOM-Workload (client_max_body_size 512m; in nginx). Die gefälschte ZIP löst die ~4-GB-Allokation unabhängig von der Upload-Größe aus, doch ein Pro-Request-Body-Limit reduziert die Angriffsfläche für die Familie der „Metadaten-Vertrauen"-Bomben (diese Schwachstelle plus CVE-2026-5440 und CVE-2026-5438).

• POST /instances rate-limiten.

  Der Angriff lebt von Bursts paralleler Uploads. Per-IP-Request-Rate- oder Concurrent-Connection-Limits am Proxy erhöhen die Angriffskosten spürbar.

• Zugangsdaten überprüfen.

  Jede authentisierte Person mit POST /instances-Rechten kann die Schwachstelle auslösen. Prüfen Sie RegisteredUsers in orthanc.json und ein externes Authentifizierungsbackend; widerrufen Sie ungenutzte oder überprivilegierte API-Tokens.

• Auf OOM-Restart-Zyklen achten.

  Alarmieren Sie auf wiederholte SIGKILL-Exits in Ihrer Service-Überwachung (z. B. journalctl -u orthanc | grep -E 'killed|OOM|exit code 137'). Ein wiederkehrender Zyklus deutet auf laufende Ausnutzung statt auf ein einmaliges Ressourcenereignis hin.

Bewertung im Detail

Referenzen

• CVE-2026-5439 (NVD)
• VU#536588 (CERT/CC)
• Orthanc Fix-Commit
• Vendor Release Announcement (v1.12.11)

So können wir helfen

• DICOM-Sicherheitstests
• MDR-Penetrationstests
• §17 MPBetreibV