Meltdown/Spettro

Surma

Panoramica

Il 3 gennaio Project Zero ha rivelato vulnerabilità nelle CPU moderne che un processo può utilizzare per leggere (nel peggiore dei casi) memoria arbitraria, inclusa la memoria che non appartiene a quel processo. Queste vulnerabilità sono state chiamate Spectre e Meltdown. Che cosa fa Chrome per contribuire a mantenere il web sicuro e cosa devono fare gli sviluppatori web per i propri siti?

TL; DR

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

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

• Se possibile, impedisci ai cookie di entrare nella 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, per ottenere il massimo dal blocco della lettura tra origini per gli utenti che hanno attivato l'isolamento del sito.
• Attiva l'isolamento dei siti e comunica al team di Chrome se causa problemi per il tuo sito.

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

Il rischio

Esistono diverse spiegazioni di queste vulnerabilità, quindi non ne aggiungerò un'altra. Se ti interessa sapere come possono essere sfruttate queste vulnerabilità, ti consiglio di dare un'occhiata al post del blog scritto dai miei colleghi del team di Google Cloud.

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

Mitigazioni

Il team di ingegneri di Chrome e V8 sta adottando diversi accorgimenti per mitigare questa minaccia.

Isolamento dei siti

L'impatto dell'utilizzo di Spectre può essere notevolmente ridotto impedendo ai dati sensibili di condividere un processo con il codice controllato dall'attaccante. Il team di Chrome sta lavorando a una funzionalità per raggiungere questo obiettivo chiamata "Isolamento dei siti":

Nota: in genere i siti web non possono accedere ai dati l'uno dell'altro all'interno del browser[...]. A volte in questo codice vengono rilevati bug di sicurezza e i 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. Garantisce che le pagine di siti web diversi vengano sempre inserite in processi diversi, ognuno in esecuzione in una sandbox che limita le attività consentite al processo."

L'isolamento dei siti non è ancora stato attivato per impostazione predefinita perché esistono alcuni problemi noti e il team di Chrome vorrebbe eseguire il maggior numero possibile di test sul campo. Se sei un sviluppatore web, devi attivare l'isolamento dei siti e verificare se il tuo sito rimane funzionale. Se vuoi attivarla 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 cross-site

Nota: dopo la pubblicazione di questo documento, il blocco dei documenti cross-site è stato rinominato blocco della lettura cross-origin. Questi due termini fanno riferimento allo stesso concetto.

Anche quando tutte le pagine cross-site vengono inserite in processi separati, le pagine possono comunque richiedere legittimamente alcune risorse secondarie cross-site, come immagini e JavaScript. Per contribuire a impedire la fuga di informazioni sensibili, l'isolamento dei siti include la funzionalità di "blocco dei documenti cross-site" che limita le risposte di rete inviate al processo di rendering.

Un sito web può richiedere due tipi di dati da un server: "documenti" e "risorse". In questo caso, i documenti sono file HTML, XML, JSON e 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 quali immagini, JavaScript, CSS e caratteri. Le risorse possono essere incluse da qualsiasi sito.

Il criterio di blocco dei documenti cross-site impedisce a un processo di ricevere "documenti" da altre origini se:

1. Hanno un tipo MIME HTML, XML, JSON o testo/plain e
2. Hanno un'intestazione di risposta HTTP X-Content-Type-Options: nosniff o un'analisi rapida 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, anche se la richiesta viene comunque eseguita in background.

Ad esempio, immagina che un malintenzionato crei un tag <img> che includa un file JSON con dati sensibili, come <img src="https://yourbank.com/balance.json">. Senza l'isolamento dei siti, i contenuti del file JSON arriverebbero nella memoria del processo del visualizzatore, che a quel punto nota che non si tratta di un formato immagine valido e non la esegue. Con Spectre, tuttavia, ora c'è un modo per leggere potenzialmente quel blocco di memoria. Il blocco dei documenti cross-site impedirebbe ai contenuti di questo file di entrare nella memoria del processo in cui viene eseguito il rendering perché il tipo MIME è bloccato dal blocco dei documenti cross-site.

In base alle metriche utente, sono presenti molti file JavaScript e CSS che vengono caricati con tipi MIME text/html o text/plain. Per evitare di bloccare le risorse contrassegnate per errore come documenti, Chrome tenta di analizzare la risposta per assicurarsi che il tipo MIME sia corretto. Questo sniffing è imperfetto, quindi se hai la certezza di impostare gli 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 riportato sopra: <img src="https://yourbank.com/balance.json">. Questo funziona solo se la tua banca ha memorizzato un cookie che consente all'utente di accedere automaticamente. I cookie vengono in genere inviati per tutte le richieste al sito web che li imposta, anche se la richiesta viene effettuata da una terza parte che utilizza un tag <img>. I cookie SameSite sono un nuovo attributo che specifica che un cookie deve essere associato solo a una richiesta proveniente dello stesso sito, da cui il nome. Purtroppo, al momento della stesura di questo articolo, solo Chrome e Firefox 58 e versioni successive supportano questo attributo.

HTTPOnly e document.cookie

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

Aprire i link esterni utilizzando rel="noopener"

Quando esegui il collegamento a un'altra pagina utilizzando target="_blank", la pagina aperta ha accesso al tuo oggetto window, può indirizzare la tua pagina a un URL diverso e, senza l'isolamento del sito, sarà nella stessa procedura della tua pagina. Per proteggere meglio la tua pagina, i link alle pagine esterne che si aprono in una nuova finestra devono sempre specificare rel="noopener".

Timer ad alta risoluzione

Per sfruttare Meltdown o Spectre, un malintenzionato deve misurare il tempo necessario per leggere un determinato valore dalla memoria. Per questo, è necessario un timer affidabile e preciso.

Una delle API offerte dalla piattaforma web è performance.now() che ha una precisione di 5 microsecondi. Come misura di mitigazione, tutti i principali browser hanno ridotto la risoluzione di performance.now() per rendere più difficili 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 utilizza come timer. Per il momento i browser hanno scelto di disattivare SharedArrayBuffer finché non verranno implementate altre misure di mitigazione.

V8

Per sfruttare Spectre, è necessaria una sequenza di istruzioni della CPU appositamente creata. Il team di V8 ha implementato delle mitigazioni per le prove di concetto di attacchi note e sta lavorando a modifiche in TurboFan, il suo compilatore ottimizzatore, che rendono il codice generato sicuro anche quando vengono attivati questi attacchi. Tuttavia, queste modifiche alla generazione di codice potrebbero comportare una penalizzazione del rendimento.

Mantenere il web al sicuro

La scoperta di Spectre e Meltdown e le relative implicazioni hanno generato molta incertezza. Spero che questo articolo abbia fatto luce su cosa stanno facendo i team di Chrome e V8 per mantenere la piattaforma web al sicuro e su come gli sviluppatori web possono contribuire utilizzando le funzionalità di sicurezza esistenti. Per qualsiasi domanda, non esitare a contattarmi su Twitter.