Heap-Buffer-Overflow in der PAM-Bildpuffer-Allokation

Beschreibung

// width, channelCount, bytesPerChannel sind alle unsigned int (32 Bit).
// z. B. WIDTH=715827883, DEPTH=3, MAXVAL=65535 (bytesPerChannel=2):
//   715827883 * 3 * 2 = 4294967298 (0x100000002)
//   Trunkiert auf uint32: 2
unsigned int pitch = width * channelCount * bytesPerChannel;

// allokiert pitch * height = 2 * 1 = 2 Bytes
alignedImageBuffer_ = malloc(pitch * height);

// Schleife durchläuft `width` Iterationen (z. B. 715827883).
// Jede Iteration verschiebt einen uint16_t-Zeiger und schreibt
// an Offsets 0, 2, 4, ... über ~1,4 GB Heap hinter den Puffer.
for (unsigned int w = 0; w < width; ++w, ++pixel) {
    uint8_t* srcdst = reinterpret_cast<uint8_t*>(pixel);
    uint8_t tmp = srcdst[0];   // Out-of-Bounds-Lesezugriff
    srcdst[0] = srcdst[1];     // Out-of-Bounds-Schreibzugriff
    srcdst[1] = tmp;           // Out-of-Bounds-Schreibzugriff
}

==1==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xffffabc81372
READ of size 1 at 0xffffabc81372 thread T16
    #0 in Orthanc::PamReader::ParseContent()           PamReader.cpp:268
    #1 in Orthanc::PamReader::ReadFromMemory()         PamReader.cpp:295
    #2 in Orthanc::ParsedDicomFile::EmbedImage()       ParsedDicomFile.cpp:1300
    #3 in Orthanc::ParsedDicomFile::EmbedContent()     ParsedDicomFile.cpp:1262
    #4 in CreateDicomV2                                OrthancRestAnonymizeModify.cpp:1029
    #5 in CreateDicom                                  OrthancRestAnonymizeModify.cpp:1108

0xffffabc81372 is located 0 bytes to the right of 2-byte region [0xffffabc81370,0xffffabc81372)
allocated by thread T16 here:
    #0 in __interceptor_malloc
    #1 in Orthanc::PamReader::ParseContent()           PamReader.cpp:214

Auswirkung

• Denial-of-Service: Ein einzelner authentisierter POST /tools/create-dicom-Request mit einem 71 Byte großen PAM-Payload beendet den Orthanc-Prozess mit SIGSEGV. Der Server muss nach jedem Request neu gestartet werden und ist anschließend sofort wieder angreifbar.
• Heap-Write-Primitive: Die Schleife führt sequenzielle 2-Byte-Swaps über rund 1,4 GB Heap hinter der Allokation durch. Ein Ausführen von beliebigem Programmcode wurde nicht nachgewiesen; die Form der Primitive (kontrollierte Offsets, vom Angreifer beeinflusste Bytes) macht sie zu einem plausiblen Ziel für weitere Exploitation-Forschung.
• Das Angriffsmodell hängt von der Orthanc-Konfiguration ab: Bei aktivem AuthenticationEnabled handelt es sich um einen authentisierten Angreifer mit Rechten zum Hochladen oder Modifizieren von Studien; ohne HTTP-Authentifizierung (eine zulässige Orthanc-Konfiguration) ist der Endpunkt für jeden netzseitig erreichbaren Aufrufer offen.

Abhilfe

Aktualisieren Sie Orthanc auf Version 1.12.11 oder höher. Der Patch führt sowohl eine Validierung der Header-Werte zur Parse-Zeit als auch 64-Bit-Arithmetik mit expliziten Überlaufprüfungen vor der Allokation durch. Ergänzend lässt sich POST /tools/create-dicom per Pro-Route-Autorisierung in orthanc.json weiter einschränken.

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.

• Betroffenen Endpunkt einschränken.

  Sperren oder beschränken Sie POST /tools/create-dicom an Ihrem Reverse-Proxy (nginx, Traefik etc.) für alle Rollen, die DICOM-Dateien nicht programmatisch erstellen müssen.

• Zugangsdaten überprüfen.

  Die Schwachstelle erfordert einen authentisierten Benutzer. Prüfen Sie RegisteredUsers in orthanc.json sowie ein externes Authentifizierungsbackend auf Konten, die keine create-dicom-Rechte benötigen.

• Logs auf verdächtige Aktivität prüfen.

  Suchen Sie nach früheren POST /tools/create-dicom-Aufrufen mit ungewöhnlich kleinen Request-Bodies (unter ~200 Bytes) sowie nach unerwarteten Prozessneustarts in Ihrer Service-Überwachung (z. B. journalctl -u orthanc | grep -E 'SIGSEGV|killed').

• Crash-Recovery konfigurieren.

  Ein erfolgreicher Denial-of-Service sollte auf die Neustartzeit Ihrer Service-Überwachung begrenzt sein (systemd, Kubernetes Liveness Probes, Docker --restart). Recovery behebt die Schwachstelle nicht, begrenzt aber die Auswirkungen.

Bewertung im Detail

Referenzen

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