Il 10 marzo 2020, un nuovo importante bug riguardante la sicurezza delle CPU Intel è salito agli onori della cronaca, si tratta di ciò che viene definito “Snoop-assisted L1 Data Sampling” e consente il prelievo di dati (anche se fondamentalmente si tratta di poche informazioni), direttamente dalla cache L1 di un determinato Core.
Nella pratica, ciò che viene sfruttato è il controller (snooper) deputato al mantenimento dell’uniformità di informazioni condivise (coerenza) tra le varie cache appartenenti ai core di una CPU, l'attacco ha luogo durante il trasferimento di questi dati che avviene nei sistemi che utilizzano una memoria condivisa distribuita.
Per fare un esempio non troppo complesso, pensiamo ad un processore con due singoli core fisici, ognuno ovviamente dotato di una propria cache L1D, ovvero una cache dedicata ai dati. Partiamo dal presupposto che il malintenzionato di turno deve essere in grado di poter interagire con il core 0 (ad esempio) ed eseguire delle azioni su di esso, cosa difficile senza permessi, ma non impossibile.
Ad un certo punto un processo memorizzerà dati sulla cache L1 del core fisico 0 e resterà in attesa, mentre, a causa di un secondo processo in esecuzione sul core fisico 1 che vorrà accedere ai dati precedentemente menzionati, partirà un azione di snoop da parte di quest’ultimo core, verso la cache del primo. Durante lo stesso ciclo di Clock, nel quale lo snoop giunge al core fisico 0, non resta quindi che intercettare tale operazione e causare un errore che genererà ciò che la stessa casa madre definisce un “TSX Asynchronous Abort” (Intel "Transactional Synchronization Extensions" è un sistema che serve proprio a migliorare le prestazioni dei software multi-thread).
Il problema giunge proprio ora: durante un errore del genere che blocca tutto il processo appena descritto, alcune operazioni che non sono state ancora completate vanno a leggere i dati direttamente dalle cache e li trasferiscono ai processi dipendenti, rendendoli facilmente accessibili da chiunque.
Capito il funzionamento della falla e il grado di conoscenze richiesto per poterla sfruttare, veniamo dunque al punto. Come riporta The Register, l’ingegnere Balbir Singh di AWS (Amazon Web Service) ha proposto una soluzione che sarebbe poi dovuta essere integrata nella prossima versione del kernel linux, prima di venir spazzata via da Linus Torvalds in persona, per motivi che tra poco vedremo.
La soluzione proposta da Singh quantomeno per mitigare il problema, seppur con importanti danni prestazionali, rispecchia quanto di più ovvio si possa pensare: ogni qualvolta viene effettuato un context switch (ovvero un’operazione di salvataggio dello stato delle attività dei core per consentire alla CPU di essere utilizzata in altre attività per poi, in base alla politica di scheduling, ripristinare ciò che è stato precedentemente messo in pausa) deve anche essere svuotata la cache L1D.
Se a prima vista steste pensando che questa potrebbe essere la giusta via da seguire, anche perdendo qualcosa in termini di efficienza, leggete le perplessità di Torvalds, perché, come sempre, difficilmente gli si può dar torto.
I punti a favore della tesi del papà di Linux sono vari, ma più o meno tutti si concentrano sul fatto che il gioco non valga la candela e che agire in modo così indiscriminato, rivoluzionando il modo di funzionare del kernel per qualsiasi CPU, non abbia in ogni caso senso. Torvalds si spinge quindi a definire l’azione di svuotare la cache L1D ad ogni context switch, senza nemmeno considerare il processore su cui si opera, un qualcosa che va “al di là della stupidità”.
Non contento aggiunge che, grazie all'Hyper-threading che comunemente divide un core fisico in due con ciò che ne consegue, un attacco del genere potrebbe essere portato a termine ben prima che avvenga il cambio di attività e che un attaccante non starebbe certo lì ad aspettare tale operazione, posizionandosi in ascolto sul core “fratello” generato dal multi-threading e rendendo il flush della cache una totale perdita di tempo e prestazioni.
Alla lista dei possibili svantaggi si aggiunge il codice, che risulta molto più appesantito e difficile da seguire, e la difficoltà in sé di tutta l’operazione ritenuta così elevata da non essere praticabile in qualsiasi contesto o verso un qualsiasi utente, dato che nessuno impiegherebbe un elevato impegno e risorse sofisticate, senza un obiettivo realmente interessante.
Un altro motivo di disappunto riguarda i processi compromessi. Poiché normalmente i processi appartengono tutti ad un unico utente, Torvalds non trova commisurata la soluzione di così basso livello proposta e quindi così radicale, verso un problema che potrebbe non presentarsi mai. In questo caso però troviamo la pronta risposta di Singh che fa notare come in realtà un singolo utente possa eseguire attività multiple e se una di queste fosse compromessa, la falla potrebbe essere comunque sfruttata.
Purtroppo, dal punto di vista sicurezza, Intel da tempo non naviga in buone acque. Anche se spesso si tratta di problemi che difficilmente coinvolgono gli utenti più piccoli, la risonanza mediatica che ne deriva intacca la fiducia di tutti e, complici anche le ottime proposte della concorrenza, le quote di mercato ne risentono in percentuali non trascurabili.
Augurandoci che la casa di Santa Clara sia in grado di trovare presto una soluzione alle falle che ultimamente affliggono i propri prodotti, vi lasciamo con la lista di tutte le CPU interessate da tale vulnerabilità, invitandovi come sempre a fare molta attenzione verso qualsiasi file o programma che andrete ad eseguire sul vostro PC.
Preoccupati da eventuali fughe di dati? Non c’è molto che possiate fare per la falla descritta nell’articolo, ma un buon antivirus vi aiuterà sicuramente a star lontano dai guai. Uno dei migliori è Kaspersky Internet Security, acquistabile direttamente da Amazon.
