{"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\/it\/blog\/news\/uyazvimost-pozvolyayushhaya-obojti-mehanizm-zashhity-intel-tdx","title":{"rendered":"Vulnerabilit\u00e0 che consente di eludere il meccanismo di protezione Intel TDX","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Le aziende Google e Intel hanno rivelato i risultati (PDF) della loro collaborazione sulla revisione della sicurezza del meccanismo Intel TDX 1.5 (Trusted Domain Extensions). La tecnologia Intel TDX implementa la possibilit\u00e0 di crittografare la memoria delle macchine virtuali per proteggerle da interferenze e analisi da parte dell'amministratore del sistema host e da attacchi fisici all'hardware. A seguito della revisione sono state individuate 6 vulnerabilit\u00e0 e 35 errori non critici. <\/p>\n

I problemi interessano le CPU Intel Xeon di sesta generazione, cos\u00ec come le generazioni 4 e 5 dei processori Intel Xeon Scalable. Le vulnerabilit\u00e0 sono state risolte nell'aggiornamento del microcodice di ieri. Su GitHub \u00e8 stato pubblicato un toolkit per sfruttare le vulnerabilit\u00e0 in Intel TDX e prototipi di exploit per due vulnerabilit\u00e0 (CVE-2025-30513, CVE-2025-32007). <\/p>\n

La vulnerabilit\u00e0 pi\u00f9 pericolosa (CVE-2025-30513) consente a un amministratore non affidabile, che ha accesso al sistema host, di elevare i propri privilegi e compromettere completamente le garanzie di sicurezza fornite dalla tecnologia Intel TDX. La vulnerabilit\u00e0 \u00e8 causata da una condizione di gara in uno dei moduli TDX, che consente, durante la migrazione di una macchina virtuale, di trasferire l'ambiente protetto (TD \u2014 Trusted Domain) da uno stato che supporta la migrazione a uno stato che consente il passaggio in modalit\u00e0 di debug. <\/p>\n

Il problema \u00e8 causato dalla possibilit\u00e0 di alterare gli attributi dell'ambiente nel momento successivo alla loro validazione, ma prima del loro trasferimento in uno stato immutabile nell'ambiente migrato. Una volta impostato l'attributo di debug, l'amministratore del sistema host pu\u00f2 monitorare in tempo reale l'attivit\u00e0 del sistema guest protetto e accedere allo stato di memoria decrittografato. <\/p>\n

La vulnerabilit\u00e0 \u00e8 abbastanza semplice da sfruttare, poich\u00e9 l'amministratore pu\u00f2 avviare in qualsiasi momento il processo di live-migrazione della macchina virtuale protetta. Il problema \u00e8 stato identificato dai ricercatori di Google, che, studiando l'API, hanno notato una discrepanza tra come lo stato delle operazioni viene monitorato nella FSM (Finite State Machine), come viene gestita l'interruzione dell'operazione di importazione, e come lo stato dell'ambiente protetto viene cambiato, ma non ripristinato al valore iniziale dopo un guasto. <\/p>\n

Vulnerabilit\u00e0 meno pericolose: <\/p>\n