CVE-2026-33697

Riepilogo

Cocos AI è un sistema di confidential computing per l'IA. L'attuale implementazione di attested TLS (aTLS) in CoCoS è vulnerabile a un attacco di relay che interessa tutte le versioni dalla v0.4.0 alla v0.8.2. Questa vulnerabilità è presente sia nei target di deployment AMD SEV-SNP sia Intel TDX supportati da CoCoS. Nel design interessato, un attaccante potrebbe riuscire a estrarre la chiave privata TLS effimera utilizzata durante l'attestazione intra-handshake. Poiché l'evidenza di attestazione è vincolata alla chiave effimera ma non al canale TLS, il possesso di tale chiave è sufficiente per fare relay o dirottare la sessione aTLS attestata. Un client accetterà la connessione basandosi su presupposti errati riguardo all'endpoint con cui sta comunicando — il report di attestazione non può distinguere il servizio attestato autentico dal relay dell'attaccante. Ciò compromette le garanzie di autenticazione previste dall'attested TLS. Un attacco riuscito può consentire a un attaccante di impersonare un servizio CoCoS attestato e accedere a dati o operazioni che il client intendeva inviare solo all'endpoint attestato autentico. Lo sfruttamento richiede che l'attaccante estragga prima la chiave privata TLS effimera, cosa possibile tramite accesso fisico all'hardware del server, attacchi di transient execution o attacchi side-channel. Si noti che l'implementazione aTLS è stata completamente riprogettata nella v0.7.0, ma la riprogettazione non risolve questa vulnerabilità. La debolezza dell'attacco di relay è architetturale e interessa tutte le release nell'intervallo v0.4.0–v0.8.2. Questa classe di vulnerabilità è stata formalmente analizzata e dimostrata in molteplici implementazioni di attested TLS, incluso CoCoS, da ricercatori i cui risultati sono stati divulgati all'IETF TLS Working Group. La verifica formale è stata condotta utilizzando ProVerif. Al momento della pubblicazione, non è disponibile alcuna patch. Non è disponibile alcuna soluzione alternativa completa. Le seguenti misure di hardening riducono ma non eliminano il rischio: mantenere aggiornati firmware e microcode del TEE per ridurre la superficie di estrazione delle chiavi; definire policy di attestazione rigorose che convalidino tutti i campi disponibili del report, incluse le versioni del firmware, i livelli TCB e i platform configuration register; e/o abilitare aTLS mutuo con certificati firmati da CA laddove l'architettura di deployment lo consenta.