Da ieri sera si sta alimentando sempre di più la notizia dei 13 Bug trovati da CTS-Labs, dai nomi d’impatto, che si presume colpiscano i processori AMD della famiglia ZEN, quindi Ryzen, Ryzen Pro, Epyc e Ryzen Mobile.
Piccolo sunto delle vulnerabilità: i bug, secondo CTS-Labs, azienda israeliana nata nel 2017 e pressochè sconosciuta, si suddividono in 4 gruppi che a loro volta comprendono varie varianti, RyzenFall (notevole l’immagine della Torre di Pisa…), MasterKey (se fossi in Cooler Master chiederei i diritti sul nome :D), Fallout (evviva la fantasia) e Chimera. Per spiegare meglio chi colpisce cosa, prendiamo l’immagine direttamente dal sito amdflaws.com (si, sembra una trollata):
Ora, i dettagli tecnici di come sfruttare le vulnerabilità non sono stati resi noti da parte di CTS-Labs, ma alcuni altri esperti di sicurezza informatica, vicini a CTS-Labs, dichiarano che le vulnerabilità sono reali, anche se parliamo di vulnerabilità di tipo Second Stage, ovvero non sfruttabili se la macchina non è in parte già compromessa con la possibilità di scalare i privilegi. Non è chiaro se e come possano essere sfruttati per attacchi remoti, per ora si presume che sia necessario l’accesso fisico alla macchina, ma per farla breve questi bug permetterebbero l’installazione/esecuzione di codice arbitrario o l’accesso ad aree di memoria protette sfruttando la vulnerabilità del Secure Processor, in caso di RyzenFall Fallout e Masterkey, oppure sfrutterebbero una “backdoor” (un’accusa mica da niente…) nei chipset Promontory, prodotti da ASMedia per conto di AMD, con la possibilità di attaccare qualsiasi periferica collegata ad esso. Il report completo di CTS-Labs lo potete trovare qui, mentre la prima risposta ufficiale di AMD la potete trovare qui.
Prima di fare allarmismi da panico, come l’articolo lacunoso e approssimativo di Repubblica.it, bisogna un attimo analizzare bene i (pochi) dati messi a disposizione per capire come funzionino questi attacchi. In primis i test sono stati svolti solamente in ambiente locale e con privilegi di amministrazione, quindi come abbiamo detto sono di tipi Second Stage, inoltre per sfruttare tali vulnerabilità c’è il bisogno di reflashare il BIOS con codice malevolo introdotto e di driver firmati digitalmente.
Non vogliamo entrare nei dettagli e non vogliamo assolutamente sbilanciarci sul dire se le vulnerabilità sono vere o no, ma la vicenda ha avuto un iter decisamente fuori dagli schemi comuni e vogliamo mettere in risalto le stranezze rilevate.
Le tempistiche: CTS-Labs ha comunicato ad AMD il loro report solamente 24 ore prima di divulgarle, pratica veramente strana per questo genere di bug. Il sito amdflaws.com è stato registrato il 22 Febbraio, quindi si presuppone che CTS-Labs fosse da tempo a conoscenza del problema, ma non ha comunicato nulla ad AMD.
Gestione della divulgazione: onestamente è la prima volta che vediamo un atteggiamento del genere nel campo della sicurezza informatica, la modalità, i toni usati, i nomi altisonanti dei bug e il dominio dal nome volutamente provocatorio sembrano orientati principalmente a ledere il nome di AMD. Inoltre fa strano proprio l’utilizzo dei soli nomi dei bug senza l’utilizzo di codici CVE, metodologia standard per il tracking delle problematiche di sicurezza.
Dichiarazioni di CTS-Labs: nel whitepaper l’azienda di sicurezza informatica affronta molti punti con toni beffardi nel confronto di AMD ed alcuni passaggi, specialmente nei Legal Disclaimer, sono quasi tragicomici, ad esempio questo:
Although we have a good faith belief in our analysis and believe it to be objective and unbiased, you are advised that we may have, either directly or indirectly, an economic interest in the performance of the securities of the companies whose products are the subject of our reports.