Trovato un malware in Ubuntu Snap Store: l’inizio della fine?

3

Recentemente gli amici di Canonical stanno puntando tutto sugli Snap, quei pacchetti che, di fatto, contengono tutto il necessario per l’esecuzione di un dato software, comprese le librerie, e che dovrebbero rendere meno impattante l’aggiornamento di app differenti che utilizzano la stessa “base”.

Che sia per le live patch del Kernel o per la distribuzione di software di utilità, gli Snap oramai sembrano diventare sempre di più la norma per la distribuzione Ubuntu, al punto che si trovano facilmente direttamente in Ubuntu Software, l’applicazione integrata per l’installazione di pacchetti dallo “store” ufficiale.

E’ saltato fuori recentemente che un paio di applicazioni distribuite come Snap, e presenti proprio in Ubuntu Software, contenessero anche un miner di criptovalute, ovvero un piccolo software che, sedendosi in background, utilizzava le risorse del computer ospite per cercare di generare, appunto, criptovalute (Bitcoin, Ethercoin, etc.).

La cosa preoccupante non è data solo da questo comportamento, ma anche dal fatto che lo stesso processo di mining si mascherasse come un demone systemd e che, oltre a questo, gli snap si occupassero di installare uno script che venendo eseguito in fase di boot, caricava il software direttamente in background, eseguendolo anche se l’applicazione fornita dallo stesso snap non era in esecuzione.

Il miner è stato identificato e segnalato su GitHub dall’utente tarwirdur che, nonostante porti la prova esplicita solo per l’applicazione incriminata, 2048buntu, indica anche che tutte le altre applicazioni dello stesso sviluppatore (Nicolas Tomb) installavano lo stesso contenuto; per questo Canonical ha già provveduto a rimuovere tutte le applicazioni di quell’autore in attesa di ulteriori indagini, nello scorso weekend, ma non avendo lo store di Canonical un’indicazione pubblica sul numero di installazioni, non è ben chiaro quanto questo malware sia diffuso.

In ogni caso è stato indicato, come futura nota, che probabilmente il posto migliore dove segnalare questo tipo di contenuti è il forum dello store di snapcraft, l’attuale repository di Snap utilizzato da Ubuntu.

Ma come è finito un cryptominer direttamente sullo store? Beh, semplicemente per il fatto che tutte le applicazioni che vengono inviate per la pubblicazione vengono sottomesse ad un sistema automatico di test che verifica il loro funzionamento e la loro corretta installazione su diverse distribuzioni Linux, ma non vengono controllate riga per riga per eventuali contenuti sospetti.

Inoltre, entrambe le applicazioni sono state pubblicate come software proprietario, rendendo non disponibile il codice e, quindi, facendo si che fosse possibile identificare questo comportamento malevolo solo dopo la loro installazione.

Alcuni, però, suppongono che questo comportamento non fosse realmente malevolo e che l’autore abbia inserito volutamente questo codice (in cui veniva citata una Ferrari) con il solo scopo di attirare l’attenzione sull’uso degli Snap (e di snapcraft) come vettore di trasporto per comportamenti illeciti.

Questa teoria è supportata anche dal fatto che il malware in questione non sfruttava realmente un problema (od un metodo specifico di funzionamento) degli Snap, e che poteva tranquillamente essere inserito anche in un PPA, una AppImage o uno di quei famosi script di installazione tanto in voga su GitHub negli ultimi anni (avete presente i vari

# curl https://github.com/... | bash

? Ecco, non fatelo!).

Quindi, è veramente un problema legato agli Snap? Sarà davvero questo il veicolo di infezione delle future macchine Linux? O è solo un modo per avvertire di un possibile problema che, in realtà esiste da anni?

Ai posteri l’ardua sentenza.

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.

3 risposte a “Trovato un malware in Ubuntu Snap Store: l’inizio della fine?”

  1. Avatar Kim ALLAMANDOLA

    Il problema è il vecchio trust is a weakness, che io rielaboro in “the need of trust is a weakness”. Per considerare sicuro qualcosa dobbiamo poterlo controllare. Poiché non possiamo metterci a leggere, tutti, milioni e milioni di righe di codice dobbiamo accettare un certo rischio e diluirlo il più possibile. La “diluizione” passa per la community ovvero passa per il numero di occhi che scorrono lo stesso codice.

    È vero che NESSUNO, proprietario o FOSS, non fa un reale auditing di ogni cosa (forse OpenBSD ci prova) ma più occhi passano più chances ci sono che un baco od un codice malevolo saltino fuori. Il modello “tradizionale” coi packagers delle singole distro implica vari occhi, pur forse poco attenti, sullo stesso listato. Il modello snap è come quello Microsoft dall’upstream direttamente all’utente. Ovvero va nella direzione opposta i cui disastri ben conosciamo avendo visto la storia di Windows. Nix/Guix vanno invece in una direzione migliore e oltre a tutto non hanno i limiti di snap.

    Pensateci perché se continua questa deriva commerciale arriveremo ad uno scisma in quel che resta della community: da un lato un neonato winux, dall’altro un neonato software libero di ritorno che torna, purtroppo, ad essere elitario e ristretto. Se poi ci mettiamo i recenti movimenti “proprietari” da WSL a DeX è facile immaginare un OS futuro con kernel proprietario, sandboxing proprietario e software libero dentro trasformando quest’ultimo da prodotto della comunità per la comunità in lavoro gratis per la multinazionale di turno.

  2. Avatar Kim ALLAMANDOLA

    Parla invece, più voci si fan sentire più altre si accodano. Se siamo in tanti c’è speranza, se restiamo nei nostri sgabuzzini no.

  3. Avatar Kim ALLAMANDOLA

    Fosse solo quello… Snap NON serve per il cloud o l’IoT, serve solo per diffondere software proprietario non solo “tecnicamente” ma anche per formare la mentalità dell’utente che veda la distro (o l’OS) come “piattaforma vuota” da comporre con software da varie fonti, non come ecosistema completo che ognuno plasma a sua necessità e gusto.

    Per il cloud/IoT NixOS con NixOps è anni luce avanti: hai built-in sia il concetto di IaC (Infrastructure as code, ovvero l’insieme del sistema informatico (infrastructure) scritto in (pochi&leggibili) files di testo, magari inseriti in un CVS dove si vede chi e quando fa ogni commit e deployati da utenti loggati opportunamente, tutto riproducibile e scalabile senza problemi) e pure il concetto di Immutable Servers poiché di fatto NixOS viene “re-buildato” (in manciate di secondi) ad ogni cambiamento della configurazione quindi sostanzialmente NON hai “derive” dallo stato noto e in più hai “immagini sempre aggiornate” poiché il singolo deploy, bare-metal incluso, è come se fosse un’immagine fatta al momento.

    Il problema è che questo sistema presenta l’OS/distro come un qualcosa di unico, sotto il controllo dell’utente, personale, e non funziona granché fuori dal mondo FOSS (per dire non esistono pkg su NixOS, ci sono solo l’equivalente degli spec-files rpm detti derivation e delle cache binarie (repo) degli stessi già compilati). Il mondo proprietario ha bisogno che l’utente (anche aziendale) pensi a singoli prodotti, che al massimo evolvono in piattaforme, “scatole chiuse” che puoi prendere o lasciare. Ai più suona strano specie perché tecnicamente questa visione non è molto consistente ma per la mentalità del manager questo cambia enormemente.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *