Google rinforza site isolation per Chrome per migliorarne la protezione

La funzionalità site isolation di Chrome, che aiuta a difendersi da attacchi significativamente più potenti, è stata potenziata da Google e si appresta a sbarcare anche su Firefox ed Edge.

chrome

Google ha annunciato agli utenti di Chrome di aver potenziato una tecnologia difensiva avanzata per proteggerli dagli attacchi che sfruttano le vulnerabilità in Blink, il motore di rendering del browser. Chrome 77, lanciato a settembre a cui è seguito Chrome 78 il 22 ottobre, integra la funzionalità site isolation, che aiuta a difendersi da attacchi significativamente più potenti. Site isolation ora può gestire anche attacchi gravi in cui il processo di rendering è completamente compromesso da un bug di sicurezza, come errori di corruzione della memoria o errori logici Universal Cross-Site Scripting (UXSS).

Site isolation limita ogni processo del motore di rendering Blink ai documenti di un singolo sito web, isolando così tutto in un sito renderizzato da altri siti. L’idea di fondo è che se un sito web dannoso sfrutta una vulnerabilità, gli hacker che controllano il sito di attacco non saranno in grado di accedere a nessun dato (ad esempio informazioni aziendali estremamente preziose) al di fuori del proprio sito web criminale.

Quando Google ha implementato site isolation a metà 2018 (un anno dopo il suo debutto) in Chrome 67, lo scopo principale della tecnologia era quello di difendersi dagli attacchi in stile Spectre quando le vulnerabilità in-chip furono rilevate all’inizio dello scorso anno. Ora lo scopo principale è cambiato.

Supponiamo che un aggressore abbia scoperto e sfruttato un bug di corruzione della memoria nel motore di rendering di Chrome, Blink“, scrivono gli ingegneri di Google Alex Moshchuk e Łukasz Anforowicz. “Il bug potrebbe consentire loro di eseguire codice nativo arbitrario all’interno del processo di rendering in modalità sandbox, non più vincolato dai controlli di sicurezza in Blink. Tuttavia, Chrome conosce a quale sito è dedicato il processo di rendering e quindi può limitare cookie, password e dati del sito che l’intero processo è autorizzato a ricevere. Ciò rende molto più difficile per gli aggressori rubare dati cross-site.”

Ad esempio, quando viene attivato il site isolation del renderer, i cookie e le password sono accessibili solo tramite quei processi “bloccati” sui siti corrispondenti. C’era una vera necessità di estendere site isolation per coprire i processi di rendering di Blink. “L’esperienza passata suggerisce che bug potenzialmente sfruttabili saranno presenti nelle future versioni di Chrome”, ha riconosciuto il team di Chromium in un documento. “Sono stati rilevati 10 bug potenzialmente sfruttabili nei componenti di rendering in Chrome 69, 5 in Chrome 70, 13 in Chrome 71, 13 in Chrome 72 e 15 in Chrome 73. Questo volume di bug è stabile nonostante anni di investimenti nella formazione degli sviluppatori e in programmi di ricompensa per la scoperta di vulnerabilità. Si noti che ciò include solo i bug che ci vengono segnalati o trovati dal nostro team.”

Le funzionalità aggiuntive di site isolation apportate in Chrome 77 sono state annunciate lo scorso anno da Justin Schuh, ingegnere principale e direttore della sicurezza di Chrome, quando ha tweettato: “… sono in corso lavori per proteggervi dagli attacchi di renderer compromessi”. Allo stesso tempo Schuh scriveva che, mentre gli ingegneri stavano lavorando a site isolation per Chrome su Android, il progetto stava andando incontro a diverse difficoltà a causa di problemi di consumo di risorse. Tale consumo è stato uno dei principali compromessi per l’implementazione di site isolation, poiché l’aumento del numero di processi ha aumentato anche il consumo di memoria del browser fino al 13%.

A partire da Chrome 77 anche la versione Android di Chrome integra comunque site isolation, la cui implementazione però è diversa da quella su PC. “A differenza delle piattaforme desktop in cui isoliamo tutti i siti, Chrome su Android utilizza una forma più sottile di site isolation, proteggendo un minor numero di siti per mantenere bassi i consumi generali della RAM”, hanno scritto Moshchuk e Anforowicz.” Site isolation è attivato infatti solo per i siti di alto valore in cui gli utenti accedono con una password. “Ciò protegge i siti con dati sensibili che probabilmente più interessano agli utenti, come banche o siti di shopping, consentendo al contempo la condivisione dei processi tra siti meno critici.”

Questa forma di site isolation basata sulle password è stata attivata per il 99% dei dispositivi Android con almeno 2 GB di RAM. Maggiori informazioni su site isolation di Chrome sono consultabili in un documento che Moshchuk, insieme a due colleghi di Google, Charles Reis e Nasko Oskov, ha presentato ad agosto all’annuale evento sulla sicurezza USENIX.

Tra l’altro site isolation è stato (e sarà) adottato da altri browser come nel caso di Opera (il browser norvegese si basa infatti anch’esso su Chromium), mentre a inizio anno Mozilla ha annunciato che il proprio Project Fission avrebbe aggiunto site isolation a Firefox, senza però fornire ulteriori dettagli sulle tempistiche. Non è chiaro quale progresso abbia fatto Mozilla da allora, ma gli sviluppatori hanno ridotto la memoria richiesta da Firefox per un processo di questo tipo, un passo necessario affinché site isolation non comprometta eccessivamente le prestazioni del browser.

Anche Microsoft, che a fine 2018 ha abbracciato Chromium per il proprio browser Edge, integrerà quasi sicuramente site isolation quando porterà sul mercato la prima versione stabile di Edge “full-Chromium”. “Non esagero quando definisco site isolation il più grande progresso nella sicurezza del browser dalla creazione della sandbox”, ha tweettato Schuh il 17 ottobre. “Ha sostanzialmente cambiato il tipo di garanzie che un browser può fornire e ha imposto la base di sicurezza più solida di qualsiasi piattaforma nel mondo reale”.