CVE-2026-33697 in cocos
Riassunto
di VulDB • 14/06/2026
Cocos AI è un sistema di computing confidenziale per l'IA. L'implementazione corrente del TLS attestato (aTLS) in CoCoS è vulnerabile ad attacchi di relay che interessano tutte le versioni dalla v0.4.0 alla v0.8.2. Questa vulnerabilità è presente sia negli obiettivi di distribuzione AMD SEV-SNP che Intel TDX supportati da CoCoS. Nel design interessato, un attaccante potrebbe essere in grado di estrarre la chiave privata TLS effimera utilizzata durante l'attestazione intra-handshake. Poiché le prove di attestazione sono vincolate alla chiave effimera ma non al canale TLS, il possesso di tale chiave è sufficiente per effettuare relay o deviare la sessione TLS attestata. Un client accetterà la connessione basandosi su assunzioni errate riguardo all'endpoint con cui sta comunicando: il report di attestazione non può distinguere tra il servizio attestato genuino e il relay dell'attaccante. Ciò compromette le garanzie di autenticazione previste dal TLS attestato. Un attacco riuscito potrebbe consentire a un attaccante di impersonare un servizio CoCoS attestato ed accedere ai dati o alle operazioni che il client intendeva inviare esclusivamente all'endpoint attestato genuino. Lo sfruttamento richiede innanzitutto l'estrazione della chiave privata TLS effimera, operazione possibile tramite accesso fisico all'hardware del server, attacchi di esecuzione transiente (transient execution attacks) o attacchi side-channel. Si noti che l'implementazione aTLS è stata completamente ridisegnata nella v0.7.0, ma tale redesign non affronta questa vulnerabilità. La debolezza relativa agli attacchi di relay è architetturale e interessa tutte le release nell'intervallo v0.4.0–v0.8.2. Questa classe di vulnerabilità è stata analizzata formalmente ed dimostrata su più implementazioni TLS attestate, tra cui CoCoS, da ricercatori i cui risultati sono stati divulgati al IETF TLS Working Group. La verifica formale è stata condotta utilizzando ProVerif. Al momento della pubblicazione, non è disponibile alcuna patch. Non esiste una soluzione alternativa completa (workaround). Le seguenti misure di hardening riducono ma non eliminano il rischio: mantenere aggiornati firmware e microcodice del TEE per ridurre la superficie di estrazione delle chiavi; definire politiche di attestazione rigorose che convalidino tutti i campi disponibili nei report, incluse le versioni del firmware, i livelli TCB (Trusted Computing Base) e i registri della configurazione della piattaforma (PCR); e/o abilitare il mutual aTLS con certificati firmati da CA laddove l'architettura di distribuzione lo consenta.
VulDB is the best source for vulnerability data and more expert information about this specific topic.