gdcm-security-poc

Pacchetto privato di riproduzione del sanitizer end-to-end per sei risultati di GDCM

master è uno snapshot datato, non un branch in movimento. Entrambe le revisioni sono raggiungibili dal repository pubblico, quindi bootstrap.sh può preparare l'una o l'altra senza alcuna sorgente privata.

Ambito dei reperti

Le prove runtime in questo repository sono per la v3.2.6. Gli intervalli più ampi riportati di seguito provengono dall'ispezione della cronologia dei sorgenti; i pattern implicati rimangono anche nello snapshot master fissato.

Contenuti

• fixtures/ - gli input DICOM inerti, con SHA-256 fissato in manifest/expectations.json e verificati prima di ogni esecuzione del trigger
• generators/ - generatori di sorgenti deterministici e senza dipendenze per ogni fixture
• harnesses/ - harness minimali di lettura/codifica/decodifica; il reperto 2 è mostrato sia tramite la CLI gdcmconv sia tramite l'API di transcodifica della libreria che un server chiamerebbe
• manifest/expectations.json - comandi leggibili dalla macchina, segnali decisivi e criteri di accettazione per il target fixed
• scripts/ - preparazione dei sorgenti fissati, build con sanitizer, esecuzione limitata, pulizia
• evidence/ - risultati concisi già osservati, con i target non testati dichiarati esplicitamente
• LICENSE - licenza MIT

Prerequisiti

Un ambiente di build Linux o macOS usa e getta con Git, Python 3, CMake 3.20+, Ninja e una toolchain C++11 (Clang o GCC). Su Ubuntu: git python3 cmake ninja-build clang zlib1g-dev. Impostare CC/CXX per usare GCC invece.

La preparazione dei sorgenti clona via HTTPS a meno che GDCM_SOURCE_REPO non punti a un clone locale esistente. Non viene usato alcun host SSH.

Preparazione e build

Questi comandi preparano solo sorgenti e artefatti di build; non aprono alcuna fixture.

Il terzo argomento è il profilo. debug è -O0 -g; release è -O2 -g -DNDEBUG, che elimina le gdcm_debug_assert() di GDCM e corrisponde a come le distribuzioni compilano la libreria. Eseguire la matrice con entrambi risponde alla prima domanda che un manutentore pone, ovvero se i report sono un artefatto di una build con le asserzioni abilitate.

GDCM_SUPPORT_BROKEN_IMPLEMENTATION=ON è il default di GDCM stesso e viene lasciato invariato. Sovrascrivere il parallelismo conservativo con JOBS=8.

Ogni build scrive build-info.json (revisione, compilatore, flag, piattaforma) nel proprio albero di build GDCM, e ogni riepilogo di esecuzione lo incorpora, così le prove archiviate sono auto-descrittive.

Esecuzione

run-matrix.sh esegue ogni caso automatizzato per ogni target, non si ferma al primo fallimento e scrive _runs/matrix-<stamp>.json più un _runs/matrix-<stamp>.md renderizzato. Il caso f1-exploit a due stadi rimane manuale ed è riportato come tale invece di essere classificato erroneamente come un caso automatizzato fallito.

Ogni processo figlio ha i core dump disabilitati e un timeout di 15 secondi; il reperto 5 riceve inoltre un limite di stack limitato. Gli output rimangono sotto _runs/. Il classificatore confronta la classe del sanitizer e la funzione implicata, mai indirizzi, PID o numeri di riga dei sorgenti.

Per vulnerable, un caso passa quando appare il segnale decisivo e il suo controllo rimane pulito. Per master, il runner registra l'osservazione invece di un verdetto predefinito. Per fixed, un caso passa solo quando il segnale è assente, non appare alcun altro sanitizer o segnale fatale, e l'harness restituisce un esito pulito consentito. Queste regole sono provvisorie finché FIXED_REV non indica una patch effettiva; devono essere riviste rispetto al comportamento previsto di rifiuto-o-elaborazione di quella patch.

Casi

Altri due harness sono ricerca di sfruttabilità piuttosto che casi di riproduzione, e si compilano solo nel profilo senza sanitizer su Linux x86-64:

Prove conservate

evidence/v3.2.6-macos-arm64-debug.md registra la matrice debug v3.2.6 completata, inclusi ogni controllo ed entrambi i controlli limitati di propagazione del reperto 3.

evidence/v3.2.6-linux-x86_64-finding01-groom.md e evidence/v3.2.6-linux-x86_64-finding03-leak.md registrano i due risultati di sfruttabilità riportati di seguito. I risultati su master corrente, la matrice completa del profilo release e f1-exploit non sono dichiarati finché i loro transcript non vengono conservati.

Pulizia

La pulizia rifiuta di essere eseguita senza il marker del pacchetto e rimuove solo _work, _build, _generated, _runs e le cache di bytecode Python sotto questo repository. Le prove conservate sotto evidence/ non vengono rimosse.

Primitiva di sfruttamento (reperto 1)

f1-exploit è solo per Linux-x86_64 e viene eseguito manualmente; manifest/expectations.json contiene la sequenza esatta di comandi. Sotto il layout di allocazione deterministico dell'harness verifica tre fatti separati, ciascuno con un caso negativo abbinato:

• l'overflow raggiunge memoria che l'allocatore ha fornito dopo il buffer target;
• i byte che vi finiscono sono esattamente i byte richiesti dal DICOM costruito. Inserire un valore diverso, o usare la fixture f1 semplice, segnala corruzione ma esplicitamente non controllo del contenuto, quindi il controllo è falsificabile;
• il puntatore a funzione della vittima sintetica finisce per contenere un indirizzo fornito dal file, e chiamarlo trasferisce il controllo a una funzione all'interno dell'harness.

Circa la metà delle finestre di 8 byte all'interno dell'overflow di 12288 byte accetta un valore arbitrario. Le restanti sono accoppiate, perché DoYBRFull422 duplica un byte sorgente in due posizioni di output; l'offset 6144 è una delle finestre libere. La decodifica del frame 1 viene eseguita per ultima, quindi è il contenuto del frame 1 che persiste oltre l'allocazione.

L'harness registra se ImageReader::Read() restituisce true mentre l'oggetto adiacente è modificato. Un transcript Linux x86-64 riuscito deve essere conservato prima di descrivere quel risultato come prova osservata.

Cosa accade senza la strumentazione

f1-exploit fornisce il proprio layout della vittima, quindi non può rispondere se un processo non modificato abbia quel layout. finding01_groom usa glibc standard, PIE predefinito e ASLR, con hook globali di allocazione che registrano ma non riposizionano le allocazioni. Nei test conservati:

• l'allocazione successiva al buffer di 24576 byte era un chunk scratch GDCM liberato di 2049 byte in tutte le 20 prove registrate. Non è stato osservato alcun oggetto vivo o vtable;
• corrompere i metadati della free-list di quel chunk attiva il controllo di consistenza di glibc stesso, che aborta. L'harness finding01 semplice muore allo stesso modo senza alcuna strumentazione.

Sulla build glibc testata, il reperto 1 ha causato in modo affidabile denial of service; non è stato trovato alcun percorso di esecuzione di codice. La geometria testata era fissa, e altri allocatori o piattaforme possono disporre l'heap diversamente.

finding03_leak è il risultato più forte. Nella build testata, la lettura fuori limite raggiunge 131070 byte, un puntatore a vtable di gdcm::ByteValue entra nei pixel decodificati, e l'harness deriva la base di caricamento della libreria usando l'offset di vtable noto di quella build. Questo è un risultato locale di divulgazione a livello di API: richiede l'applicazione della LUT e l'accesso al buffer dei pixel decodificati. Non dimostra che un servizio di rete restituisca quei pixel.

I due non possono essere concatenati in esecuzione di codice qui, e non solo perché non è stata trovata alcuna vittima: richiedono valori diversi di PhotometricInterpretation, quindi richiedono due file, e una base divulgata è utile solo finché il processo che la divulga è ancora vivo.

Confine delle prove

Un report di sanitizer prova l'evento dichiarato di memory-safety o comportamento indefinito nel processo e nella revisione testati. f1-exploit verifica il controllo dei byte e una sovrascrittura di puntatore a funzione adiacente sotto un allocatore strumentato che fornisce deliberatamente il layout target. Non stabilisce quel layout in un consumatore non modificato. Le prove conservate di finding01_groom non hanno osservato quel layout per la geometria testata e la build glibc.

Niente di tutto ciò prova la raggiungibilità remota in un particolare prodotto, la persistenza o l'applicabilità a valle. L'argomento di raggiungibilità per un dato deployment è un'affermazione separata, fatta nel testo di divulgazione e non da questo pacchetto.