Meltdown/Spettro

Surma

Panoramica

Il 3 gennaio, Project Zero ha rivelato le vulnerabilità nelle CPU moderne che un processo può utilizzare per leggere (nel peggiore dei casi) la memoria arbitraria, inclusa la memoria che non appartiene a quel processo. Queste vulnerabilità sono state denominate Spectre e Meltdown. Cosa sta facendo Chrome per contribuire alla sicurezza del web e cosa dovrebbero fare gli sviluppatori web per i propri siti?

TL; DR

In qualità di utente che naviga sul web, devi assicurarti di mantenere aggiornati il tuo sistema operativo e il tuo browser. Inoltre, gli utenti di Chrome possono valutare l'attivazione dell'isolamento dei siti.

Se sei uno sviluppatore web, il team di Chrome consiglia:

• Se possibile, impedisci ai cookie di inserire la memoria del processo del renderer utilizzando gli attributi dei cookie SameSite e HTTPOnly ed evitando di leggere da document.cookie.
• Assicurati che i tipi MIME siano corretti e specifica un'intestazione X-Content-Type-Options: nosniff per tutti gli URL con contenuti sensibili o specifici per l'utente, al fine di ottenere il massimo dal blocco della lettura multiorigine per gli utenti che hanno attivato l'isolamento dei siti.
• Attiva l'isolamento dei siti e informa il team di Chrome se causa problemi al tuo sito.

Se ti stai chiedendo perché questi passaggi sono utili, continua a leggere.

Il rischio

Le spiegazioni di queste vulnerabilità sono state numerose, quindi non ne aggiungo un'altra. Se vuoi scoprire come sfruttare queste vulnerabilità, ti consiglio di dare un'occhiata al post del blog dei miei colleghi del team di Google Cloud.

Sia Meltdown che Spectre consentono a un processo di leggere la memoria che non dovrebbe essere in grado di. A volte, più documenti di siti diversi possono condividere un processo in Chrome. Questo può accadere quando una ha aperto l'altra utilizzando window.open, <a href="..." target="_blank"> o iframe. Se un sito web contiene dati specifici degli utenti, è possibile che un altro sito possa utilizzare queste nuove vulnerabilità per leggere i dati utente.

Mitigazioni

Il team tecnico di Chrome e V8 sta effettuando vari sforzi per mitigare questa minaccia.

Isolamento dei siti

L'impatto dello sfruttamento ottimale di Spectre può essere notevolmente ridotto impedendo ai dati sensibili di condividere un processo con codice controllato da utenti malintenzionati. Il team di Chrome sta lavorando a una funzionalità chiamata "Isolamento dei siti":

Nota: "i siti web in genere non possono accedere ai rispettivi dati all'interno del browser[...]. A volte, il codice contiene bug di sicurezza e siti web dannosi potrebbero tentare di aggirare queste regole per attaccare altri siti web. [...] L'isolamento dei siti offre una seconda linea di difesa per ridurre le probabilità di successo di questi attacchi. Assicura che le pagine di diversi siti web vengano sempre inserite in processi diversi, ognuno in esecuzione in una sandbox che limita le operazioni consentite dal processo."

L'isolamento dei siti non è ancora stato abilitato per impostazione predefinita poiché esistono un paio di problemi noti e il team di Chrome vorrebbe il maggior numero possibile di test sul campo. Se sei uno sviluppatore web, devi attivare l'isolamento dei siti e controllare se il tuo sito rimane funzionante. Se vuoi procedere ora, abilita chrome://flags#enable-site-per-process. Se trovi un sito che non funziona, aiutaci segnalando un bug e indicando che hai attivato l'isolamento dei siti.

Blocco dei documenti su più siti

Nota: dopo la pubblicazione di questo documento, il blocco dei documenti tra siti è stato rinominato in Blocco lettura multiorigine. Questi due termini fanno riferimento allo stesso concetto.

Anche quando tutte le pagine tra siti vengono inserite in processi separati, le pagine possono comunque richiedere legalmente alcune sottorisorse tra siti, come immagini e JavaScript. Per evitare la fuga di queste informazioni sensibili, l'isolamento dei siti include una funzionalità di "blocco dei documenti tra siti" che limita le risposte di rete inviate al processo del renderer.

Un sito web può richiedere due tipi di dati a un server: "documenti" e "risorse". Qui i documenti sono in formato HTML, XML, JSON e file di testo. Un sito web è in grado di ricevere documenti dal proprio dominio o da altri domini con intestazioni CORS permissive. Le risorse includono elementi come immagini, JavaScript, CSS e caratteri. Le risorse possono essere incluse da qualsiasi sito.

Il criterio di blocco dei documenti tra siti impedisce a un processo di ricevere "documenti" da altre origini se:

1. Hanno un tipo HTML, XML, JSON o MIME testo/normale e
2. Hanno un'intestazione della risposta HTTP X-Content-Type-Options: nosniff o una rapida analisi dei contenuti ("sniffing") conferma che il tipo è corretto
3. CORS non consente esplicitamente l'accesso al documento

I documenti bloccati da questo criterio vengono presentati al processo come vuoti, sebbene la richiesta venga comunque eseguita in background.

Ad esempio, supponiamo che un utente malintenzionato crei un tag <img> che include un file JSON con dati sensibili, come <img src="https://yourbank.com/balance.json">. Senza l'isolamento dei siti, i contenuti del file JSON tornerebbero alla memoria del processo di rendering, dopodiché il renderer nota che non si tratta di un formato di immagine valido e non esegue il rendering di un'immagine. Con Spectre, tuttavia, ora è possibile leggere un blocco di memoria. Il blocco dei documenti tra siti impedisce ai contenuti di questo file di entrare nella memoria del processo in cui è in esecuzione il renderer, perché il tipo MIME è bloccato dal blocco dei documenti tra siti.

Secondo le metriche utente, esistono molti file JavaScript e CSS pubblicati con tipi MIME text/html o text/plain. Per evitare di bloccare le risorse contrassegnate per errore come documenti, Chrome tenta di annusare la risposta per garantire che il tipo MIME sia corretto. Questo sniffing è imperfetto, quindi se hai la certezza di aver impostato le intestazioni Content-Type corrette sul tuo sito web, il team di Chrome consiglia di aggiungere l'intestazione X-Content-Type-Options: nosniff a tutte le risposte.

Se vuoi provare il blocco dei documenti tra siti, attiva l'isolamento dei siti come descritto sopra.

SameSite cookie

Torniamo all'esempio precedente: <img src="https://yourbank.com/balance.json">. Questo funziona solo se yourbank.com ha memorizzato un cookie che fa accedere automaticamente l'utente. In genere i cookie vengono inviati per tutte le richieste al sito web che li imposta, anche se la richiesta viene effettuata da una terza parte utilizzando un tag <img>. I cookie SameSite sono un nuovo attributo che specifica che un cookie deve essere associato solo a una richiesta che ha origine dallo stesso sito, da cui il nome. Purtroppo, al momento della stesura di questo documento, solo Chrome e Firefox 58 e versioni successive supportano questo attributo.

HTTPOnly e document.cookie

Se i cookie del sito vengono utilizzati soltanto sul lato server, non tramite JavaScript del client, esistono dei modi per impedire ai dati dei cookie di entrare nel processo del renderer. Puoi impostare l'attributo del cookie HTTPOnly, che impedisce esplicitamente l'accesso al cookie tramite lo script lato client sui browser supportati, come Chrome. Se l'impostazione di HTTPOnly non è possibile, puoi limitare l'esposizione del caricamento dei dati dei cookie al processo visualizzato non leggendo document.cookie, a meno che non sia assolutamente necessario.

Apri link esterni utilizzando rel="noopener"

Quando crei un link a un'altra pagina utilizzando target="_blank", la pagina aperta ha accesso all'oggetto window, può passare dalla pagina a un URL diverso e, senza l'isolamento dei siti, seguirà la stessa procedura della pagina. Per proteggere meglio la tua pagina, i link a pagine esterne che si aprono in una nuova finestra devono sempre specificare rel="noopener".

Timer ad alta risoluzione

Per sfruttare Meltdown o Spectre, un utente malintenzionato deve misurare quanto tempo occorre per leggere un determinato valore dalla memoria. A tal fine, è necessario un timer affidabile e preciso.

Un'API offerta dalla piattaforma web è performance.now(), con una precisione massima di 5 microsecondi. Per ridurre, in tutti i principali browser, la risoluzione di performance.now() è stata ridotta per rendere più difficile montare gli attacchi.

Un altro modo per ottenere un timer ad alta risoluzione è utilizzare un SharedArrayBuffer. Il buffer viene utilizzato da un worker dedicato per incrementare un contatore. Il thread principale legge questo contatore e lo usa come timer. Per il momento i browser hanno deciso di disabilitare SharedArraybu finché non saranno in atto altre mitigazioni.

V8

Per sfruttare Spectre, è necessaria una sequenza appositamente creata di istruzioni della CPU. Il team V8 ha implementato mitigazioni per le proof of concept note di un attacco e sta lavorando a modifiche in TurboFan, il suo compilatore ottimizzatore, che rendono sicuro il codice generato anche quando vengono attivati questi attacchi. Tuttavia, queste modifiche alla generazione del codice possono comportare penalità in termini di prestazioni.

Garantire la sicurezza del web

C'è stata molta incertezza sulla scoperta di Spectre e Meltdown e delle loro implicazioni. Mi auguro che questo articolo abbia chiarito cosa stanno facendo i team di Chrome e V8 per mantenere sicura la piattaforma web e come gli sviluppatori web possono contribuire utilizzando le funzionalità di sicurezza esistenti. In caso di domande, non esitare a contattarmi su Twitter.