Dopo essere stato trovato colpevolmente vulnerabile all’attacco Carpet Bomb che già aveva colpito Apple Safari con cui il browser di Google condivide il motore di rendering WebKit, Chrome cerca di rifarsi la faccia spiegando al mondo l’architettura con cui proteggerà gli utenti e i loro computer dalle minacce che vengono dal Web.
È stato infatti pubblicato un documento che spiega in maniera dettagliata come Chromium (ovvero l’anima open source di Chrome) utilizzi la divisione in processi intercomunicanti non solo per velocizzare l’esecuzione di ogni singola tab, ma anche per separare il motore di visualizzazione da quella che è l’interfaccia vera e propria.
I processi che si occupano di interpretare HTML, JavaScript e quant’altro componga una pagina girano all’interno di una SandBox separata dal resto del sistema. Il processo browser, che gestisce l’interfaccia, ha invece gli stessi privilegi dell’utente. Oltre a ricevere gli stimoli (pressione del pulsanti, indirizzi da visitare e così via) ha il compito di controllare ciò che viene svolto dai processi del rendering. Tutto quello che avviene nella SandBox non è protetto ed è il processo browser ad avere il compito di filtrare e discernere tra bene e malware.
In pratica la suddivisione e la divisione dei processi non viene utilizzato tanto per svolgere quelle funzioni che siamo abituati ad affidare agli strumenti anti-malware e anti-phishing già inclusi in molti browser, ma serve piuttosto ad evitare che eventuali vulnerabilità del software possano propagarsi a tutto il browser rendendolo di fatti vulnerabile, e permettendo ad esempio che siti malevoli riescano ad installare del software sul computer del visitatore.
Attualmente l’architettura utilizzata dalla SandBox è strettamente legata ad alcune funzioni di Windows e questa potrebbe essere una delle ragioni per cui Chrome non è ancora approdato su Mac e Linux. Il sistema soffre inoltre di alcune limitazioni. Ad esempio la protezione non funziona con FAT32, poiché tale filesystem non supporta la “Access Control List”.
Un processo di rendering compromesso potrebbe avere facilmente accesso a tutto il disco fisso o anche ad un eventuale drive USB utilizzato in quel momento. Inoltre se un’applicazione terza utilizza un oggetto con descrittore di sicurezza “Null”, Windows non porrà alcun limite al suo accesso e un processo di rendering compromesso potrebbe usare questa applicazione come ponte per valicare i confini della SandBox.
Limitazioni a parte, la strada della modularità è segnata e sembra promettere bene. Vedremo se gli altri browser sapranno adeguarsi o resteranno alla vecchia scuola.
