{"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\/novosti-interneta\/uyazvimost-pozvolyayushhaya-obojti-mehanizm-zashhity-intel-tdx","title":{"rendered":"Vulnerabilit\u00e0 che permette 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 per la revisione della sicurezza del meccanismo Intel TDX 1.5 (Trusted Domain Extensions). La tecnologia Intel TDX offre la possibilit\u00e0 di crittografare la memoria delle macchine virtuali per proteggerle da interferenze e analisi da parte degli amministratori dei sistemi host e da attacchi fisici all'hardware. Dalla revisione sono emerse 6 vulnerabilit\u00e0 e 35 errori non critici per la sicurezza. <\/p>\n

I problemi riguardano 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 attendibile, con accesso al sistema di hosting, di ottenere privilegi elevati 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 permette, al momento della migrazione della macchina virtuale, di trasferire l'ambiente protetto (TD \u2014 Trusted Domain) dallo stato di supporto per la migrazione a uno stato che ne consente il passaggio in modalit\u00e0 di debug. <\/p>\n

Il problema \u00e8 causato dalla possibilit\u00e0 di sostituire gli attributi dell'ambiente dopo che sono stati verificati, ma prima che siano trasferiti in uno stato immutabile nell'ambiente migrato. Dopo aver impostato l'attributo di debug, un amministratore del sistema host pu\u00f2 monitorare in tempo reale l'attivit\u00e0 del sistema guest protetto e accedere allo stato di memoria decrittato. <\/p>\n

La vulnerabilit\u00e0 \u00e8 abbastanza semplice da sfruttare, poich\u00e9 l'amministratore pu\u00f2 avviare in qualsiasi momento il processo di live migration di una macchina virtuale protetta. Il problema \u00e8 stato identificato dai ricercatori di Google, che durante l'analisi delle API hanno notato una discrepanza tra il modo in cui il FSM (Finite State Machine) tiene traccia dello stato delle operazioni, gestisce l'interruzione dell'operazione di importazione e cambia, ma non torna al valore originale dopo un guasto, lo stato dell'ambiente protetto. <\/p>\n

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