GZIP-Dekompressionsbombe über Content-Encoding-Header

Beschreibung

if (boost::iequals(call.GetHttpHeader("content-encoding", ""), "gzip"))
{
  GzipCompressor compressor;
  compressor.Uncompress(dicom, call.GetBodyData(), call.GetBodySize());
}

uint64_t GzipCompressor::GuessUncompressedSize(const void* compressed,
                                                size_t compressedSize)
{
  const uint8_t* p = reinterpret_cast<const uint8_t*>(compressed)
                     + compressedSize - 4;
  return ((static_cast<uint32_t>(p[0]) << 0) +   // angreifer-kontrolliert
          (static_cast<uint32_t>(p[1]) << 8) +   // max ~4 GB (uint32)
          (static_cast<uint32_t>(p[2]) << 16) +
          (static_cast<uint32_t>(p[3]) << 24));
}

uncompressedSize = GuessUncompressedSize(compressed, compressedSize);
uncompressed.resize(static_cast<size_t>(uncompressedSize));  // keine Obergrenze

Auswirkung

• Denial-of-Service: Eine Welle von ~20 parallelen HTTP-Requests (jeweils ein 24 Byte großer gzip-Stream mit gepatchtem ISIZE) beendet den Orthanc-Prozess über den Linux-OOM-Killer (Exit-Code 137).
• Der gesamte Angriffs-Payload umfasst 480 Bytes (20 × 24-Byte-gzip-Streams). Keine gültigen DICOM-Daten erforderlich, nur das gzip-Framing mit gepatchtem ISIZE-Trailer.
• 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 dekomprimierte Größe und weist Payloads oberhalb dieses Limits mit BadFileFormat ab. Als Defense-in-Depth konfigurieren Sie an Ihrem Reverse-Proxy eine harte Content-Length-Obergrenze — typischerweise einige hundert MB — was zusätzlich die unbegrenzte Content-Length-Allokation in CVE-2026-5440 und die gefälschte ZIP-Allokation in CVE-2026-5439 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 gzip-Bombe löst die ~4-GB-Allokation unabhängig von der Upload-Größe aus, doch ein Pro-Request-Body-Limit deckt die Familie der „Metadaten-Vertrauen"-Bomben ab (diese Schwachstelle plus CVE-2026-5440 und CVE-2026-5439).

• Content-Encoding: gzip deaktivieren, falls ungenutzt.

  Senden Ihre DICOM-Upload-Clients keine gzip-komprimierten Bodies, entfernen Sie den Content-Encoding-Header an Ihrem Reverse-Proxy. Der HTTP-Pfad, der GzipCompressor auslöst, hängt vollständig an diesem Header.

• 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-5438 (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