Come abbiamo visto in un precedente post, è da diverso tempo che sulle “prime pagine” di siti e giornali non si parla di Spectre e Meltdown, le pericolose vulnerabilità dei processori svelate a gennaio 2018 dal portale The Register. Gli stessi vendor (Intel in primis ma anche AMD) sembrano aver “dimenticato” il problema relegando alle future generazioni di CPU il compito di andare oltre le ventennali falle architetturali dei x86 e ad alcuni aggiornamenti software (microcode updates) il ruolo di mitigarne l’efficacia.
Il più recente studio pubblicato dai ricercatori di sicurezza Google conferma l’impraticabilità delle “strategie microcode” già a partire dal titolo, “Spectre is here to stay. An analysis of side-channels and speculative execution”; sfogliando la ventina di pagina di cui si compone si trovano considerazioni come la seguente:
[Spectre (Variant 4)] è in grado di sconfiggere qualsiasi soluzione alla quale abbiamo pensato. Abbiamo valutato soluzioni molteplici per la variante 4 ma la minaccia si è rivelata molto più pervasiva e pericolosa di quanto ci aspettassimo. […] [Crediamo che] la variante 4 non possa essere efficacemente mitigata via software, [non per scarsità di personale ma per] l’assenza di opzioni architetturali, in quanto ragionare sulla variante 4 comporta l’assunzione fuorviante che [nel processo di speculazione della CPU le scritture in memoria siano completamente invisibili alle successive operazioni di lettura].
E’ il caso di ricordare che la variante 4 era stata scoperta lo scorso maggio 2018 dal Google Project Zero, che l’aveva descritta come un bug in grado di forzare i processori a rivelare i dati presenti in memoria, consentendo ai malintenzionati di accedere alle informazioni gestite dalle applicazioni. La variante 4 è nello specifico relegata a tutti gli scenari in cui del codice fornito da un malintenzionato sia recepito nel medesimo address space del codice fornito dall’utente, come avviene nei browser:
[una pagina web il cui codice JavaScript malevolo sia in esecuzione nel thread di un browser può potenzialmente [sconfinare] nel codice JavaScript in esecuzione presso [il thread di un’altra pagina, rubandone i dati segreti].
Riprogettare l’hardware ma non solo
Se a prima vista il pericolo sembra quindi delimitato ai soli browser, ad uno sguardo più attento può potenzialmente estendersi a qualsiasi software in grado di interpretare del “codice esterno”. Il paper va considerato non come un semplice esercizio accademico ma come un avvertimento ai vendor:
Inseguendo l’apparentemente prioritario [traguardo delle prestazioni] i sistemi informatici sono divenuti massicciamente complessi. Abbiamo avuto uno straordinario successo nel renderli più veloci e potenti, ma anche più complessi, [avvalendoci di molteplici metodi d’astrazione]. [Questi ultimi] ci hanno permesso di avere più fiducia nei nostri design attraverso ragionamenti e verifiche, separando l’hardware dal software ed introducendo limiti di sicurezza. Ma abbiamo nuovamente visto che [i nostri modelli d’astrazione non sono infallibili e che nell’hardware in cui non avremmo dovuto guardare sono presenti delle vulnerabilità negli stessi chip che abbiamo impiegato in tutto il mondo].
I nostri modelli, i nostri modelli mentali, sono sbagliati; senza saperlo abbiamo barattato la sicurezza con prestazioni e complessità. Ed ora è ironicamente doloroso [constatare che difendersi con le mitigazioni via software], buona parte delle quali sappiamo essere incomplete, [richiede ancora più complessità]. […] Spectre è probabilmente [un nome che calza a pennello] poiché sembra destinato a perseguitarci a lungo.
Per contrastare le falle è necessaria un’accurata ed approfondita revisione dell’hardware e del suo design, orientamento che non sembra esser stato però recepito dall’industria – si pensi alle dichiarazioni di Intel circa la gestione della variante 1 di Spectre via software update.
Fonti: 1, 2 (documento originale).
