master ist ein datierter Snapshot, kein beweglicher Branch. Beide Revisionen sind aus dem öffentlichen Repository erreichbar, sodass bootstrap.sh beide ohne jeglichen privaten Quellcode vorbereiten kann.

Umfang der Befunde

Laufzeitnachweise in diesem Repository gelten für v3.2.6. Die weiteren Bereiche unten stammen aus der Quellcode-Historieninspektion; die betroffenen Muster sind auch im angepinnten Master- Snapshot weiterhin vorhanden.

Inhalt

• fixtures/ - die inerten DICOM-Eingaben, SHA-256-gepinnt in manifest/expectations.json und vor jedem Auslöserlauf verifiziert
• generators/ - deterministische, abhängigkeitsfreie Quellgeneratoren für jedes Fixture
• harnesses/ - minimale Lese-/Kodier-/Dekodier-Harnesses; Befund 2 wird sowohl über die gdcmconv-CLI als auch über die Bibliotheks-Transcode-API gezeigt, die ein Server aufrufen würde
• manifest/expectations.json - maschinenlesbare Befehle, entscheidende Signale und Akzeptanzkriterien für das fixed-Ziel
• scripts/ - Vorbereitung des angepinnten Quellcodes, Sanitizer-Builds, begrenzte Ausführung, Bereinigung
• evidence/ - prägnante bereits beobachtete Ergebnisse, mit explizit genannten ungetesteten Zielen
• LICENSE - MIT-Lizenz

Voraussetzungen

Eine wegwerfbare Linux- oder macOS-Build-Umgebung mit Git, Python 3, CMake 3.20+, Ninja und einer C++11-Toolchain (Clang oder GCC). Unter Ubuntu: git python3 cmake ninja-build clang zlib1g-dev. Setzen Sie CC/CXX, um stattdessen GCC zu verwenden.

Die Quellcode-Vorbereitung klont über HTTPS, es sei denn, GDCM_SOURCE_REPO verweist auf einen vorhandenen lokalen Klon. Es wird kein SSH-Host verwendet.

Vorbereiten und bauen

Diese Befehle bereiten nur Quellcode und Build-Artefakte vor; sie öffnen kein Fixture.

Das dritte Argument ist das Profil. debug ist -O0 -g; release ist -O2 -g -DNDEBUG, was GDCMs gdcm_debug_assert()s entfernt und der Art entspricht, wie Distributionen die Bibliothek bauen. Die Matrix unter beiden auszuführen beantwortet die erste Frage, die ein Maintainer stellt, nämlich ob die Berichte ein Artefakt eines assertion-fähigen Builds sind.

GDCM_SUPPORT_BROKEN_IMPLEMENTATION=ON ist GDCMs eigener Standard und wird unverändert gelassen. Überschreiben Sie die konservative Parallelität mit JOBS=8.

Jeder Build schreibt build-info.json (Revision, Compiler, Flags, Plattform) in seinen GDCM- Build-Baum, und jede Laufzusammenfassung bettet sie ein, sodass archivierte Nachweise selbsterklärend sind.

Ausführen

run-matrix.sh führt jeden automatisierten Fall für jedes Ziel aus, stoppt nicht beim ersten Fehler und schreibt _runs/matrix-<stamp>.json sowie eine gerenderte _runs/matrix-<stamp>.md. Der zweistufige f1-exploit-Fall bleibt manuell und wird als solcher gemeldet, statt fälschlich als fehlgeschlagener automatisierter Fall klassifiziert zu werden.

Jedes Kind hat Core Dumps deaktiviert und ein 15-Sekunden-Timeout; Befund 5 erhält zusätzlich ein begrenztes Stack-Limit. Ausgaben bleiben unter _runs/. Der Klassifizierer gleicht Sanitizer-Klasse und betroffene Funktion ab, niemals Adressen, PIDs oder Quellcodezeilennummern.

Für vulnerable besteht ein Fall, wenn das entscheidende Signal erscheint und seine Kontrolle sauber bleibt. Für master zeichnet der Runner die Beobachtung auf statt eines vorab erklärten Urteils. Für fixed besteht ein Fall nur, wenn das Signal fehlt, kein anderes Sanitizer- oder fatales Signal erscheint und der Harness ein erlaubtes sauberes Ergebnis zurückgibt. Diese Regeln sind vorläufig, bis FIXED_REV einen tatsächlichen Patch benennt; sie müssen gegen das beabsichtigte Ablehn-oder-Verarbeiten-Verhalten dieses Patches überprüft werden.

Fälle

Zwei weitere Harnesses sind Exploitability-Forschung statt Reproduktionsfälle und bauen nur im unsanitized Profil auf Linux x86-64:

Aufbewahrte Nachweise

evidence/v3.2.6-macos-arm64-debug.md zeichnet die abgeschlossene v3.2.6-Debug-Matrix auf, einschließlich jeder Kontrolle und beider begrenzter Befund-3-Propagationsprüfungen.

evidence/v3.2.6-linux-x86_64-finding01-groom.md und evidence/v3.2.6-linux-x86_64-finding03-leak.md zeichnen die beiden Exploitability-Ergebnisse unten auf. Ergebnisse für aktuelles Master, die vollständige Release-Profil-Matrix und f1-exploit werden nicht beansprucht, bis ihre Transkripte aufbewahrt sind.

Bereinigung

Die Bereinigung weigert sich, ohne den Paketmarker zu laufen, und entfernt nur _work, _build, _generated, _runs und Python-Bytecode-Caches unterhalb dieses Repositorys. Aufbewahrte Nachweise unter evidence/ werden nicht entfernt.

Exploit-Primitiv (Befund 1)

f1-exploit ist nur für Linux-x86_64 und wird von Hand ausgeführt; manifest/expectations.json enthält die exakte Befehlssequenz. Unter dem deterministischen Allokationslayout des Harness testet es drei separate Fakten, jeweils mit einem passenden Negativfall:

• der Überlauf erreicht Speicher, den der Allocator nach dem Zielpuffer ausgegeben hat;
• die dort landenden Bytes sind exakt die Bytes, die das präparierte DICOM angefordert hat. Das Einpflanzen eines anderen Werts oder die Verwendung des einfachen f1-Fixtures meldet Korruption, aber ausdrücklich nicht Inhaltskontrolle, sodass die Prüfung falsifizierbar ist;
• der Funktionszeiger des synthetischen Opfers enthält am Ende eine von der Datei gelieferte Adresse, und deren Aufruf überträgt die Kontrolle auf eine Funktion innerhalb des Harness.

Etwa die Hälfte der 8-Byte-Fenster innerhalb des 12288-Byte-Überlaufs akzeptiert einen beliebigen Wert. Der Rest ist gekoppelt, weil DoYBRFull422 ein Quellbyte in zwei Ausgabepositionen dupliziert; Offset 6144 ist eines der freien Fenster. Die Dekodierung von Frame 1 läuft zuletzt, also ist es der Inhalt von Frame 1, der über die Allokation hinaus bestehen bleibt.

Der Harness zeichnet auf, ob ImageReader::Read() true zurückgibt, während das benachbarte Objekt modifiziert wird. Ein erfolgreiches Linux-x86-64-Transkript muss aufbewahrt werden, bevor dieses Ergebnis als beobachteter Nachweis beschrieben wird.

Was ohne die Instrumentierung passiert

f1-exploit liefert sein eigenes Opfer-Layout, kann also nicht beantworten, ob ein unmodifizierter Prozess dieses Layout hat. finding01_groom verwendet Stock-glibc, Standard-PIE und ASLR, mit globalen Allokations-Hooks, die Allokationen aufzeichnen, aber nicht verschieben. In den aufbewahrten Tests:

• die Allokation nach dem 24576-Byte-Puffer war in allen 20 aufgezeichneten Versuchen ein freigegebener 2049-Byte-GDCM-Scratch- Chunk. Es wurde kein lebendes Objekt oder keine vtable beobachtet;
• das Korrumpieren der Free-List-Metadaten dieses Chunks löst glibcs eigene Konsistenzprüfung aus, die abbricht. Der einfache finding01-Harness stirbt auf dieselbe Weise ganz ohne Instrumentierung.

Auf dem getesteten glibc-Build verursachte Befund 1 zuverlässig Denial of Service; es wurde kein Code-Execution-Pfad gefunden. Die getestete Geometrie war fest, und andere Allocatoren oder Plattformen könnten den Heap anders anordnen.

finding03_leak ist das stärkere Ergebnis. Im getesteten Build erreicht das Out-of-Bounds-Lesen 131070 Bytes, ein gdcm::ByteValue-vtable-Zeiger gelangt in dekodierte Pixel, und der Harness leitet die Bibliotheks-Ladebasis unter Verwendung des bekannten vtable-Offsets dieses Builds ab. Dies ist ein lokales API-Level-Offenlegungsergebnis: es erfordert LUT-Anwendung und Zugriff auf den dekodierten Pixelpuffer. Es zeigt nicht, dass ein Netzwerkdienst diese Pixel zurückgibt.

Die beiden können hier nicht zu Code-Execution verkettet werden, und nicht nur, weil kein Opfer gefunden wurde: sie benötigen unterschiedliche PhotometricInterpretation-Werte, also zwei Dateien, und eine geleakte Basis ist nur nützlich, solange der leckende Prozess noch lebt.

Nachweisgrenze

Ein Sanitizer-Bericht beweist das angegebene Memory-Safety- oder Undefined-Behavior-Ereignis im getesteten Prozess und in der getesteten Revision. f1-exploit testet Byte-Kontrolle und ein Überschreiben eines benachbarten Funktions- zeigers unter einem instrumentierten Allocator, der absichtlich das Ziel- Layout liefert. Es belegt dieses Layout nicht in einem unmodifizierten Consumer. Die aufbewahrten finding01_groom-Versuche beobachteten dieses Layout für die getestete Geometrie und den glibc- Build nicht.

Nichts davon beweist Remote-Erreichbarkeit in einem bestimmten Produkt, Persistenz oder Downstream-Anwendbarkeit. Das Erreichbarkeitsargument für ein gegebenes Deployment ist eine separate Behauptung, die im Offenlegungstext gemacht wird und nicht von diesem Paket.