Pwnium, il secondo vincitore

Di - 4 July 2012 - in

Ormai piú di un mese fa vi parlai di Pinkie Pie, uno dei due vincitori della gara di hacking di Chrome Pwnium. Qui invece voglio presentarvi Sergey Glazunov, vincitore del premio per la sicurezza, il cui hack è forse meno d’azione rispetto all’altro, ma non è certamente meno interessante.

Prima di cominciare, però, vi introdurrò la tecnica base utilizzata da Glazunov, il Cross-Site Scripting o XSS, tecnica utilizzata largamente per minare la sicurezza dei siti internet, piuttosto che dei browser.

Molti siti web, ormai, hanno contenuti dinamici, ovvero le loro pagine cambiano a seconda delle richieste dell’utente. Su questo sito, ad esempio, la medesima pagina può mostrare tutti gli ultimi post, o solo un post, o può permettere all’utente di aggiungere commenti. Un sistema di questo tipo ottiene quindi un input dall’utente, lo elabora con uno script, e riconsegna un output.

Il XSS consiste nel dare al sito come input uno spezzone di codice, o un intero programma, creato ad arte. Se il sistema dietro al sito web non ha adeguati filtri per riconoscere quali input siano accettabili e quali no, uno spezzone di codice ben fatto può, senza generare errori, venire eseguito dal server che ospita il sito.

La cosa notevole dell’exploit di Glazunov è il suo basarsi su questo tipo di falla, senza quindi coinvolgere i complicati sistemi di corruzione della memoria utilizzati invece da Pinkie Pie.

Chromium, infatti, come tutti i browser moderni, ha delle pagine web interne, chiamate WebUI, raggiungibili con indirizzi del tipo chrome://indirizzo, che servono a svolgere compiti di varia utilità e che hanno accesso ad API del browser non accessibili alle normali pagine web. Le pagine sono tutte linkate in chrome://about. L’esistenza delle pagine WebUI porta ad avere, se non vengono messe in atto le dovute contromisure, una vulnerabilità analoga all’XSS, che viene chiamata UXSS, ovvero XSS universale.

Glazunov ha trovato due bug non particolarmente gravi, che combinati assieme portavano ad una vulnerabilità UXSS di livello “Elevato” (High). Il concorso Pwnium, però, per essere vinto, richiedeva vulnerabilità di livello “Critico” (Critical). Senza buttare il lavoro fatto per trovare questa vulnerabilità, Glazunov ha provato ad appoggiarsi a questo problema per trovare qualcosa di piú grave.

L’ovvio passaggio successivo, quindi, è stato quello di cercare una pagina WebUI con qualche vulnerabilità.

Glazunov ha scoperto che provando a inserire in una pagina WebUI contenente almeno un frame (una struttura delle pagine web per mostrare in una pagina il contenuto di un’altra pagina) una pagina interna per le estensioni non valida, veniva generato un errore in chrome://chromewebdata.

Tale pagina non è protetta dalle Content Security Policy, un insieme di regole standard che impedisce a pagine che non abbiano la stessa origine, ovvero non facciano parte della stessa classe di pagine secondo definizioni che qui è eccessivo approfondire, interagiscano tra loro.

A questo punto, dunque, la pagina chrome://chromewebdata è una pagina a rischio per eventuali attacchi UXSS, se si riuscisse ad eseguirci del codice dentro.

Ora però sorgono alcuni problemi:

  • chrome://chromewebdata, come ci si aspetta, non ha accesso ad API sensibili
  • Gli indirizzi del tipo chrome:// hanno tutti diversa origine
  • Le origini di tipo chrome:// ottengono privilegi solo se il processo che le genera è marcato come privilegiato. Tale marcatura avviene solo se si naviga esplicitamente sulla pagina in questione, e non se la si include in un frame
  • Generalmente le pagine di tipo chrome:// sono protette dalle Content Security Policy

A questo punto, Glazunov si è dimostrato un ottimo risolutore di puzzle game.

Ha aperto una pagina chrome://net-internals in una pagina chrome://chromewebdata appositamente corrotta. Tale pagina contiene un frame. Grazie ad un secondo bug, che permette di sostituire un frame di origine diversa dall’originale, è riuscito ad avere chrome://net-internals come pagina direttamente richiamata dal browser semplicemente tornando indietro nella cronologia.

In questo modo ha ottenuto i (limitati) privilegi della chrome://net-internals, trovandosi cosí in una pagina con privilegi piú elevati di chrome://chromewebdata e con un frame in cui eseguire codice tramite UXSS.

Aperta una pagina bianca del browser (about:blank), è riuscito, grazie ad un bug di JavaScript, a farla credere pagina figlia di chrome://net-internals, dove per figlia si intende aperta da.

Le pagine figlie possono navigare senza perdere i privilegi del padre. Questo ha permesso a Glazunov di navigare verso chrome://download aggiungendo cosí l’accesso ad ulteriori pagine privilegiate.

I privilegi di chrome://download sono decisamente elevati: si tratta della pagina di download, ed ha accesso al disco del computer che ospita il browser. Facile quindi scaricare una libreria malevola, e scaricare ed eseguire un programma qualunque senza chiedere all’utente. Un problema Windows ha permesso di caricare una libreria scaricata in questa maniera nell’eseguibile del browser, considerato sicuro dal sistema.

Ho spiegato il procedimento in maniera molto semplificata, sia perché era semplificata la fonte, sia perché alcuni dettagli implementativi non sono effettivamente interessanti. Non ho linkato i dettagli dei bug, poiché non sono piú disponibili.

Insomma, ottimo lavoro anche quello di Glazunov, che è riuscito a scovare e a far chiudere un’altra importante falla.

Via | Chromium Blog

Leave a Reply

Lorenzo Breda Articolo scritto da

Studente di Informatica a Roma, si occupa di programmazione web sopratutto lato server, e di accessibilità del web. Utilizza e ama Debian GNU/Linux, e si interessa di fisica, fumetto, trekking e fotografia (gli ultimi due possibilmente abbinati). Collabora con Googlab da aprile 2012.

Contatta l'autore

Previous post:

Next post: