t3code-release-checksum-same-origin

L'updater verifica un file SHA-256 che si trova accanto al download. Ruba l'host del download e rubi anche il checksum. Non c'è alcuna firma su quel percorso. La corruzione accidentale fallisce comunque. Una coppia scambiata dalla stessa origine viene installata.

Classe: Supply chain Portata: Supply chain (chiunque controlli releaseBaseUrl)

T3 Code 61c3794c - Ping

ID	nessuna CVE al momento
Classe	Supply chain
Portata	Supply chain (host di rilascio compromesso, CDN, o DNS/TLS su quella origine)
CWE	CWE-345 / CWE-494
CVSS	Medio: 6.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Prodotto	T3 Code
Affetto	61c3794c32b0eeebfac09add43e403618c65d2d7
Auth	nessuna sulla vittima una volta che il publisher è compromesso; la vittima esegue un'installazione o un aggiornamento
Licenza	GNU Affero GPL v3.0
Lab	publisher su loopback 127.0.0.1:18192; tar simulato in modo che i byte dell'archivio non vengano mai eseguiti

Cosa può fare un attaccante

Richiede il controllo dell'origine che serve sia SHA256SUMS che l'archivio (releaseBaseUrl / GitHub Releases per quella build). Non richiede un account T3 sulla vittima.

Privilegio	Metodo / sink	Ricognizione / integrità / disponibilità	Provato in lab o dedotto
Pubblicare archivio + checksum corrispondenti da un'unica origine	ensurePinnedRuntimeInstalled recupera ${baseUrl}/SHA256SUMS poi ${baseUrl}/${fileName}, confronto SHA-256	Integrità (installazione accettata)	Provato in lab. checksum-pass=1, witness t3f02s9m4 in entrambi i file
Guidare self-update / boot-service attraverso lo stesso helper	selfUpdate.ts, bootService.ts passano releaseBaseUrl	Integrità	Sorgente. Il lab ha chiamato l'helper direttamente
Eseguire il binario installato dopo l'estrazione	tar -xf poi esegue t3	Integrità / disponibilità	Dedotto. Il lab ha simulato tar e non ha eseguito i byte
Controllo negativo: checksum non corrispondente	stesso helper, zeri in SHA256SUMS	n/a	Provato in lab. step verifying the t3 release archive checksum

Resta chiuso su questo residuo

Asse	Metodo / sink	Perché è chiuso
Integrità	Bit-flip accidentale in transito	La mancata corrispondenza SHA-256 rifiuta l'estrazione
Integrità	Origine aggiuntiva non firmata	Il lab ha usato un'unica base URL; una seconda origine non viene mai consultata perché non esiste
Integrità	Questo lab che esegue byte dell'attaccante	tar simulato; extracted-binary-executed=0

signature-check=0 sul blocco download+digest e sui chiamanti self-update / boot-service (nessun minisign, cosign, GPG o sigstore).

Come l'ho trovato

pinnedRuntime.ts costruisce entrambe le URL da cliReleaseDownloadBaseUrl. I test in-tree bloccano già il passaggio del checksum dalla stessa origine e il fallimento in caso di mancata corrispondenza. Non richiedono una firma.

Vicoli ciechi: trattare un checksum come autenticatore del publisher.

Lab

python3 t3code-release-checksum-same-origin-Abraxas-Labs.py

o:

cd lab
./run.sh

Publisher HTTP loopback su 127.0.0.1:18192. In produzione ensurePinnedRuntimeInstalled utilizza Effect fetch verso quell'origine. Le coppie corrispondenti installano (estrazione mockata). Le coppie non corrispondenti si fermano alla verifica.

IOC loopback-bound=127.0.0.1:18192
IOC same-origin=1
IOC checksum-pass=1
IOC checksum-fail=1
IOC signature-check=0
IOC tar-mocked=1
IOC extracted-binary-executed=0
SUCCESS T3-F02-CHECKSUM t3f02s9m4

La correzione

Firma il manifest del checksum (minisign, cosign o GPG) e incorpora la chiave pubblica nel binario. Verifica la firma prima di analizzare SHA256SUMS. Fissa l'origine della release a un riferimento firmato immutabile.

Riferimenti

• github.com/pingdotgg/t3code 61c3794c32b0eeebfac09add43e403618c65d2d7
• pinnedRuntime.ts download+digest
• CWE-345 · CWE-494

Licenza

GNU Affero GPL v3.0. Vedi LICENSE. Solo laboratorio loopback. Nessuna garanzia.

Abraxas Labs [email protected]

Si prega di attribuire la CVE ad Abraxas Labs.