Vulnerabilità nei processori Intel: come attivare le protezioni

Microsoft spiega come attivare le varie linee di difesa per fronteggiare eventuali tentativi di sfruttamento dei nuovi bug recentemente scoperti all'interno dei processori Intel.

A corollario dell’ultimo “patch day” di novembre, Microsoft ha pubblicato una serie di informazioni per aiutare gli utenti di Windows a mitigare gli effetti degli ultimi bug scoperti nei processori Intel.
La società di Redmond ha innanzi tutto confermato che gli aggiornamenti presentati in questa pagina di supporto e riferiti a tutte le versioni di Windows al momento supportate, consentono di limitare i rischi dovuti alla presenza di una nuova vulnerabilità nei meccanismi di esecuzione speculativa integrati nelle CPU (CVE-2019-11135). Questa volta, ad essere oggetto di un problema, sono le Intel Transactional Synchronization Extensions (TSX): Nuova vulnerabilità nei processori Intel: ZombieLoad 2.

Come spiegato nell’articolo, la falla denominata ZombieLoad 2, può consentire a un utente malintenzionato o a un processo dannoso di sottrarre dati personali e informazioni sensibili attingendo al contenuto di aree della memoria che non dovrebbero normalmente risultare accessibili.

I tecnici di Microsoft hanno spiegato che la patch permette di lenire il problema e che l’aggiornamento del BIOS della scheda madre (contenente il microcode aggiornato distribuito da Intel) è comunque consigliato.
Da parte sua, Intel ha confermato che i processori affetti dal problema sulle estensioni TSX sono i Core di decima, nona e ottava generazione, gli Xeon Scalable di seconda generazione, gli Xeon W ed E, i Pentium Gold e i Celeron 5000.

Se si volesse evitare di correre rischi preferendo disattivare completamente il supporto TSX a livello di processore, Microsoft spiega che è possibile farlo con una semplice modifica sulla configurazione del registro di sistema.
Per procedere, basta aprire il prompt dei comandi con i diritti di amministratore quindi digitare quanto segue:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel" /v DisableTsx /t REG_DWORD /d 1 /f

Al termine dell’operazione bisognerà necessariamente riavviare il sistema. Per riattivare eventualmente TSX sulla CPU, basterà impartire lo stesso comando sostituendo /d 1 con /d 0.

Né Microsoft né Intel al momento si esprimono sul calo di performance stimato che comporta la disattivazione completa di TSX o l’installazione delle patch hardware e software.

La seconda vulnerabilità (contraddistinta dall’identificativo CVE-2018-12207) della quale parla Microsoft è quella documentata a questa pagina, contenente i riferimenti alle patch per le varie versioni di Windows.

In questo caso, un utente che eseguisse codice malevolo sulla macchina, può rischiare l’improvviso blocco della stessa e quindi la mancata erogazione dei servizi in esecuzione (attacco di tipo Denial of Service, DoS).

Intel conferma e rivela che potenzialmente affetti dal problemi sono tutti i processori Core di ottava generazione e precedenti, i Core della serie X, i Pentium Gold, i Celeron G, gli Xeon Scalable di prima e seconda generazione, gli Xeon E7 (v2/v3/b4), gli Xeon E5 (v2/v3/v4), gli Xeon E3 (fino alla v6), gli Xeon E/D/W e le CPU Xeon legacy.

Pur installando gli ultimi aggiornamenti Microsoft in Windows, la protezione contro i tentativi di attacco DoS risulterà disattivata per default. Sui sistemi che utilizzano Hyper-V, si potrà abilitarla ricorrendo al comando seguente:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v IfuErrataMitigations /t REG_DWORD /d 1 /f

Ci preme però sottolineare un aspetto a nostro avviso importante: nessuna delle vulnerabilità è al momento sfruttabile in modalità remota. Ciò significa che per estrarre informazioni sensibili e provocare il malfunzionamento della macchina con un attacco DoS è necessario che l’utente malintenzionato disponga già dell’accesso al sistema da aggredire o che comunque venga avviato un eseguibile dannoso. L’aspetto negativo è che non sono necessari i diritti amministrativi.
Se da un lato per gli utenti finali tutto sommato cambia poco (mai eseguire file sospetti, massima attenzione agli utenti che possono accedere alle singole macchine), a nostro avviso il problema è critico lato server, soprattutto sui sistemi condivisi come quelli messi a disposizione dei clienti dai provider di servizi cloud. In queste configurazioni, un aggressore potrebbe superare i limiti della macchina virtuale e sottrarre informazioni altrui o danneggiare altri utenti.

Ti consigliamo anche

Link copiato negli appunti