Tom's Hardware Italia Tom's Hardware
CPU

La verità di CTS-Labs sulle vulnerabilità dei processori AMD

Ieri sera vi abbiamo riportato delle presunte falle di sicurezza delle più recenti CPU AMD basate su architettura Zen. AMD sta indagando e al momento in cui scriviamo non ha ancora rilasciato informazioni dettagliate, quindi novità su quel fronte – il più importante a questo punto – non ce ne sono.

Stamane abbiamo pubblicato un lungo articolo in cui abbiamo trattato i "lati oscuri" della vicenda, che non avevamo discusso in prima battuta e su cui c'era stato "caldeggiato" un approfondimento dai lettori.

Questa sera però c'è un nuovo fatto. È tornata a parlare CTS-Labs, con una lettera del suo CTO, Ilia Luk-Zilberman. La trovate a questo indirizzo. Intitolata "Response to the amdflaws publication", spiega – dal punto di vista dell'azienda di ricerca israeliana – i motivi di uno dei tanti lati oscuri attorno a questa divulgazione delle presunte falle delle CPU AMD.

Di cosa stiamo parlando? Della decisione di parlarne pubblicamente il giorno dopo aver comunicato ad AMD l'esistenza delle presunte vulnerabilità.

Zilberman (accorciamo il cognome per amor di brevità), afferma che il tutto è iniziato un anno fa, con le prime indagini sui chipset di ASMedia. "Abbiamo trovato backdoor del produttore all'interno dei chip che vi danno il controllo sugli stessi – ASM1042, ASM1142 e ASM1143. Volevamo divulgare pubblicamente le nostre scoperte, ma poi abbiamo visto che AMD ha dato in outsourcing i propri chipset ad ASMedia".

Così il focus di CTS-Labs si è spostato su AMD. "Abbiamo comprato un computer Ryzen e fatto girare il nostro proof of concept, e ha funzionato subito, senza modifiche. Piena capacità di lettura, scrittura ed esecuzione sul chipset AMD, così com'era, senza modifiche".

ryzen

Zilberman si è detto scioccato di come AMD non avesse rimosso le backdoor di ASMedia dai propri chipset e così, "ci siamo detti, ok, cosa sta succedendo in AMD? Per questo abbiamo iniziato a indagare su AMD". Dopo un po' di tempo per configurare l'ambiente per "avviare la comunicazione con il Secure Processor", Zilberman spiega che CTS-Labs "ha iniziato a trovare vulnerabilità".

Nella lettera si parla di errori basilari. A quel punto gli errori sono iniziati a saltare fuori in differenti sezioni e regioni dei chip. "È così pieno di vulnerabilità che basta concentrarsi, fare ricerche e troverete qualcosa – ovviamente è un'opinione personale", aggiunge il CTO.

"Dopodiché abbiamo deciso di divulgare pubblicamente il tutto. In onestà penso che sia difficile credere che siamo l'unico gruppo al mondo ad aver riscontrato queste vulnerabilità, considerando chi sono gli attori nel mondo attuale e che noi siamo un piccolo gruppo di sei ricercatori".

A questo punto la lettera giunge al nodo cruciale: perché i ricercatori hanno pubblicato le loro – presunte in attesa di conferme da AMD – scoperte senza attendere 90 giorni?

Il CTO ritiene che l'attuale struttura della "Responsible Disclosure" abbia problemi molto seri. "Quello principale secondo me con questo modello è che durante questi 90 giorni, sta al produttore decidere se allertare i clienti sul fatto che c'è un problema. E per quanto ho visto, è estremamente raro che il produttore notifichi anzitempo i problemi ai propri clienti".

"Il secondo problema è che qualora il produttore non risolvesse il problema in tempo, cosa succederebbe? I ricercatori potrebbero divulgare il tutto al pubblico? Con dettagli tecnici ed exploit? Mettendo a rischio i consumatori? Il come abbiamo accettato questo modus operandi è qualcosa che va oltre la mia comprensione, ovvero il fatto che i ricercatori comunichino queste vulnerabilità alla scadenza del periodo perché il produttore non ha risposto. Perché dovremmo far pagare i clienti per la mancanza di azioni da parte del produttore? Certo, lo capisco – questo è il modello attuale e tutti seguono l'esempio, ma penso che possiamo fare meglio".

Il meglio che intende Zilberman è il seguente. "Penso che un modo migliore sarebbe quello di informare il pubblico il giorno 0 che ci sono vulnerabilità e qual è il loro impatto. In modo da informare il pubblico e il produttore allo stesso tempo. E non rivelare i dettagli tecnici a meno che il problema non sia già stato risolto. In modo da mettere la piena pressione pubblica sul produttore fin dall'inizio, ma non mettere mai a rischio i clienti".

"Questo modello ha un enorme problema; come convincere il pubblico che stai dicendo la verità senza i dettagli tecnici? Abbiamo pagato il prezzo dell'incredulità nelle ultime 24 ore. La soluzione che abbiamo trovato è una convalida di terze parti, come quella che abbiamo fatto con Dan Guido di Trail of Bits. A ben guardare, avremmo dovuto farlo con 5 aziende di terze parti per dipanare ogni dubbio. È una lezione per la prossima volta".