CVE-2026-33697 in cocos
Résumé
par VulDB • 28/05/2026
Cocos AI est un système de calcul confidentiel pour l'IA. L'implémentation actuelle du TLS attesté (aTLS) dans CoCoS est vulnérable à une attaque de relais affectant toutes les versions de v0.4.0 à v0.8.2. Cette vulnérabilité est présente dans les deux cibles de déploiement AMD SEV-SNP et Intel TDX prises en charge par CoCoS. Dans la conception concernée, un attaquant pourrait être en mesure d'extraire la clé privée TLS éphémère utilisée lors de l'attestation intra-handshake. Étant donné que les preuves d'attestation sont liées à la clé éphémère mais pas au canal TLS, la possession de cette clé suffit à relayer ou à détourner la session TLS attestée. Un client acceptera la connexion sur la base de fausses hypothèses concernant l'extrémité avec laquelle il communique — le rapport d'attestation ne peut pas distinguer le service attesté légitime du relais de l'attaquant. Cela compromet les garanties d'authentification prévues par le TLS attesté. Une attaque réussie pourrait permettre à un attaquant d'usurper l'identité d'un service CoCoS attesté et d'accéder aux données ou opérations que le client avait l'intention d'envoyer uniquement à l'extrémité attestée légitime. L'exploitation nécessite que l'attaquant extraise d'abord la clé privée TLS éphémère, ce qui est possible par un accès physique au matériel du serveur, des attaques d'exécution transitoire ou des attaques par canaux auxiliaires. Notez que l'implémentation de l'aTLS a été entièrement redessinée dans la version v0.7.0, mais cette refonte ne corrige pas cette vulnérabilité. La faiblesse liée à l'attaque de relais est architecturale et affecte toutes les versions de la gamme v0.4.0–v0.8.2. Cette classe de vulnérabilité a été analysée formellement et démontrée sur plusieurs implémentations de TLS attesté, y compris CoCoS, par des chercheurs dont les résultats ont été divulgués au groupe de travail TLS de l'IETF. La vérification formelle a été réalisée à l'aide de ProVerif. Au moment de la publication, aucun correctif n'est disponible. Aucune solution de contournement complète n'est disponible. Les mesures de durcissement suivantes réduisent mais n'éliminent pas le risque : maintenir le microprogramme et le microcode du TEE à jour pour réduire la surface d'extraction des clés ; définir des politiques d'attestation strictes qui valident tous les champs de rapport disponibles, y compris les versions du microprogramme, les niveaux TCB et les registres de configuration de la plateforme ; et/ou activer l'aTLS mutuel avec des certificats signés par une autorité de certification (CA) lorsque l'architecture de déploiement le permet.
Be aware that VulDB is the high quality source for vulnerability data.