La scelta di misure di sicurezza per la protezione del sistema operativo non passa soltanto attraverso l’utilizzo di specifici software quali, ad esempio, antivirus e firewall, ma anche indirettamente tramite la scelta del browser con il quale poter navigare.

Dando uno sguardo ai dati relativi alla diffusione negli ultimi due anni dei cinque principali browser si evince chiaramente il successo che Google Chrome ha ottenuto dal 2008, anno del suo rilascio, ad oggi e che lo porta ad essere attualmente il browser maggiormente utilizzato.

Browser share

Negli ultimi anni i browser si sono trasformati sempre più da semplici parser HTML ad applicativi multifunzione sempre più complessi, costretti ad interagire con svariate tecnologie di terze parti, plugin vari necessari per poter riprodurre i diversi formati presenti ad oggi nel web – Adobe Flash, Microsoft Silverlight, Oracle Java sono solo alcuni esempi.

La sicurezza di un browser non è quindi data soltanto dalla stabilità del proprio codice – sebbene questa ricopra un ruolo di primaria importanza – ma anche da quella dei plugin installati. Una falla nel plugin di Abode Flash, ad esempio, potrebbe compromettere la sicurezza dell’intero sistema, a meno che il browser non sia pronto a gestire tale eventualità. Eventualità, questa, tutt’altro che remota ma che è, anzi, predominante negli attacchi da remoto che ogni giorno vengono scoperti online.

Nel corso degli anni sono state applicate dagli sviluppatori dei maggiori browser differenti tecnologie di sicurezza atte a rendere il lavoro dei pirati informatici sempre più arduo. Ad oggi, una delle tecnologie più utilizzate all’interno della maggior parte dei browser è la sandbox.

Come però i maggiori browser implementino tale tecnologia sarà oggetto di analisi nel corso dell’articolo. Sebbene questo fattore non possa essere utilizzato come unica discriminante nella valutazione di un browser, esso rappresenta sicuramente una caratteristica di cui dover tenere conto.

Al fine di poter confrontare i diversi browser nelle rispettive implementazioni, è utile capire a grandi linee quali sono gli elementi che permettono la realizzazione di una sandbox.

L’obiettivo di una sandbox è quello di isolare dal punto di vista comportamentale e logico una porzione di codice.

L’esecuzione di ogni tab del browser sotto forma di singolo processo è un buon punto di partenza e presenta due vantaggi fondamentali: il primo è dato da una gestione locale delle caratteristiche di sicurezza (magari assegnando limitazioni più o meno restrittive a differenti tab), il secondo è dato dall’evitare che un crash avvenuto all’interno di una tab possa portare alla chiusura dell’intero browser. Chiaramente per poter implementare tale tecnologia è necessario dover cambiare completamente l’architettura del browser, rendendola quindi estremamente modulare.

Limitazioni vere e proprie possono essere gestite tramite altri meccanismi messi a disposizione dal sistema operativo (nello specifico Windows), tra i quali:

Access Token
Il token associato ad un processo contiene, tra le varie informazioni, i privilegi associati al processo e il suo livello di integrità.

Livelli di integrità
Implementati a partire da Windows Vista, i livelli di integrità permettono di assegnare diritti diversi a processi appartenenti allo stresso user account. A differenza di Windows XP in cui i diritti di accesso a una risorsa erano di default uguali per ogni processo creato dallo stesso utente ed erano stabiliti soltanto dalle ACL (Access List), da Windows Vista in poi grazie all’introduzione dei livelli di integrità è stato possibile effettuare una suddivisione più raffinata. In ordine crescente di limitazioni, abbiamo livello integrità Sistema, Alto, Medio, Basso e Non attendibile. Se non diversamente specificato le applicazione utente del sistema sono create con livello Medio. Vale la regola generale secondo la quale un oggetto con un dato livello di integrità non può mai accedere ad un oggetto con un livello di integrità superiore. Si noti che i livelli di integrità non vengono utilizzati solo a livello di processi ma anche a livello di scambio di messaggi tra elementi grafici (UIPI).

Job object
Un job è un oggetto che in ambiente Windows permette di trattare un insieme di processi come un’unica entità. Impostando le caratteristiche del job si può agire indirettamente sulle regole comportamentali dei processi ad esso associati, permettendo di aggiungere ulteriori limitazioni rispetto a quelle già presenti nell’access token del processo.

Gli elementi sopra elencati rappresentano soltanto alcuni degli strumenti sfruttati dai browser per implementare tecniche di sandboxing e che nello specifico fanno riferimento a funzionalità e oggetti messi a disposizione direttamente dal sistema operativo. Tuttavia è possibile, come nel caso di Chrome, ricorrere a tecniche più avanzate (come l’hooking della API di sistema) per tenere sotto controllo il comportamento di ogni singolo processo.

Analizzata a grandi linee come una sandbox è realizzata, è utile comprendere il perché questa sia così importante e soprattutto da cosa ci protegge. Sarà utile dunque porsi nell’ottica di un attaccante e cercare di capire perché è fondamentale far sì che un processo non possa eseguire, o possa farlo con dei limiti, determinate operazioni.

Nel caso specifico di un browser, il primo passo effettuato da un attaccante è quello di sfruttare un bug presente nel codice del software di navigazione tramite un exploit. Questo potrebbe occorrere anche visitando semplicemente una pagina web creata ad hoc che sfrutti un bug del motore di rendering HTML del browser o di uno dei vari plugin installati, presenti solitamente sottoforma di libreria DLL caricata nello spazio di indirizzamento del processo del browser stesso.

Anche utilizzando le tecniche di sicurezza introdotte in Windows Vista e 7 precedentemente descritte, sono comunque presenti scenari di attacco di cui i browser dovrebbero tenere conto.

Immaginiamo che l’avversario abbia ottenuto il controllo del flusso di esecuzione di un processo con privilegi limitati. A questo punto potrebbe tentare di elevarli (attacco privilege escalation) avviando un nuovo processo familiare all’utente, come il blocco note (notepad.exe), e iniettando al suo interno il codice nocivo. In questo modo è molto più probabile che l’utente, fìdandosi del processo, approvi eventuali richieste di azioni sospette (social engineering).

L’attaccante avrebbe avuto vita più facile qualora il processo del browser fosse stato avviato con livelli di integrità di default (medio)i. Per questo motivo una buona regola sarebbe quella di far eseguire, nei limiti del possibile, il processo del browser con un basso livello di integrità. Come vedremo in seguito non tutti i browser adottano questa misura di sicurezza.

Supponiamo ora che l’utente abbia acconsentito al processo notepad.exe di effettuare liberamente le operazioni richieste. A questo punto il codice malevolo potrebbe tentare di leggere informazioni confidenziali sul disco o di scrivere un nuovo eseguibile per poterlo avviare al successivo riavvio del sistema inserendo un’opportuna chiave nel registro di sistema, mantenendo quindi il controllo della macchina infetta.

Un modo alternativo che hanno a disposizione i processi per comunicare è quello dello scambio di messaggi IPC, utilizzati anche per la comunicazione fra gli elementi dell’interfaccia grafica (window). Altri tipi di attacco possono sfruttare questo scambio di informazioni per aggirare i controlli precedentemente descritti (un esempio di abuso di tale tecnologia è lo shatter attack). E’ buona regola quindi isolare i processi il più possible anche da questo punto di vista tramite l’utilizzo di desktop alternativi a quello principale e limitando i privilegi di acesso alle sole finestre che riguardano l’applicazione.

Altre informazioni confidenziali possono essere ricavate dalla lettura della clipboard, una particolare area di memoria condivisa fra i processi – che spesso viene sottovalutata – in cui vengono salvate le informazioni del classico meccanismo di copia-incolla.

La seguente tabella riporta come i tre browser maggiormente diffusi gestiscono gli aspetti critici precedentemente descritti.

Browser security features

Uno degli aspetti che più saltano all’occhio è la totale assenza di una qualsiasi misura di sandboxing da parte di Firefox. Dietro questa mancanza di interesse da parte del team di Mozilla, culminata con l’abbandono (?) del progetto Electrolysis, si nasconde forse una scelta progettuale ben precisa, basata sulla (eccessiva?) fiducia del proprio codice e dei gestori di plugin di terze parti.

È il caso di Flash e Silverlight, che come possiamo vedere vengono gestiti da un processo totalmente separato e indipendente dal processo Firefox:

Flash plugin in Firefox

Non è un caso che gli utenti Firefox ricorrano spesso all’uso di add-on quali NoScript. C’è da chiedersi però fino a che punto questa possa essere ritenuta una scelta ottimale in termini di sicurezza e non una forzatura per sopperire alla mancanza di tutela da parte degli sviluppatori.

Un altro aspetto non di poco conto è con quale livello di integrità i processi del browser vengono eseguiti:

Integrity levels

Come detto in precedenza, almeno dal punto di vista della sicurezza, è sempre preferibile eseguire processi potenzialmente vulnerabili ad un livello di integrità il più basso possibile per limitarli nel caso di un’eventuale infezione.

Nel caso specifico, Firefox viene sempre eseguito con livello di integrità medio e può quindi avere accesso ad ogni altra applicazione utente.

A differenza del browser di Mozilla, Internet Explorer implementa una propria sandbox utilizzando esclusivamente le funzionalità messe a disposizione dal sistema operativo stesso.

Le varie tab aperte dall’utente sono gestite come processi indipendenti incapsulati all’interno di job object con livello di integrità basso. Questa soluzione non permette ai processi del browser di accedere in scrittura alla maggior parte delle risorse di sistema: gli accessi in scrittura sul registro sono limitati alla chiave

HKEY_CURRENT_USERSoftwareAppDataLow

mentre sul disco si può scrivere esclusivamente nella directory

%USER PROFILE%AppDataLocalLow

ne permette comunque l’accesso completo in lettura.

Un attaccante che, potenzialmente, prende possesso del processo associato alla pagina web ha inoltre la possibilità di scrittura su tutti i processi, file su disco o di inviare messaggi IPC che condividono il livello di integrità basso, possiblità che potrebbe risultare rischiosa (ricordiamo la privilege escalation tramite social engineering) ma che in generale non comporta scenari di immediato pericolo.

Oltre a questa limitazione di sicurezza Internet Explorer non aggiunge al job restrizioni che riguardino clipboard e la creazione di processi, lasciando quindi la possibilità di accesso completo a questa zona di memoria condivisa e di generazione di nuovi processi figlio (che comunque erediteranno il livello di integrità basso).

Il principale difetto che si può facilmente notare nella sandbox di Internet Explorer è il fatto che è completamente inutilizzabile in Windows XP: dato che questo sistema operativo non prevede la suddivisione in livelli di integrità i processi del browser rimangono totalmente esposti agli attacchi.

A differenza dei suoi due maggiori concorrenti, Google Chrome pone molta più attenzione all’aspetto della sicurezza imponendo notevoli restrizioni tramite il job assegnato ad ogni processo tab creato.

Job security restrictions

La limitazione nella scrittura della clipboard (precedentemente avevamo accennato al problema nella lettura) è molto importante in quanto permette di evitare a un processo infetto di usare questo “ponte di comunicazione” per passare ad esempio dei comandi ad altri processi.

La comunicazione tra processi è tenuta ancora più sotto controllo limitando lo scambio di messaggi tra gli elementi dell’interfaccia grafica del browser. Questo è possibile grazie alla creazione da parte di Chrome di un oggetto desktop dedicato ai singoli elementi del browser.

Ogni tab viene inoltre eseguita come un processo separato al quale viene associato il livello di integrità “Non attendibile”. Così facendo i processi non hanno accesso né in lettura né in scrittura alle informazioni provenienti da qualsiasi risorsa (registoro di sistema, processi, disco, …) di livelli di integrità superiore. Così facendo si limita l’infezione ai processi aventi lo stesso livello di integrità.

ACL differences

Ulteriori limitazioni sono state introdotte da Chrome grazie alla notevole riduzione dei diritti associati all’access token. In questo modo il browser può realizzare almeno in parte la sua sandbox anche in sistemi operativi in cui non sono previsti livelli di integrità.

A differenza di Firefox e Internet Explorer, Chrome sfrutta anche la tecnica dell’hooking per controllare quale API di sistema vengono invocate dal browser, bloccando tentativi di accesso
alla memoria di altri processi esterni e l’esecuzione di funzioni potenzialmente pericolose se usate impropriamente tra le quali: NtCreateFile, NtOpenFile, NtOpneProcess, NtOpenThread.

Vale la pena sottolineare come le funzionalità della sandbox di Chrome non si basino soltanto sull’uso dei livelli di integrità, che anzi possono essere considerati come un elemento aggiuntivo a quella che abbiamo visto essere un’architettura solida e in grado di sfruttare diverse tecniche di sandboxing.

Questo rappresenta sicuramente un grosso punto a favore di Chrome, che allo stato attuale delle cose resta di fatto uno dei pochi browser in grado di mantenere un buon livello di sicurezza anche se eseguito su sistemi operativi più datati come Windows XP.

A maggior ragione se si pensa alla recentissima collaborazione tra Google e Adobe che ha portato all’integrazione del Flash Player all’interno della sandbox nativa di Chrome, che ad oggi rimane l’unico browser in grado di garantire una versione sotto sandbox del plugin su Windows XP.

Benedetto Voltattorni
Marco Bizzarri