Micorsoft Teams, Discord, Mattermost, RocketChat, Visual Studio Code hanno un unico tallone d’Achille

Si è svolta pochi giorni fa a Las Vegas, tra l’11 e il 14 agosto, il DEFCON 2022, la trentesima edizione dell’evento-conferenza forse più noto al mondo in cui hacker etici e ricercatori di sicurezza presentano le proprie ricerche e il proprio lavoro.

Anche nel caso si tratti di responsible disclosures e, quindi, bug e vulnerabilità che sono già state patchate o, in alternativa, proofs of concept senza che venga reso pubblico il codice che realmente servirebbe per porre in essere l’attacco, i lavori presentati sono spesso di forte interesse pubblico e rilevanza mediatica e non possono che indurre a riflessioni di vario genere.

Tra i lavori discussi vi è una vulnerabilità Remote Code Execution, già patchata, che ha colpito applicazioni desktop come Microsoft Teams, Visual Studio Code, Discord, Mattermost e RocketChat.

Vi starete domandando cosa hanno in comune gli applicativi appena citati e la risposta prende il nome di Electron, il framework open source che esiste dal 2013 e che consente agli sviluppatori di poter usare linguaggi web per creare applicazioni desktop.

Sebbene sia un paradigma che ha anche degli svantaggi e tenda, comprensibilmente, a far rabbrividire i puristi, le ragioni della sua popolarità sono molteplici e la convenienza che offre è indubbia: chi, infatti, direbbe di no alla prospettiva di poter scrivere applicativi desktop usando linguaggi tipicamente web oriented come HTML5, CSS, Javascript, senza dover anche imparare dei linguaggi di programmazione desktop come C, C++, Java, Python nonchè le librerie grafiche dei sistemi operativi su cui dovrà girare?

Se ci aggiungiamo il fatto che gli applicativi scritti usando Electron sono anche cross platform e che la conoscenza dei linguaggi web è decisamente più diffusa di qualsiasi altra, la scelta è presto compresa.

Non dobbiamo però considerarci sorpresi quando apprendiamo che un framework alla base delle più popolari desktop app è particolarmente preso di mira e oggetto di studio, nè quando viene annunciata una vulnerabilità che, improvvisamente, consente di bucare svariati applicativi che tra loro hanno poco a che vedere.

La vulnerabilità di cui stiamo parlando non è la prima nè, certamente, sarà l’ultima, ed è stata discussa da Aaditya Purani, security researcher che annuncia:

We were able to compromise 20 different Electron applications that are used by millions of people. […] Just using HTML, JavaScript, and CSS you can ship an entirely cross platform native desktop application […] so the only thing you need to do as an attacker is to find a way to invade your JavaScript within the webpage.

Siamo stati in grado di compromettere 20 applicazioni Electron usate da milioni di persone. […] Usando semplicemente HTML, Javascript e CSS, si possono creare applicazioni desktop native completamente cross platform […] quindi l’unica cosa che vi servirà fare, se state attaccando, sarà compromettere il Javascript che gira nella pagina.

La pagina a cui si riferisce è proprio il nostro applicativo Electron, dal momento che esso verrà renderizzato come pagina web, tramite le librerie di Chromium. Eh si, avete capito bene: un applicativo Electron non è così diverso da un sito web che, però, almeno di default, non offre lo stesso livello di isolamento che avrebbe offerto un normale sito web aperto con Chromium.

Uno sguardo alla pagina di security del sito web del progetto, infatti, porta a questo warning:

When working with Electron, it is important to understand that Electron is not a web browser. It allows you to build feature-rich desktop applications with familiar web technologies, but your code wields much greater power. JavaScript can access the filesystem, user shell, and more. This allows you to build high quality native applications, but the inherent security risks scale with the additional powers granted to your code.

Quando lavoriamo con Electron è importante tenere a mente che non è un browser web. Ti permette di costruire applicazioni desktop ricche di feature con tecnologie web familiari ma il codice ha un potere nettamente maggiore. Javascript può accedere al filesystem, alla shell utente e non solo. Questo ti permette di costruire applicazioni native di alta qualità ma i rischi di sicurezza aumentano di pari passo con i poteri addizionali che vengono dati al tuo codice

Ancora, si legge sulla pagina dedicata al sandboxing:

Historically, this mixed sandbox approach was established because having Node.js available in the renderer is an extremely powerful tool for app developers. Unfortunately, this feature is also an equally massive security vulnerability.

Storicamente, l’approccio della sandbox mista è stato stabilito perchè avere Node.js accessibile dal renderizzatore si dimostra essere strumento molto potente per gli sviluppatori di app. Sfortunatamente, questa funzione è, allo stesso tempo, anche una grossa vulnerabilità.

E continua con:

Theoretically, unsandboxed renderers are not a problem for desktop applications that only display trusted code, but they make Electron less secure than Chromium for displaying untrusted web content. However, even purportedly trusted code may be dangerous — there are countless attack vectors that malicious actors can use, from cross-site scripting to content injection to man-in-the-middle attacks on remotely loaded websites, just to name a few. For this reason, we recommend enabling renderer sandboxing for the vast majority of cases under an abundance of caution.

In teoria, i renderizzatori che non girano in una sandbox (non isolati) non sarebbero un problema per le applicazioni desktop che mostrano solo codice di cui ci fidiamo ma rendono Electron meno sicuro di Chromium per visualizzare contenuti web non fidati. Comunque, anche del codice presumibilmente fidato potrebbe essere pericoloso – vi sono una quantità innumerevole di vettori di attacco che attori malevoli possono usare, dal cross site scripting al content injection al man in the middle quando si caricano siti web remoti, giusto per nominarne alcuni. Per questo motivo, per abbondare in cautela, raccomandiamo di abilitare il sandboxing (isolamento) del renderer per la maggior parte degli utilizzi.

Electron, quindi, offre una lunga serie di parametri di sicurezza e scelte che possono mitigare i rischi dell’eseguire codice non fidato, non tutti però attivi di default. Vi è, però, una falla in tutto ciò: la scelta di utilizzare o meno le feature di sicurezza e di isolare o meno le componenti che Electron usa per funzionare è nelle mani degli sviluppatori e non dell’utente finale.

Se vi state domandando come fare, quindi, per sapere se il vostro applicativo utilizza il sandboxing o tutte le altre feature di sicurezza che Electron offrirebbe, siete arrivati a un dubbio pienamente legittimo per cui non vi è necessariamente una risposta chiara ed è parte degli svantaggi dell’utilizzare degli applicativi Electron quando, per le stesse funzionalità, esistono i siti web dei servizi in questione.

In questo caso, se per qualche motivo siete costretti a usare le app Electron, come utenti finali avete ben poco controllo su come queste sono state implementate a livello di sicurezza.

Ad esempio, oltre a una abbondanza di altri parametri che possono essere utilizzati dagli sviluppatori vi è anche la versione delle librerie di rendering Chromium utilizzate dall’applicativo, le quali non sempre sono aggiornate e, di conseguenza, possono presentare vettori di attacco non patchati.

Che dire, quindi? Ha senso mettersi di traverso e opporsi a quella che sembra la naturale evoluzione di una parte del software che utilizziamo giornalmente? Probabilmente no, ma come sempre è bene tenere alta la guardia e essere al corrente di ciò che avviene ‘sotto’ gli applicativi che usiamo e non finire, quindi, per dare per scontato nulla e avere quindi un falso senso di sicurezza.

Se è vero, infatti, che non abbiamo controllo su come è stato scritta la nostra app, è anche vero che abbiamo ancora il controllo su dove esso girerà e sul nostro sistema operativo e, essendo adesso a conoscenza del potenziale problema, possiamo isolare i nostri applicativi in molti modi, ad esempio creando una policy SELinux o AppArmor ad hoc per gli applicativi più esposti.

Candidati ideali sono ad esempio quegli applicativi che prevedono chat con altri utenti e che, quindi, presentano il rischio di far eseguire codice remoto sulle nostre macchine solo al click di un link opportunamente confezionato.

A seconda del livello di paranoia prudenza, possiamo anche spingerci oltre e isolare gli applicativi facendoli partire da un container o, addirittura, all’interno di una macchina virtuale, a forte discapito della convenienza d’uso.

Un ulteriore mitigazione consistere nel passare a Wayland, ormai offerto di default da molte distribuzioni e funzionante con quasi tutti i driver GPU, al posto di Xorg, ormai considerato insicuro, ma questa è un’altra, lunga, storia.

Tags: , , , , ,