Aggiornamento di sicurezza dstack — Rafforzamento della pipeline di attestazione

Nell’ambito degli sforzi continui di sicurezza di dstack, il ricercatore indipendente di sicurezza Rahul Saxena (Bluethroat Labs) ha individuato una serie di problemi nella pipeline di verifica dell’attestazione di dstack nel gennaio 2026. Il team di ingegneria di dstack ha collaborato con il ricercatore per validare i risultati, implementare le correzioni e rafforzare lo stack di attestazione. Tutte le remediation accettate sono state distribuite e non è stata trovata alcuna evidenza di sfruttamento attivo in produzione.

Questo aggiornamento riflette un approccio Secure-by-Default: in precedenza, alcune decisioni delle policy di verifica erano demandate alla configurazione a livello applicativo; ora, i valori predefiniti sono più restrittivi e gli output del verificatore sono più chiari, per prevenire semantiche ambigue di tipo “via libera”.

TL;DR

Dstack sta passando da un modello di infrastruttura flessibile a un’architettura Secure-by-Default. Questi aggiornamenti consolidano la logica di verifica, in precedenza lasciata a policy definite dall’utente, in controlli obbligatori a livello infrastrutturale, garantendo una baseline di sicurezza più elevata per tutte le distribuzioni.

• Tutti i problemi trovati e accettati sono stati corretti e distribuiti.
• Nessuna azione richiesta per gli utenti Phala Cloud. Per gli utenti Dstack: aggiornare le immagini dstack alla v0.5.6. Gli utenti dcap-qvl dovrebbero aggiornare dcap-qvl all’ultima versione. Gli utenti DstackApp.sol che desiderano applicare TCB status = UpToDate devono adottare le modifiche di questa PR: https://github.com/Dstack-TEE/dstack/pull/498
• Miglioramenti principali: verifica dell’identità del QE, impostazioni predefinite più restrittive per l’enforcement del TCB, attestazione GPU verificata nel Trust Center, rimozione dell’URL PCCS controllato dal client, verifica TLS resa esplicitamente opt-in.

Timeline

• Gennaio 2026: problemi segnalati e analizzati con il ricercatore.
• Gennaio–febbraio 2026: correzioni implementate, revisionate e distribuite.
• Febbraio 2026: divulgazione pubblica (questo post).

Risultati e remediation

1) Verifica dell’identità del QE (Critico)

Problema: La libreria dcap-qvl non richiedeva la validazione obbligatoria dell’identità del Quoting Enclave (QE), consentendo potenzialmente a un verificatore di accettare quote provenienti da un QE non autorizzato.

Remediation: La verifica dell’identità del QE è ora integrata nella libreria core come controllo obbligatorio. Questo sposta la responsabilità della validazione del QE dallo sviluppatore applicativo all’infrastruttura dstack. (GHSA-796p-j2gh-9m2q)

2) Enforcement dello stato TCB (Alto)

Problema: Il verificatore forniva lo stato del TCB come campo informativo, ma non applicava policy di rifiuto per livelli TCB revocati o obsoleti, con il rischio di configurazioni eccessivamente permissive.

Remediation: Il verificatore adotta ora una postura di sicurezza più “opinionata”. I controlli sullo stato del TCB sono applicati di default e il booleano is_valid è stato deprecato per garantire che gli sviluppatori gestiscano esplicitamente la valutazione della postura di sicurezza.

3) Verifica dell’attestazione GPU (Basso)

Problema: I dati di attestazione GPU venivano mostrati senza una verifica crittografica della catena di certificati dei dispositivi NVIDIA; inoltre, il binding CPU↔GPU non era applicato a livello di piattaforma.

Remediation: Il Trust Center è stato aggiornato con challenge basate su nonce, verifica delle quote NRAS e validazione JWT. La verifica del Confidential Computing mode della GPU in fase di boot è pianificata per una futura release di dstackOS.

4) SSRF tramite URL PCCS controllato dal client (Basso)

Problema: Il parametro pccs_url consentiva ai chiamanti di indirizzare richieste server-side verso endpoint arbitrari.

Remediation: Il parametro è stato rimosso dall’API pubblica.

5) Semantica della verifica degli Event Log (Basso)

Problema: La semantica di event_log_verified poteva essere fraintesa (replay del digest vs verifica semantica).

Remediation: La documentazione è stata chiarita. Gli event log IMR 0–2 verranno rimossi nella prossima release per eliminare ambiguità.

6) Verifica TLS per PCCS (Basso)

Problema: La configurazione predefinita bypassava la verifica del certificato TLS per le connessioni PCCS, scelta pensata per lo sviluppo locale ma inadatta alla produzione.

Remediation: Il valore predefinito è stato cambiato in “Verified”. La verifica dei certificati TLS è ora un requisito obbligatorio, salvo esplicito opt-out per ambienti di test locali.

7) Freshness del certificato RA-TLS (Trade-off di design)

Valutazione: RA-TLS di dstack segue lo stesso modello architetturale di RA-TLS di Intel Gramine. L’attestazione lega la chiave privata del certificato alle misurazioni del TEE, anziché a singole sessioni. Lo scenario proposto richiede l’estrazione della chiave dall’interno di una CVM in produzione; in tal caso, la remediation corretta è la revoca delle misurazioni, non la freshness a livello di sessione.

Impatto

• Tutti i problemi trovati e accettati sono stati corretti e distribuiti.
• Nessuna evidenza di sfruttamento attivo in produzione.
• Nessuna azione richiesta per gli utenti dstack o gli integratori downstream. Gli utenti dcap-qvl dovrebbero aggiornare all’ultima versione.

Roadmap di rafforzamento della sicurezza

• Integrazione GPU TEE: verifica del Confidential Computing mode in fase di boot in dstack-os.
• Miglioramenti all’API del verificatore: separazione più chiara tra validità crittografica e valutazione della postura di sicurezza.
• Programma formale di bug bounty: valutazione di un programma strutturato.

Ringraziamenti

Ringraziamo Rahul Saxena e GuyPhy (Bluethroat Labs) per aver identificato questi problemi e per la collaborazione durante tutto il processo di risoluzione. La ricerca indipendente in ambito sicurezza è essenziale per l’integrità delle infrastrutture TEE e incoraggiamo una continua revisione del codebase di dstack.