{"id":160597,"date":"2026-02-11T17:11:57","date_gmt":"2026-02-11T15:11:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-pozvolyayushhaya-obojti-mehanizm-zashhity-intel-tdx"},"modified":"2026-02-11T17:11:57","modified_gmt":"2026-02-11T15:11:57","slug":"uyazvimost-pozvolyayushhaya-obojti-mehanizm-zashhity-intel-tdx","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/uyazvimost-pozvolyayushhaya-obojti-mehanizm-zashhity-intel-tdx","title":{"rendered":"Vuln\u00e9rabilit\u00e9 permettant de contourner le m\u00e9canisme de protection Intel TDX","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Les entreprises Google et Intel ont publi\u00e9 les r\u00e9sultats (PDF) de leur collaboration pour l'audit de s\u00e9curit\u00e9 du m\u00e9canisme Intel TDX 1.5 (Trusted Domain Extensions). La technologie Intel TDX permet le chiffrement de la m\u00e9moire des machines virtuelles pour les prot\u00e9ger des intrusions et des analyses de l'administrateur du syst\u00e8me h\u00f4te ainsi que des attaques physiques sur le mat\u00e9riel. L'audit a r\u00e9v\u00e9l\u00e9 6 vuln\u00e9rabilit\u00e9s et 35 erreurs sans impact sur la s\u00e9curit\u00e9. <\/p>\n

Les probl\u00e8mes concernent les processeurs Intel Xeon de 6e g\u00e9n\u00e9ration ainsi que ceux des 4e et 5e g\u00e9n\u00e9rations des processeurs Intel Xeon Scalable. Les vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 corrig\u00e9es dans la mise \u00e0 jour du microcode d'hier. Un outil pour exploiter les vuln\u00e9rabilit\u00e9s dans Intel TDX et des prototypes d'exploits pour deux vuln\u00e9rabilit\u00e9s (CVE-2025-30513, CVE-2025-32007) ont \u00e9t\u00e9 publi\u00e9s sur GitHub. <\/p>\n

La vuln\u00e9rabilit\u00e9 la plus critique (CVE-2025-30513) permet \u00e0 un administrateur non fiable ayant acc\u00e8s au syst\u00e8me h\u00f4te d'\u00e9lever ses privil\u00e8ges et de compromettre compl\u00e8tement les garanties de s\u00e9curit\u00e9 offertes par la technologie Intel TDX. Cette vuln\u00e9rabilit\u00e9 est caus\u00e9e par une condition de course dans l'un des modules TDX, permettant, lors de la migration d'une machine virtuelle, de transf\u00e9rer un environnement prot\u00e9g\u00e9 (TD \u2014 Trusted Domain) de l'\u00e9tat de support de migration \u00e0 un \u00e9tat permettant le passage en mode d\u00e9bogage. <\/p>\n

Le probl\u00e8me est caus\u00e9 par la possibilit\u00e9 de falsification des attributs d'environnement apr\u00e8s leur v\u00e9rification, mais avant leur passage en \u00e9tat immuable dans l'environnement transf\u00e9r\u00e9. Apr\u00e8s avoir d\u00e9fini l'attribut de d\u00e9bogage, l'administrateur du syst\u00e8me h\u00f4te peut suivre en temps r\u00e9el l'activit\u00e9 de la machine virtuelle prot\u00e9g\u00e9e et acc\u00e9der \u00e0 l'\u00e9tat d\u00e9chiffr\u00e9 de la m\u00e9moire. <\/p>\n

La vuln\u00e9rabilit\u00e9 est suffisamment simple \u00e0 exploiter, car l'administrateur peut \u00e0 tout moment initier le processus de migration en direct de la machine virtuelle prot\u00e9g\u00e9e. Le probl\u00e8me a \u00e9t\u00e9 identifi\u00e9 par des chercheurs de Google, qui, lors de l'examen de l'API, ont remarqu\u00e9 un d\u00e9calage entre la mani\u00e8re dont l'\u00e9tat des op\u00e9rations est suivi dans la FSM (Finite State Machine), comment l'interruption de l'op\u00e9ration d'importation est g\u00e9r\u00e9e et comment l'\u00e9tat prot\u00e9g\u00e9 est modifi\u00e9 mais pas r\u00e9initialis\u00e9 \u00e0 sa valeur d'origine apr\u00e8s un \u00e9chec. <\/p>\n

Vuln\u00e9rabilit\u00e9s moins dangereuses : <\/p>\n