AMD avverte di nuovi attacchi Transient Scheduler (Tsa) che colpiscono un’ampia gamma di CPU.

L’azienda di semiconduttori segnala infatti una nuova serie di vulnerabilità hardware che interessano un vasto ventaglio di chipset e che potrebbero portare alla divulgazione di informazioni.

“La scoperta delle vulnerabilità Transient Scheduler Attacks (TSA) rappresenta un nuovo capitolo nella lunga serie di attacchi side-channel che colpiscono le Cpu moderne”, commenta Angelo Gazineo, Sales Specialist per Maticmind.

“In un mondo sempre più digitale, la gestione delle vulnerabilità non è solo una questione tecnica, ma un impegno strategico per proteggere il nostro ecosistema cyber”, continua Riccardo Paglia, Go To Market Manager per Maticmind.

“TSA rappresenta un’evoluzione nelle transient execution attacks, spostando l’attenzione dalla speculazione tradizionale (come avviene con Spectre) alla dinamica di schedulazione out-of-order direttamente interna ai core“, aggiunge Ada Spinelli, Cyber Threat Intelligence Analyst per Maticmind. Infatti queste vulnerabilità “rientrano in una categoria sempre più critica: la sicurezza speculativa, ovvero la protezione dei dati durante l’esecuzione speculativa delle istruzioni da parte della Cpu”, spiega Massimo Biagiotti, Cyber Competence Center Manager per Maticmind.

Ecco come mitigare il rischio.

Attacchi Transient Schedule (Tsa) contro le Cpu di Amd: ecco le vulnerabilità hardware

Le falle, note come Transient Scheduler Attacks (TSA), si manifestano sotto forma di canale laterale speculativo nelle sue Cpu che sfruttano i tempi di esecuzione delle istruzioni in condizioni microarchitetturali specifiche.

“Le nuove vulnerabilità TSA nei processori Amd permettono di accedere a dati sensibili, sfruttando la gestione delle operazioni della Cpu. Per sfruttare queste vulnerabilità, è necessario un accesso fisico o remoto alla macchina”, spiega Federico Savastano, Cyber Threat Intelligence Analyst per Maticmind.

“In alcuni casi, un aggressore potrebbe essere in grado di utilizzare queste informazioni sulla tempistica per dedurre dati da altri contesti, con conseguente fuga di informazioni”, ha dichiarato Amd in un avviso.

L’azienda ha dichiarato che i problemi sono frutto di una scoperta nell’ambito di uno studio pubblicato dai ricercatori di Microsoft e del Politecnico di Zurigo sul test di moderne Cpu contro gli attacchi di esecuzione speculativa come Meltdown e Foreshadow, sperimentando l’isolamento tra domini di sicurezza come macchine virtuali, kernel e processi.

“Paragonabili infatti a Meltdown e Spectre, questi attacchi sfruttano canali laterali per accedere a dati riservati, potenzialmente compromettendo l’isolamento tra processi o livelli di privilegio”, sottolinea Angelo Gazineo.

“Nonostante i punteggi CVSS relativamente bassi, l’impatto combinato è paragonato da più ricercatori alle storiche Spectre e Meltdown, perché mette in discussione l’isolamento tra workload”, sottolinea Riccardo Michetti.

Vulnerabilità hardware da non sottovalutare

“Negli ultimi anni, le vulnerabilità hardware – come quelle appena scoperte nei processori Amd, note come Transient Scheduler Attacks (Tsa) – sono state spesso messe in secondo piano rispetto a quelle software, più facili da sfruttare da remoto e quindi più ‘visibili’ per gli attaccanti”, spiega Riccardo Paglia.

“Tuttavia”, continua l’analista, “non dobbiamo sottovalutare questi rischi: anche se le TSA richiedono un accesso locale al dispositivo e condizioni specifiche per essere sfruttate, la loro diffusione su miliardi di Cpu Amd– dai computer desktop ai server aziendali – le rende un potenziale pericolo per la sicurezza dei dati sensibili, come password o informazioni riservate che potrebbero ‘filtrare’ tra processi diversi”.

Infatti, “le implicazioni più gravi includono la fuga di dati dal kernel, con conseguenti possibilità di escalation di privilegi o persistenza del malware“, mette in guardia Gazineo.

Quattro nuove CVE

In seguito alla divulgazione responsabile nel giugno 2024, ecco gli identificativi CVE delle falle:

• CVE-2024-36350 (punteggio CVSS: 5.6): una vulnerabilità di esecuzione transitoria in alcuni processori Amd può consentire a un utente malintenzionato di dedurre i dati da archivi precedenti, con potenziale perdita di informazioni privilegiate;
• CVE-2024-36357 (punteggio CVSS: 5.6): falla di esecuzione transitoria in alcuni processori Amd può consentire a un utente malintenzionato di dedurre i dati nella cache L1D, con potenziale perdita di informazioni sensibili attraverso confini privilegiati;
• CVE-2024-36348 (3.8): vulnerabilità di esecuzione transitoria in alcuni processori AMD può consentire a un processo utente di dedurre i registri di controllo in modo speculativo, anche se la funzione UMIP ( è abilitata, con potenziale perdita di informazioni
• CVE-2024-36349 (punteggio CVSS: 3,8) – Una vulnerabilità di esecuzione transitoria in alcuni processori AMD può consentire a un processo utente di dedurre TSC_AUX anche quando tale lettura è disabilitata, con potenziale perdita di informazioni.

“Sebbene difficili da sfruttare, la vasta diffusione delle Cpu coinvolte impone un’attenzione particolare, soprattutto in contesti aziendali e cloud. Questo caso evidenzia ancora una volta l’importanza della collaborazione tra vendor, ricercatori e sviluppatori nella gestione proattiva delle minacce. La sicurezza hardware resta un’area critica, spesso trascurata dagli utenti comuni, ma fondamentale per la protezione dell’intero ecosistema digitale”, evidenzia Angelo Gazineo.

Le varianti

“Amd distingue due varianti, TSA-L1 e TSA-SQ, che coinvolgono rispettivamente la cache L1 e lo store queue dei processori. I sistemi desktop, mobile e datacenter basati su Ryzen, EPYC, Threadripper, Instinct e persino alcuni modelli Athlon rientrano nella superficie d’attacco”, aggiunge Riccardo Michetti.

Le Cpu Amd coinvolte

AMD ha descritto il TSA come una “nuova classe di canali laterali speculativi” che colpisce le sue CPU e ha dichiarato di aver rilasciato aggiornamenti del microcodice per i processori interessati:

• Terza generazione Amd EPYC Processors
• Quarta generazione AMD EPYC Processors
• Amd Instinct MI300A
• Amd Ryzen 5000 Series Desktop Processors
• Amd Ryzen 5000 Series Desktop Processors with Radeon Graphics
• Amd Ryzen 7000 Series Desktop Processors
• Amd Ryzen 8000 Series Processors with Radeon Graphics
• Amd Ryzen Threadripper PRO 7000 WX-Series Processors
• Amd Ryzen 6000 Series Processors with Radeon Graphics
• Amd Ryzen 7035 Series Processors with Radeon Graphics
• Amd Ryzen 5000 Series Processors with Radeon Graphics
• Amd Ryzen 7000 Series Processors with Radeon Graphics
• Amd Ryzen 7040 Series Processors with Radeon Graphics
• Amd Ryzen 8040 Series Mobile Processors with Radeon Graphics
• Amd Ryzen 7000 Series Mobile Processors
• Amd EPYC Embedded 7003
• Amd EPYC Embedded 8004
• Amd EPYC Embedded 9004
• Amd EPYC Embedded 97X4
• Amd Ryzen Embedded 5000
• Amd Ryzen Embedded 7000
• Amd Ryzen Embedded V3000

“I processori AMD vulnerabili sono utilizzati in Pc, server, dispositivi IoT e infrastrutture, rendendo critica la gestione delle vulnerabilità hardware per proteggere i dati e le infrastrutture critiche. La protezione di tali asset è quindi da leggere in un quadro di sicurezza nazionale ed europea“, sottolinea Federico Savastano.

Il rischio di falso completamento

L’azienda ha anche osservato che le istruzioni che leggono i dati dalla memoria possono subire il cosiddetto “falso completamento”, che si verifica quando l’hardware della Cpu si aspetta che le istruzioni di caricamento si completino rapidamente, ma esiste una condizione che impedisce che ciò avvenga.

Queste “quattro nuove CVE possono consentire attacchi side-channel sfruttano l’effetto di ‘false completion’ delle istruzioni di caricamento, riuscendo a far trapelare informazioni da contesti privilegiati (kernel, hypervisor, macchine virtuali) pur partendo da codice in user-space“, conferma Riccardo Michetti, Cyber Threat Intelligence Manager per Maticmind.

In questo caso, le operazioni dipendenti possono essere programmate per l’esecuzione prima che venga rilevato il falso completamento.

“Sfruttando meccanismi di false completion, questa tecnica consente accessi side-channel a strutture microarchitetturali come la Store Queue e la L1D cache, anche in assenza di privilegi elevati. Le CVE 202436350 e 202436357 dimostrano quanto questa idea sia praticabile”, mette in evidenza Ada Spinelli.

Poiché il caricamento non è stato effettivamente completato, i dati associati a quel caricamento sono considerati non validi. Il carico verrà ri-eseguito in un secondo momento per essere completato correttamente e le operazioni dipendenti verranno eseguite di nuovo con i dati validi quando saranno pronte.

I dettagli

A differenza di altri comportamenti speculativi come il Predictive Store Forwarding, i carichi che subiscono un falso completamento non comportano un eventuale flush della pipeline.

Mentre i dati non validi associati a un falso completamento possono essere inoltrati alle operazioni dipendenti, le istruzioni di load e store che consumano questi dati non tentano di recuperare dati o di aggiornare lo stato della cache o del TLB. Di conseguenza, il valore di questi dati non validi non può essere dedotto con metodi standard di canale laterale transitorio.

Nei processori affetti da Tsa, i dati non validi possono tuttavia influenzare la tempistica di altre istruzioni in esecuzione da parte della Cpu in un modo che potrebbe essere rilevabile da un utente malintenzionato.

“Nel settore farmaceutico, lo studio degli effetti collaterali di un medicinale sull’organismo avviene solo dopo un lungo e rigoroso periodo di sperimentazione clinica. Tuttavia, anche anni di test non sempre riescono a prevedere tutte le reazioni indesiderate che possono emergere in condizioni reali e complesse”, spiega Giovanni Del Panta, Responsabile Cybersecurity Architects per Maticmind.

“In modo analogo, quando si ha a che fare con attacchi come il Transient Scheduler Attack (TSA), che sfruttano comportamenti collaterali e profondamente radicati nella microarchitettura della Cpu, diventa molto difficile prevenirli esclusivamente attraverso le tradizionali fasi di validazione e verifica. Queste, infatti, hanno una durata limitata (spesso di pochi mesi), sono orientate principalmente a garantire le performance, lo stress test e la funzionalità by design, più che a rilevare effetti secondari emergenti.
Il principio di iniziare l’elaborazione di un flusso di dati prima che esso sia interamente disponibile non è nuovo: è lo stesso che ha guidato l’introduzione, anni fa, della tecnica cut-through switching nella gestione del traffico di rete, in alternativa allo store-and-forward. Anche in quel caso, il guadagno in latenza è stato accompagnato dall’apertura di nuove superfici di attacco, in particolare DDoS e vulnerabilità documentate tramite CVE”, prosegue Giovanni Del Panta.

Come mitigare i rischi dei Transient Scheduler Attacks (Tsa)

Innanzitutto occorre applicare le patch appena avverrà il rilascio. “Nonostante la loro pericolosità, AMD ha classificato il rischio come medio, sottolineando però l’urgenza di applicare le patch disponibili per mitigare i rischi“, sottolinea Gazineo.

“Le patch di AMD, che combinano microcodice e aggiornamenti del kernel, aiutano a ridurre i rischi, ma comportano comunque un overhead, soprattutto in ambienti cloud multi-tenant”, mette in guardia Ada Spinelli: “TSA evidenzia quanto sia importante ampliare il nostro concetto di minaccia, andando oltre le classiche aree di rischio come ISA o branch prediction, e considerando anche la logica temporale dei core come possibile superficie di attacco”.

“L’impatto potenziale in scenari come cloud o ambienti multi-tenant resta significativo, soprattutto perché permette a un’applicazione meno privilegiata di ‘sbirciare’ informazioni riservate di un altro contesto, che sia un’altra VM o addirittura il kernel”, conferma Luca Mantini, Responsabile Solution Engineering per Maticmind.

La sicurezza speculativa

La sicurezza speculativa, ovvero la protezione dei dati durante l’esecuzione speculativa delle istruzioni da parte della CPU, è “un meccanismo, pensato per migliorare le performance, può aprire canali laterali attraverso cui un attaccante—anche senza privilegi—può inferire informazioni da contesti isolati. Il TSA rappresenta quindi una superficie d’attacco evoluta, particolarmente pericolosa in ambienti multi-tenant, dove la co-residenza di macchine virtuali è comune. La possibilità di leakage tra processi o VM mette a rischio dati personali e sensibili, sollevando criticità rispetto al GDPR (Art. 5 e 32) e alla Direttiva NIS2, che impone misure tecniche proporzionate al rischio. Le patch di AMD sono un primo passo, ma vanno verificate con test offensivi mirati, validando le mitigazioni a livello di microarchitettura. La sicurezza speculativa non è più solo un tema accademico: è un fronte reale dove performance e privacy devono coesistere senza compromessi”, sottolinea Massimo Biagiotti.

Risposta rapida, ma non basta

“La risposta dell’azienda è stata rapida e questo è un elemento rassicurante: microcode e BIOS contenenti la patch sono già disponibili tramite i principali OEM, mentre i kernel Linux e gli aggiornamenti cumulativi di Windows distribuiti a partire dal 10 luglio integrano le contromisure automatiche“, rassicura Michetti.

“Il fatto che l’exploit richieda l’esecuzione locale di codice riduce la superficie remota, non è infatti possibile attivarlo con un semplice script da browser né da rete, il che spiega i rating di gravità medio-bassi. In aggiunta, Amd offre un meccanismo di mitigazione temporanea, basato sull’istruzione VERW, che può essere invocato dal sistema operativo nei passaggi da codice privilegiato a non privilegiato, permettendo di guadagnare tempo mentre la fleet viene aggiornata”, continua Michetti.

Tuttavia “la vulnerabilità espone un rischio notevole negli ambienti multi-tenant. Il canale di esfiltrazione non lascia tracce nei log tradizionali, perché si basa solo su misure di latenza; questo rende l’attività quasi invisibile a strumenti di threat hunting e analisi forense. L’implementazione delle correzioni, inoltre, non è banale: occorre allineare firmware, hypervisor, container runtime e qualunque meccanismo di live migration, con possibili finestre di incoerenza tra nodi. Chi scegliesse l’opzione VERW deve poi preventivare un impatto sulle prestazioni“, mette in guardia Michetti.

Inoltre, secondo Luca Mantini, “Inoltre, come sempre, il vero problema sarà garantire che tali aggiornamenti vengano effettivamente applicati a tutti i sistemi coinvolti. Storicamente, il deployment degli aggiornamenti del microcodice non è sempre stato immediato né uniforme, lasciando spesso ampie finestre temporali per eventuali attacchi mirati”.

In definitiva, “questa vicenda conferma una volta ancora che nella progettazione hardware la sicurezza deve essere sempre un fattore chiave fin dall’inizio, non una patch successiva. Anche se TSA non scatenerà probabilmente panico generalizzato, dovrebbe sicuramente far riflettere su come gestiamo, testiamo e aggiorniamo le nostre infrastrutture IT, specialmente in contesti sensibili come datacenter e ambienti virtualizzati”, sottolinea Luca Mantini.

Un compromesso consapevole

“La traiettoria naturale di mitigazione, in scenari di questo tipo, prevede un compromesso consapevole: si accetta una riduzione delle performance a favore di una maggiore sicurezza operativa. Si tratta di una scelta razionale, perché — a differenza degli esseri umani — i sistemi possono sopportare un’efficienza leggermente inferiore in cambio di una maggiore resilienza. Inoltre, è realistico pensare che l’evoluzione futura di ASIC e microarchitetture permetterà di recuperare il gap prestazionale nel medio termine.

Le contromisure oggi adottate seguono questo approccio e includono:

• restrizioni sull’esecuzione speculativa, già implementate in risposta a Spectre;
• randomizzazione delle code dello scheduler, per impedire pattern prevedibili e leak sistematici;
• flush dello scheduler in fase di context switch, analogamente a quanto già si fa con la cache”, avverte Giovanni Del Panta.

“Queste tecniche, pur comportando un degrado prestazionale, rappresentano una risposta strutturata e proporzionata.

Come segnalato nei report di vulnerabilità, attacchi di tipo TSA non sono facilmente eseguibili da remoto: richiedono accesso malevolo diretto alla macchina e strategie ripetitive di esfiltrazione, spesso basate su canali di comunicazione preesistenti tra applicazioni e kernel”, conclude Giovanni Del Panta.

Come proteggersi in termini operativi

“In termini operativi conviene procedere con la mappatura completa dell’hardware AMD presente in azienda, quindi applicare quanto prima i pacchetti di microcode forniti da produttori e distribuzioni, seguiti dai reboot orchestrati per assicurarsi che il nuovo firmware venga inizializzato. Fino a patch concluse, i workload che custodiscono dati sensibili come, per esempio, chiavi di pagamento, dovrebbero essere spostati su host dedicati oppure protetti con tecnologie di cifratura come SEV-SNP. Nei contesti dove l’aggiornamento non fosse immediatamente possibile, l’attivazione selettiva della mitigazione VERW offre un’ulteriore barriera, con l’avvertenza di monitorare costantemente l’impatto sulle latenze applicative”,

Soc per fare la differenza

Inoltre, “per mitigare questi rischi, un passo immediato è rafforzare i controlli sull’accesso ai dispositivi, limitando le possibilità di intrusioni indesiderate. In questo senso, implementare un Security Operations Center (Soc) – un centro dedicato al monitoraggio continuo – può fare la differenza: permette di rilevare in tempo reale attacchi avanzati e persistenti (APT), che spesso sfruttano debolezze hardware come queste. Un approccio strutturato, dinamico e modulare al Soc consente di adattarsi rapidamente alle minacce emergenti, integrando strumenti di analisi automatizzata, aggiornamenti regolari del firmware e simulazioni di attacchi per testare la resilienza dei sistemi”, continua Paglia: “Investire in pratiche di cyber security robuste non solo riduce i rischi, ma rafforza la fiducia e la continuità del business”.

Threat Intelligence

Questo attacco ricorda “l’importanza cruciale della Threat Intelligence nel contesto delle nuove vulnerabilità scoperte nei processori Amd. La Threat Intelligence è infatti essenziale per identificare, analizzare e mitigare tempestivamente le minacce informatiche emergenti. Attraverso un efficace sistema di raccolta e analisi delle informazioni sulle minacce, le organizzazioni possono rimanere aggiornate sulle vulnerabilità più recenti e sulle tecniche d’attacco utilizzate dai cyber criminali, adottando così misure di sicurezza proattive in grado di ridurre significativamente il rischio”, secondo Angelo Gazineo.

Focus sugli attacchi side-channel

Guardando oltre l’urgenza, “il caso TSA conferma la necessità di innalzare il livello di attenzione verso attacchi side-channel sempre più frequenti. Conviene rivedere i criteri di consolidamento dei workload e, dove i requisiti lo consentano, limitare o disabilitare l’SMT nei nodi che gestiscono dati altamente sensibili”, avverte Michetti.

Un approccio zero trust

“La scarsa complessità richiesta ad attaccanti già presenti su un host e la capacità di violare confini logici rendono queste vulnerabilità più insidiose di quanto la severità numerica suggerisca. La buona notizia è che l’industria ha reagito in tempi brevi; la cattiva è che le patch, da sole, non bastano. Solo un roll-out tempestivo, unito a regole di segregazione dei workload applicando un approccio ‘zero trust’, consente di ridurre concretamente la superficie di attacco”, conclude Michetti.

Il ruolo della Direttiva NIS 2

“In un contesto normativo come la Direttiva NIS 2 dell’Unione Europea, che obbliga le aziende a condurre un’analisi attenta e una valutazione dei rischi legati alle vulnerabilità, diventa essenziale adottare un approccio proattivo. NIS2 non solo richiede di identificare questi problemi, ma impone anche di intervenire tempestivamente per mitigarli e risolverli, riducendo al minimo l’impatto su operazioni critiche come quelle nei settori energia, trasporti o sanità. Ignorare tali vulnerabilità potrebbe esporre le organizzazioni a sanzioni, interruzioni di servizio o perdite economiche significative”, avverte Riccardo Paglia.