Heap-Buffer-Overflow im DICOM-Bilddecoder (Palette-Color-Decodierung)

Beschreibung

// alle Operanden sind unsigned int (32 Bit)
// Mit Cols=1431655766, Rows=3: 1431655766 * 3 = 4294967298 → uint32: 2
// pixelLength=2 passt zum überlaufenen Resultat → Validierung gelingt
if (pixelLength != target->GetWidth() * target->GetHeight())

// RGB24-Pitch: 3 * 1431655766 → uint32: 2
pitch_ = GetBytesPerPixel() * width_;
// Gesamtallokation: 2 * 3 = 6 Bytes (sollten ~4 GB für RGB24 sein)

// iteriert 1431655766 * 3 mal
// Bei Pixel #3: source liest über den 2-Byte-Pixelpuffer hinaus (OOB-Lesezugriff)
// Bei Pixel #3: p schreibt über den 6-Byte-Zielpuffer hinaus (OOB-Schreibzugriff)
for (unsigned int x = 0; x < width; x++)
{
    p[0] = lutRed[*source] >> offsetBits;    // OOB-Lesezugriff via *source
    p[1] = lutGreen[*source] >> offsetBits;
    p[2] = lutBlue[*source] >> offsetBits;   // OOB-Schreibzugriff via p[2]
    source++;
    p += 3;
}

==1==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xffffa6887072
READ of size 1 at 0xffffa6887072 thread T18
    #0 in DecodeLookupTable                             DicomImageDecoder.cpp:497
    #1 in Orthanc::DicomImageDecoder::DecodeUncompressedImage() DicomImageDecoder.cpp:575
    #2 in Orthanc::DicomImageDecoder::Decode()          DicomImageDecoder.cpp:827
    #3 in Orthanc::ParsedDicomFile::DecodeFrame()       ParsedDicomFile.cpp:1823
    #4 in Orthanc::ServerContext::DecodeDicomFrame()    ServerContext.cpp:1921

0xffffa6887072 is located 0 bytes to the right of 2-byte region [0xffffa6887070,0xffffa6887072)
allocated by thread T18 here:
    #0 in operator new[]
    #1 in DcmElement::newValueField()                   dcelem.cc:788

Auswirkung

• Persistenter Denial-of-Service: Eine einzelne gespeicherte DICOM-Datei lässt den Orthanc-Prozess bei jeder Vorschau-Anfrage durch eine beliebige Person abstürzen. Ein Neustart stellt den Dienst wieder her, doch das manipulierte DICOM verbleibt; jede nachfolgende Vorschau lässt den Server erneut abstürzen.
• Heap-Write-Primitive: Die Schleife schreibt sequenzielle RGB-Tripel (3 Bytes pro Pixel) über einen 6-Byte-Zielpuffer hinaus mit kontrollierten, aus den Pixeldaten abgeleiteten Bytes. Ein Ausführen von beliebigem Programmcode innerhalb der Sicherheitsautorität des Orthanc-Prozesses wurde nicht nachgewiesen; die Form der Primitive (sequenziell, kontrollierte Bytes, mehrere Gigabyte Spanne) macht sie zu einem plausiblen Ziel für weitere Exploitation-Forschung.
• In Orthancs Default-Konfiguration (DicomAlwaysAllowStore: true) ist das Ablegen unauthentifiziert; der Auslöser benötigt nur eine Vorschau-Anfrage einer beliebigen Read-Level-Person.

Abhilfe

Aktualisieren Sie Orthanc auf Version 1.12.11 oder höher. Der Patch verwendet 64-Bit-Arithmetik für jede Pixeldatenlängen-Validierung und kombiniert sie mit der Ablehnung von Rows/Columns-Werten jenseits des VR-US-Bereichs (65535) zur Parse-Zeit — dieselbe Dimensionsvalidierung, die auch CVE-2026-5442 mitigiert. Als sofortige Defense-in-Depth-Maßnahme setzen Sie DicomAlwaysAllowStore: false in orthanc.json und konfigurieren eine AET-Allowlist, was den unauthentifizierten Ablegevektor schließt.

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.

• Unauthentifizierten C-STORE-Ablegevektor schließen.

  Setzen Sie DicomAlwaysAllowStore: false in orthanc.json und definieren Sie eine explizite DicomModalities-Allowlist legitimer AETs. Andernfalls kann jeder Host, der Port 4242 erreicht, die persistent abstürzende DICOM-Datei unauthentifiziert ablegen.

• DICOM-Speicher vor dem Patch in Quarantäne und prüfen.

  Durchsuchen Sie den Speicher nach Studien, deren Rows oder Columns 65535 überschreiten (nur mit VR-UL-Kodierung möglich). Solche Studien sind konstruktionsbedingt manipuliert, da DICOM diese Tags als VR US (max. 65535) definiert. Vor dem Patch in Quarantäne geben, da die nächste Vorschau-Anfrage den Server abstürzen lässt.

• Vorschau-Berechtigungen prüfen.

  Sobald eine manipulierte Studie gespeichert ist, lässt jede Read-Level-Person, die GET /instances/*/preview aufruft, den Prozess abstürzen. Beschränken Sie den Vorschau-Zugriff am Reverse-Proxy auf die IPs der Integrationspunkte und Viewer, die ihn benötigen.

• Auf Crash-Restart-Zyklen nach Vorschau-Anfragen achten.

  Alarmieren Sie auf Orthanc-Neustarts (journalctl -u orthanc | grep -E 'SIGSEGV|killed'), die unmittelbar GET /instances/*/preview-Logeinträgen folgen. Wiederholte Abstürze derselben Study-ID deuten auf einen gespeicherten Angriff statt auf einen vorübergehenden Fehler hin.

• Crash-Recovery konfigurieren.

  Bis der Speicher von der manipulierten Studie bereinigt ist, lässt jede Vorschau den Prozess abstürzen. Eine enge Service-Überwachung (systemd, Kubernetes Liveness Probes, Docker --restart) hält den Dienst zwischen den Anfragen verfügbar, behebt die Schwachstelle aber nicht.

Bewertung im Detail

Referenzen

• CVE-2026-5443 (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