Pokemon è ancora al centro dell’attenzione ma stavolta non a causa della popolare applicazione sviluppata da Niantic per iOS e Android.

Trend Micro, leader mondiale per la protezione dati in internet e per la sicurezza nel cloud, ha da pochi giorni rilevato un nuovo rootkit che ha come bersaglio i dispositivi Linux-based. Il rootkit è in grado di colpire sistemi a 32 bit o a 64 bit sia basati su Intel che su ARM. Persino i sistemi embedded (come i router) sono a rischio.

Il nome del rootkit è Umbreon, nel videogioco Umbreon è un Pokemon che si nasconde nell’ombra, da qui il nome del virus.

Dopo essersi infiltrato nel vostro pc Umbreon crea un account utente fittizio che gli hacker usano per accedere al device via SSH. Questa la home screen che viene mostrata quando il virus vi ha colpito:

umbreon rootkit

Se vedete quest’immagine sul vostro pc preoccupatevi: stavolta è Umbreon che ha catturato voi.

Trend Micro l’ha contrassegnato come un rootkit ring 3 ovvero un virus che non va a toccare il kernel ma agisce a livello utente è quindi in grado di spiare tutto ciò che fate col vostro pc. E’ in grado di intercettare le più importanti system call (read, write etc) del sistema operativo che vengono gestite usando le librerie di Umbreon essendo caricate per prime dal loader.

Il virus, interamente scritto in C, va a sostituire la glibc (GNU C library): il loader carica prima lui e le sue librerie fasulle invece di quelle originali. Pertanto è rilevabile solo da software che non sono basati sulla libc.

La backdoor espeon

rootkit-feature-

Espeon, altro nome di Pokemon, è invece una backdoor usata dai malintenzionati per accedere ai sistemi infettati con Umbreon.

Espeon va a creare una shell, che viene configurata per collegarsi automaticamente ai pc degli hacker agendo come una reverse shell permettendo il bypass dei firewall.

Espeon cattura tutto il traffico TCP che giunge all’interfaccia Ethernet.

Come rimuoverlo

E’ possibile rimuoverlo dopo essere stati colpiti ma non è un’operazione semplice e potrebbe andare a compromettere il sistema, come spiegato sul blog ufficiale di Trend Micro.

Questa la mini guida messa a disposizione dall’azienda:

  1. Mount the partition where the /usr directory is located; (necessari i permessi di scrittura)
  2. Backup all the files before making any changes.
  3. Remove the file /etc/ld.so.<random>.
  4. Remove the directory /usr/lib/libc.so.<random>.
  5. Restore the attributes of the files /usr/share/libc.so.<random>.<arch>.*.so and remove them as well.
  6. Patch the loader library to use /etc/ld.so.preload again.
  7. Umount the partition and reboot the system normally.

Questo è un esempio:

umbreon removal

Lo svilppo di Umbreon è iniziato nel 2015 e oggi è un rischio per la comunità Linux, pertanto occhi aperti quando installate o scaricate file dal web.

 

sharing-caring

Vi ricordiamo che seguirci è molto semplice: tramite la pagina Facebook ufficiale, tramite il nostro canale notizie Telegram e la nostra pagina Google Plus.

Qui potrete trovare le varie notizie da noi riportate sul blog. È possibile, inoltre, commentare, condividere e creare spunti di discussione inerenti l’argomento.

 

  • farebbero bene a cambiare nomi, è un attimo che nintendo glieli faccia rimuovere visti i precedenti con youtube e i giochi fan made xD
    ahahahahah

  • konV

    Si può prendere solo scaricando da fonti non attendibili o anche semplicemente navigando su internet con banner o altro?

    • Matteo Gatti

      L’installazione di Umbreon non è automatica: prima devono bucare il tuo sistema con altri metodi e successivamente installarlo manualmente

      • Appunto. Quindi bisogna essere tanto stupidi da andare a beccarselo e gli utenti devono stare attendi con esperimenti di vario tipo, sperando che il sistema in qualche modo non venga bucato.

        Quindi nella maggioranza dei casi il problema non sussiste.

        • fandangozx

          Eventualmente esiste un modo per controllare se si ha il PC infetto?

          • Samael

            Lo puoi fare cercando i file presenti nella stessa guida alla rimozione

            Remove the file /etc/ld . so .
            Remove the directory /usr/lib/libc . so .

            Controlla la presenza del file e della directory indicati.
            Se non ci sono allora non hai nessun problema.

          • fandangozx

            in /etc ho solo .conf e .cache
            mentre in /usr/lib non c’è nulla allora posso dornmire sereno 😀
            Ggrazie!

          • Con ClamAV.

  • Maurizio Tosetti

    Virus per linux? un bel banco di prova

  • altermetax

    Ma se gli “hacker” accedono via SSH all’account fittizio creato da Umbreon, come fanno a spiare l’account utente principale? Questa spiegazione non regge…

    • Matteo Gatti

      “During installation, Umbreon creates a valid Linux user that the attacker can use with a backdoor into the affected system”
      Lo usano anche se sei loggato nel tuo account principale

      • altermetax

        E fin qui va bene, ma non possono leggere la home dell’utente principale tramite un altro utente.

  • Maurizio Tosetti

    Mi devo preoccupare ?

  • Che ci provino a bucare il sistema e solo se il nostro sistema GNU/Linux fosse bucato in qualche modo allora esso può fare breccia.
    Diversamente il problema non sussiste.

  • oinophilos

    Mi pare abbastana una sparata. Per cominciare per modificare le libc deve essere esguito con i privilegi di root.
    Quindi: o hai un bug che permette di scalare i privilegi; o sei cretino ed esegui delle cose prese a caso come root.

    • Matteo Gatti

      non è che modifichi la libc, impone al loader di caricare le sue librerie prima di quelle originali, così facendo inganna il sistema e si sotituisce alla libc

      • abePdIta

        Sì, ma servono comunque i permessi di root, per fare una cosa del genere. O sbaglio?

    • ale

      Di falle ce ne sono fin che vuoi, ne trovano non so quante, basta che il sistema non sia aggiornato e ci metti un attimo, fra l’altro basta una falla in un qualunque programma che gira come root (tipo un server di qualcosa) per poter quindi andare ad ottenere magari i privilegi per cambiare i permessi della directory /usr e modificare quei file, quindi insomma…

      Per l’utente idiota, il 99% degli utenti sono così, quindi, anche su Windows ci sono i permessi di amministratore (e sono gestiti in maniera molto più ferrea di quanto sono gestiti in Linux), eppure i malware ci sono…

      L’unica cosa da fare per evitare questi problemi è ovviamente quella di firmare tutto, firmware UEFI, bootloader (grazie al secure boot), kernel, libC e tutto quanto di così fondamentale insomma, come viene fatto in altri sistemi…

      • Aury88

        “anche su Windows ci sono i permessi di amministratore (e sono gestiti in
        maniera molto più ferrea di quanto sono gestiti in Linux), eppure i
        malware ci sono…”
        eh? O_o

        • ale

          I permessi di Windows sono molto più sofisticati, quelli di UNIX sono molto più basilari (es puoi solo impostare permessi per un utente ed un proprietario, vuoi che un file sia accessibile con permessi diversi da utenti diversi o gruppi diversi, ti attacchi sostanzialmente… a livello domestico non te ne fregherà nulla, ma a livello enterprise, serve)

          • Maddo

            Guarda che più semplice != meno sicuro. Su UNIX i permessi si basano su 3 distinzioni: il proprietario del file, il gruppo del proprietario e tutti gli altri. Per ognuno di questi tre si impostano i permessi rwx(read, write, execute[per le directory, execute si traduce in l’avere accesso al file tramite il nome e.g. una pagina web]). Su Windows ci sono gli ACE, che sono sì più complessi(gestiscono più azioni, hanno inheritance[che è forse l’unica cosa degna di nota], ecc…) ma non per questo più sicuri rispetto a UNIX.

          • zazà

            Bello come cerchi di darti un tono mettendo termini inglesi a caso tipo “inheritance” giusto per costruire supercazzole che cerchino di impressionare il tuo interlocutore, ma che in realtà servono solo ad evitare di dare risposte come quella che non hai dato qui, visto che non si legge da nessuna parte nel tuo post come i permessi UNIX siano alla pari delle ACL.

            Ma tu non eri quello del “driver daemon” e del “framebuffer che sostituisce il kms”? Vedo che il vizietto di fare il saputello su internet parlando di argomenti di cui non sai nulla non l’hai perso.

          • Maddo

            In realtà avevo fatto una semplice domanda: i permessi UNIX sono più semplici delle ACL di Windows, e non ci piove, ma in quale caso essi sono meno sicuri?

          • Aury88

            da quello che so puoi creare gruppi (e associare ad ognuno un grado diverso di privilegi) e aggiungere a quei gruppi gli utenti…era qualcosa tipo

            usermod -aG nome_gruppo nome_utente..

            non è comodissimo ma di fatto così puoi associare a ciascun utente privilegi di accesso

            Inoltre su linux sono credo almeno 10 anni che puoi utilizzare un ACL oltre ai permessi tradizionali di Unix. prova a vedere

            http://linux.about .com/library/cmd/blcmdl1_setfacl.htm
            intendevi queste cose?

  • me

    Il blog è molto chiaro e per scripolo ho verificato se per caso ho preso il rootkit e per fortuna la risposta è negativa. Comunque è molto difficile da individuare per non dire impossibile dalla propria macchina, l’unica possibilità è usare direttamente le librerie di livello kernel per vedere se si hanno i file cambiati. Ls non funziona e così tutti gli altri comandi, sono tutti taroccati da questo rootkit che agisce a livello utente, quindi non gli servono i permessi di root.

    Il ragazzo ha fatto un lavoraccio, complimenti.

    Servirebbe un ls che non usi vprintf(), __vfprintf_chk(), and fputs_unlocked(). ma che usi direttamente
    write() system call e che fosse scaricabile dai repository. In questo modo si fa un bel ls_level0 e si scoprono tutti questi rootkit di livello 3.

    Esiste già una ls_level0?

    • Samael

      Non c’è bisogno di una ls kernel-level.
      Per ovviare al problema sarebbe bastato linkare lo userland staticamente.

      • gabriele tesio

        qual’è la differenza, in parole semplici, tra il linkaggio statico e dinamico? con pro-contro se possibile.

        • Samael

          Allora, per spiegare il linking dobbiamo fare qualche passo indietro.

          I software, sappiamo tutti, fanno uso di librerie. Queste sono collezioni di funzioni che vengono utilizzate dai vari binari che compongono una applicazione.
          Ogni libreria è composta da due elementi
          1) la parte binaria (i file . so presenti in /usr/lib)
          2) l’header (i file . h presenti in /usr/include)

          L’header è usato a livello di codice sorgente tramite la direttiva #include e contiene al suo interno tutte le macro ed i prototipi di funzione, ovvero la dichiarazione di una funzione con i vari parametri che essa chiede.
          Tuttavia bada bene: l’header NON contiene nessuna funzione, ma solo dichiarazioni.
          Ciò serve al preprocessore (cpp) affinché, quando vada a processare il sorgente per poi passare la palla al compilatore, sappia che la funzione int pippo(int a, int b) non sia una roba uscita a caso, ma una roba definita in un contesto specifico, ovvero l’header a cui facciamo riferimento.
          E come fa a sapere dove si trova l’header in questione? Dalle variabili CFLAGS e CXXFLAGS (la prima per il compilatore C e la seconda per quello C++) che contengono sviariate direttive “-I/path/libreria”, spesso ottenute in fase di configure tramite l’uso di pkg-config.
          Una volta che l’header è stato trovato e quindi le funzioni e le macro sono state definite correttamente, il compilatore può provvedere a creare il codice oggetto (. o) di ogni file del sorgente.
          Tuttavia il codice oggetto non è eseguibile. Per poterlo diventare occorre far sì che quelle funzioni definite nell’header vengano messe a disposizione a livello binario.
          Mi spiego meglio: l’header pippo.h che abbiamo messo nel codice sorgente contiene solo una lista di funzioni. Ma non ne contiene la logica. Ecco perché si chiamano prototipi di funzione.
          Immagina un registro scolastico con la lista degli alunni. Ecco è una cosa del genere.
          In sostanza tu avrai definite cose come:

          int somma(int a, int b);

          che vanno benissimo al preprocessore in quanto lui ha solo bisogno di sapere se somma() sia una funzione esistente, tuttavia non vanno bene al software perché questo ha bisogno della logica.
          Ed ecco che interviene il linker (GNU ld nel nostro caso) che va quindi a legare il codice oggetto al binario contenente la funzione definita nell’header.
          Come fa a sapere dove sta? Tramite la variabile d’ambiente LDFLAGS che ha parametri tipo “-L/path/libreria -lpippo”; anche in questo caso molto spesso LDFLAGS viene “riempita” da pkg-config.

          Ora che differenza c’è tra il linking statico e quello dinamico?
          Il linking dinamico scrive nel codice oggetto che sta per diventare eseguibile un riferimento alla libreria che contiene la funzione. Ovvero gli dice: “ciccio, la funzione somma la devi cercare in libpippo . so”, che diventa quella che tutti noi conosciamo come DIPENDENZA.
          Nel linking statico le funzioni presenti in libpippo vengono integrate direttamente nel codice oggetto che diventa binario eseguibile rendendolo indipendente dalle dipendenze.
          Le librerie statiche infatti sono dei meri archivi AR, che riconosci in quanto hanno l’estensione . a. Esse sono persino esplorabili tramite il comando ar e contengono tutti i codici oggetto che compongono la libreria.
          Erroneamente si pensa che il linking statico sia l’integrare tutta la libreria in un software, ma non è così.
          Solo il codice oggetto che contiene la funzione desiderata viene integrato, non il resto.

          Il vantaggio è che tutti i binari sono indipendenti e sono CROSS-DISTRO. Una applicazione compilata e linkata staticamente su Ubuntu 10.04 32-bit può funzionare su tutte le distro Linux anche a 64-bit prive di multilib senza bisogno di nient’altro.
          Non si avranno MAI problemi di runtime, come dipendenze non soddisfatte o incompatibilità binarie.
          Lo svantaggio è che il software è indipendente, e quindi in caso di vulnerabilità in una libreria usata va ricompilato.

          Il vantaggio del linking dinamico non esiste. Si dice che occupi meno spazio su disco ma in realtà non è vero, perché il problema dello spazio eccessivo richiesto dai software statici è in realtà imputabile a GLIBC che è volutamente incompatibile con questo linking.
          Di contro però introduce ENORMI falle di sicurezza: LD_LIBRARY_PATH ed LD_PRELOAD permettono di caricare al volo librerie e funzioni in memoria, andando incontro a iniezioni di codice malevolo che va a sostituire quello buono.

          Il virus in questione fa proprio questo, ma lo fa peggio.
          Anziché sfruttare le due variabili d’ambiente a runtime, va direttamente a modificare il loader e la libc del sistema, andando così a corrompere in maniera perenne il sistema.
          Con un modello statico non ci sarebbero MAI stati danni di questo tipo, perché ld-linux . so non viene affatto usato, e di conseguenza ogni software sarebbe stato al sicuro.

          • Aury88

            dimmi samael, tieni per caso corsi di informatica? no perchè se no ai un nuovo studente xD

          • Samael

            Figurarsi…
            Io che tengo un corso? Nah… xD

          • kensan

            Ok, Samael non tieni corsi ma il tuo testo è scritto troppo bene. Sei
            sicuro di non averlo copiato pari pari da un libro? Se è tutta roba tua
            mi piacerebbe metterlo nel mio sito kensan dot it,
            ci troverò un titolo del tipo
            Programmazione_linking_dinamico_vs_statico e lo metto a tuo nome: Samael
            e la mia email kensan@kensan.it
            Dimmi se sei contrario. Mi
            sentirò libero di modificare il testo in quanto occorre spiegare cosa è
            questa roba del “virus in questione”.
            P.S. se non mi rispondi io lo pubblico.

          • Samael

            Non mi permetterei mai di copiare qualcosa senza mettere una citazione specificando “nome e cognome” di chi l’ha detta.

            Tutto ciò che hai letto è semplicemente frutto di esperienza che ho maturato nel corso degli anni. E ciò che ho imparato lo devo principalmente alla distribuzione che uso, Slackware, che mi ha permesso di capire cosa avviene “sotto il cofano” facendomi diventare il diretto responsabile della gestione dello strato applicativo del sistema operativo.

            Per quanto riguarda il pubblicare sul tuo blog non mi importa. Fa pure se lo ritieni necessario.

          • kensan

            Grazie 🙂

          • Luky

            woah, e io che uso gentoo e continuo a non capisci comunque una cippa
            vabbè spero che mo che inizio il primo anno di ingegneria informatica di capirci anche io qualcosa bene, almeno spero
            L’unica cosa differenza che capisco tra linking statico e dinamico è la dimensione del file stesso lol e del fatto che gli eseguibili dipendano da librerie posizionate chissà dove, già se penso a libc mi viene solo in mente “Ma che roba è? c’entra col compilatore?”
            Anche se del fatto che il linking statico risolva un bordello di problemi in ambiente linux già ne ero a conoscenza, io spero soltanto che la major distro ubuntu cerchi di spingere su snap, e niente, altrimenti non cambierà mai nulla

          • gabriele tesio

            Grazie per la spiegazione, se il linking statico è migliore, perché non viene usato? quanto sarebbero estensive le modifiche per sfruttarlo? C’è una qualche distro che lo sfrutta già/piani per usarlo a breve/medio/lungo termine?

          • Samael

            Il linking statico è DA SEMPRE mal visto dalla FSF in quanto viola palesemente la clausola di mixing di codice con differente licenza.
            Come ti ho già detto: quando tu compili staticamente un software non fai altro che unire il codice oggetto della libreria a quello del software creando un binario eseguibile completo.
            Ma questo vuol dire che se il codice della libreria è sotto licenza incompatibile con la LGPL tu stai creando un binario ILLEGALE in quanto girano nello stesso spazio di allocazione parti di codice non combinabili.
            Diverso è con il linking dinamico che invece permette la cosa in quanto la libreria è vista come una sorta di plug-in.
            Tant’è che l’unica soluzione è o distribuire tutto sotto LGPL (anche il tuo software proprietario) oppure permettere agli utenti di re-linkare il software sotto differente libreria, ovvero linkarla dinamicamente.
            ATTENZIONE: sto parlando di LGPL. Con la GPL non potresti nemmeno fare linking dinamico, perché non c’è un fork() per chiamare il codice non-GPL.
            Ma la FSF non si è limitata a parlare male del linking statico ma ha cercato di impedirlo. Come? Rendendo bloat la GLIBC aggiungendoci simboli inutili, in modo che un software linkato staticamente sia esageratamente voluminoso anche se contiene un semplice “Hello World”.
            In aggiunta a questo, GLIBC è piena zeppa di estensioni non standard al linguaggio, rendendo molti software incompatibili con altri OS o libc, a meno di patch custom.
            Per questo ho spesso detto che GLIBC è spazzatura e GNU è un cancro.
            E le critiche a GLIBC sono arrivate da più parti, tipo da Torvalds.

            Naturalmente per giustificare la cosa, per anni Ulrich Drepper (ex-sviluppatore Red Hat e sviluppatore di GLIBC) andò a dire in giro le famose stupidaggini relative alla migliore sicurezza del linking dinamico derivata dal fatto che si patcha una volta e tutti i software sono al sicuro.
            Ed è per questo che oggi su Linux ci ritroviamo ancora le dipendenze a ragnatela con tutti i problemi che ne derivano: repository di terze parti che incasinano il sistema, applicazioni vecchie, impossibilità di avere una versione più recente di un software senza aggiornare la distro ecc.
            Non possiamo tecnicamente uscire da questa spirale finché qualcuno non avrà le palle (permettimi il termine) di mandare GNU a quel paese e rendere Linux un SISTEMA OPERATIVO completo.
            E intanto Mac OS X da 25 anni (se contiamo il suo antenato NeXTSTEP) impone il linking statico salvo rare e limitate eccezioni nei bundle senza problemi di spazio su disco o delle minchiate di sicurezza paventate da Drepper.

            E che la soluzione in stile OSX fosse la migliore alla fine l’hanno dovuto ammettere tutti i big, al punto che oggi stiamo arrivando ai bundle.
            Il problema è che Flatpak non impone l’uso dello statico, ma anzi continua a parlare di runtime condivisi. E non si può nemmeno fargliene una colpa: con GLIBC di mezzo staticizzare è da pazzi.
            Canonical invece ha dato la possibilità dello statico su Snappy e spero che si arrivi a sponsorizzare musl come libc de-facto dell’SDK (se lo è già avvertitemi).

            Tuttavia è comunque impensabile oggi GNU/Linux senza GLIBC, specie perché software come systemd dipendono fortemente da essa e non vogliono supportare altre libc in quanto sono troppo poco diffuse.

            Morale della favola: se vuoi linkare staticamente su Linux devi usare libc alternative più sane tipo musl. Non ci sono alternative.

          • gabriele tesio

            Grazie mille per la spiegazione e il tempo che dedichi alle tue risposte.

          • icos

            Ho letto con molto interesse i tuoi post, ma ho una domanda/riflessione da farti: se da una parte e’ vero che il linking dinamico espone a problemi tutto il software che ne fa uso, dall’altra dovrebbe permettere un facile e relativamente indolore fix perche’ basta una patch sulla libreria interessata e hai sistemato anche tutto il resto. Inoltre c’e anche un discorso di occupazione della memoria, se ho N applicativi che usano la stessa libreria e’ inutile caricare N volte la stessa libreria; e’ un discorso che aveva piu’ senso in passato quando le risorse erano piu’ limitate (e piu’ costose), ma buttare via memoria per niente non e’, secondo me, un buon modo di lavorare.
            Inoltre supponiamo che venga trovata una falla che sfrutta una certa lib, se e’ tutto statico ti tocca ricompilare tutti gli applicativi che ne fanno uso oppure aggiornarli. Quest’ultima penso sia la strada piu’ utilizzata (siamo rimasti in pochi a compilare a manina immagino), ma se il dev tarda nell’aggiornare? Rimani scoperto finche’ non arriva una patch?
            Insomma, condivido in parte il tuo ragionamento, ma non vedo cosi tanti aspetti negativi nel linking dinamico…

          • Samael

            Le cose non sono così semplici come le descrivi:
            1) Ti basta un fix per sistemare tutto?
            Ne sei convinto? Innanzi tutto poniti la domanda: come fai a fixare? Con il package manager? Impossibile, perché è corrotto anch’esso, in quanto anche quest’ultimo va a richiamare la libreria corrotta.
            E non puoi nemmeno usare lo userland UNIX perché anch’esso è linkato dinamicamente. La soluzione te l’ha data l’articolo: devi usare binari compilati con una libc differente, tuttavia non è sicuro usare strumenti a linking dinamico che si portano le librerie in una directory, perché essi farebbero sempre e comunque capo ad ld-linux, che è corrotto.
            Quindi dovresti usare binari STATICI che non usano un loader e non avrebbero problemi.
            Con i binari statici non sarebbe mai successo. E già questo scenario basta per invalidare la tesi de “il linking ha i suoi vantaggi”. Perché quella che tu definisci vantaggio in realtà è uno scambiare la sicurezza per una ipotetica comodità.
            Comodità che non dovrebbe nemmeno esistere perché il vantaggio del linking dinamico di poter ridurre il carico della ricompilazione è vero SOLO se consideriamo il modello delle distribuzioni Linux valido. Ma così non è.
            Da che mondo è mondo il binario DEVE essere fornito da chi sviluppa il software, NON da persone terze. Sta a chi sviluppa fare QA dei binari del suo software.
            Le distribuzioni Linux sotto questo punto di vista hanno smesso di avere senso anni fa, quando la maggior parte del software viene messa a disposizione su internet e non più in supporti locali, come avveniva alla notte dei tempi.

            Senza contare che non è affatto così scontata la cosa del patchare e risolvere al volo. Ho già spiegato che ci sono innumerevoli casi, OpenSSL in testa, in cui una libreria cambia ABI *ANCHE* in minor release. E questo vuol dire che la compatibilità binaria non è in tutti i casi garantita e si può risolvere solo ricompilando.

            In aggiunta a questi due scenari c’è un’altra considerazione da fare: chi ti dice che se una libreria ha una vulnerabilità devi ricompilare TUTTI i software linkati staticamente?
            Il software linkato staticamente NON HA librerie al suo interno, l’avevo già detto. Ha solo PARTI della libreria, ovvero i codici oggetto necessari al suo funzionamento.
            Una libreria statica la si può definire un archivio zip (in realtà è ar) contenente più file al suo interno. Questi file sono i codici oggetto derivati dal sorgente.
            Ad esempio:
            libdisney.a contiene
            pippo.o
            paperino.o
            pluto.o
            topolino.o

            Se la tua applicazione minni ha bisogno delle funzioni contenute in topolino.o, solo quest’ultimo verrà inglobato.
            Il che vuol dire che se pippo.o ha un problema a te non fregherà nulla perché pippo.o non c’è. Tra l’altro essendo che ogni binario potrebbe avere un runtime linkato staticamente differente dagli altri non è nemmeno detto che siano tutte le applicazioni da ricompilare. Potrebbero benissimo essere una o due.
            Ma anche così è un compito che spetta a chi sviluppa il software, non alle distribuzioni.
            Giustificare un comportamento sbagliato utilizzando metodi sbagliati non rende la situazione giusta. La rende ancora più catastrofica. Non a caso i grandi si stanno TUTTI orientando verso il modello a bundle, lasciando perdere il modello a ragnatela attuale. Perché questo non funziona. Non ha MAI funzionato.

            2) Evitare di caricare in memoria la stessa libreria
            Ed infatti il motivo per cui questo virus è terribile è proprio a causa della comodità di cui parli.
            Il fatto di poter condividere runtime in memoria rende AUTOMATICAMENTE infetto qualsiasi binario e di conseguenza rende impossibile il fix.
            Non a caso è stato detto di usare binari linkati con libc differenti. Proprio per non RIUSARE il codice allocato.
            Senza contare che i binari statici possono condividere allocazioni, ma SOLO con loro stessi. Ovvero due sessioni dello stesso programma condivideranno le API allocate. Ma due programmi diversi no, ed è giusto così.
            Tra l’altro la questione memoria non è mai stato un problema considerando che su UNIX il modello statico è sempre stato il modello usato.
            Le librerie dinamiche sono arrivate dopo è furono frutto di uno studio condotto dalla SUN. Studio che la stessa SUN decretò fallimentare per i motivi che ti sto descrivendo, ma che venne invalidato da esigenze di mercato.
            Sì, il linking dinamico abbiamo cominciato ad usarlo per ragioni di marketing.
            Oltretutto come ho già detto nel punto 1 i binari statici NON contengono librerie, ma parti di esse, quindi NON è detto che due binari che facevano uso della stesa libreria richiedano le stesse identiche API.

            3) Ritardi nelle patch
            Il problema è molto più vasto di così perché la situazione che descrivi tu è valida anche nel linking dinamico.
            Se la patch non arriva nessun software è patchato. Di conseguenza se proprio vogliamo metterla in questi termini ti dico che è meglio avere ritardo su UN software e averne tutti gli altri patchati, anziché averne NESSUNO coperto.
            Detto questo vale quanto detto nei punti 1 e 2: i software statici sono indipendenti. NON è detto che il runtime e/o le funzioni linkate siano le stesse, quindi NON è vero che TUTTI i software andrebbero ricompilati.
            Inoltre lo scenario che tu proponi è sbagliato a prescindere perché si basa sull’idea di sicurezza assoluta: ovvero rendere sicuro il software chiudendone i bug.
            Questo modello è SBAGLIATO perché non importa quante patch avrà il tuo software, i bug ci saranno sempre e comunque. Un software non sarà mai bug free. Persino la stessa patch può introdurre vulnerabilità in quanto va a modificare un comportamento previsto in fase di sviluppo.
            La vera sicurezza la si ottiene MITIGANDO la vulnerabilità affinché anche se presente non sia effettivamente sfruttabile.
            Chi se ne importa se la libreria pippo oggi ha un bug, se quest’ultimo non è tecnicamente sfruttabile? Certo, fixarlo è sempre e comunque importante, ma se posso mitigarlo il fix diventa una cosa che si può pianificare con molta più calma.
            Già oggi qualunque sysadmin mitiga un problema quando escono dei bollettini di sicurezza, nell’attesa che il fix ufficiale arrivi.
            Per questo si stanno cercando di implementare le sandbox: proprio per creare un nuovo set di privilegi che vada a ridurre il campo d’azione dei singoli binari affinché vulnerabilità note vengano mitigate già in partenza.
            Detto questo: il problema della vulnerabilità delle librerie è un non problema perché questo tipo di attacco è inusuale in ambito desktop e prende per lo più plugin binari come flash che ormai tutti stanno cercando di deprecare.
            In ambito desktop gli attacchi sono spyware, adware e ransomware veicolati tramite ingegneria sociale, che va quindi ad ingannare l’utente spacciando il malware per un software ufficiale e sicuro.
            E su questo non c’è modo di risolvere il problema perché è questione di utente. Il problema sta tra la sedia e la tastiera.
            Semmai però il linking dinamico dà una mano ai malintenzionati perché permette loro un’infezione pandemica che va a colpire il loader e la libc. Esattamente come è avvenuto con questo virus.

          • icos

            Mmh devo ammettere che il ragionamento fila e mi hai piuttosto convinto. Va contro quello che ho studiato su diversi testi ma effettivamente sono tutte ragioni piu’ che valide. Purtroppo non ho mai avuto modo di approfondire seriamente il discorso e quindi mi chiedo se non ci siano ulteriori motivazioni tecniche a supporto del linking dinamico. Penso che approfondiro’ il discorso. Grazie per aver condiviso la tua idea, e’ stata molto utile e interessante!

          • Fighi Blue

            “Erroneamente si pensa che il linking statico sia l’integrare tutta la libreria in un software, ma non è così.” è proprio questo quello che non sapevo appunto, grazie per la spiegazione

          • abePdIta

            Sì, però, come faceva notare oinophilos, per modificare le librerie buone con quelle cattive, occorrono i permessi di root. Per cui io non parlerei di enormi falle di sicurezza, ma del fatto che se del codice malevolo ottiene i permessi di root, può fare quello che vuole. Potrebbe anche sostituire completamente il software realizzato con link statici, con una copia malevola, senza che tu te ne accorga. Certo, è più complicato, ma dal momento che hai i permessi di root, non ci sono ostacoli.
            Inoltre, secondo me, dire «Il vantaggio del linking dinamico non esiste.» è un po’ eccessivo. Ogni bravo studente di informatica si è sicuramente sentito dire almeno una volta «Non duplicare codice», cioè non scrivere due o più volte la stessa porzione di canali in punti diversi del programma, perché questo porta a problemi di manutenzione. Se scopri che nel tuo software c’è un errore, è molto più facile dover correggere il codice in un punto preciso, piuttosto che in decine di punti diversi.
            Il link dinamico è grosso modo lo stesso concetto, applicato al Sistema Operativo, anziché al singolo programma. Se domani si scopre che in una libreria c’è una falla di sicurezza, è molto più semplice correggere la libreria condivisa (così che tutti i software che la utilizzano, si ritrovino con la versione senza la falla), piuttosto che ciascun sviluppatore di ciascun software che ne faccia uso debba aggiornare la propria libreria, ricompilare il software e ridistribuirlo a tutti i vari canali a cui attingono gli utenti finali. Peggio ancora se compilazione e distribuzione vengono eseguite dalle diverse comunità/distribuzioni, come spesso avviene: ti immagini la mole di lavoro?

          • Samael

            Non importa se occorrono o meno i permessi di root, perché questi malware vengono veicolati tramite ingegneria sociale, il che li rende letali per la stragrande maggioranza delle persone.

            E no, il concetto del “usa i permessi di root e quindi può infettare tutti i binari statici” non regge.
            I binari statici non possono tecnicamente essere toccati da questo attacco perché non fanno uso del loader ld-linux.
            Senza contare che lo scenario che dici tu è improponibile su larga scala in quanto non puoi sapere a prescindere quanti e quali eseguibili sono presenti nel sistema operativo.
            Certo, potresti tentare un’infezione di massa andando a patchare tutti i file dello userland, ma essendo statici ti ritroveresti nell’impossibilità di sapere quali API (anche a livello di libc) sono state integrate perché il vantaggio del linking statico è l’indipendenza del singolo eseguibile.
            Poi se il punto del tuo discorso è “tutto è possibile” allora chiudiamola qui, perché a questo punto ti dico che l’unico sistema sicuro è quello spento e fine. Ma questo non vuol dire che dato che la sicurezza assoluta non esiste bisogna usare le peggiori pratiche di deployment.

            E per concludere NO, non è eccessivo dire che il linking dinamico non ha vantaggi. Non ne ha.
            Quello che tu pensi sia un vantaggio, ovvero fornire una sola implementazione di una API per tutti i binari che ne fanno uso, in realtà è uno svantaggio colossale.
            Se da un lato ti permette di patchare al volo la libreria (e non è vero perché ci sono casi di rotture di ABI anche su linking dinamico. OpenSSL insegna.) dall’altro ti espone ad attacchi che vengono veicolati tramite code injection (tipo questo) che possono persino essere fatti da utente normale tramite LD_PRELOAD ed LD_LIBRARY_PATH, e che tramite codice malevolo possono fare privilege escalation.
            E per favore BASTA con la storia del “se la libreria è vulnerabile allora tutti devono ricompilare”.
            Ho già detto che il software linkato staticamente NON linka la libreria ma le funzioni necessarie che essa espone, il che vuol dire che non tutto il software che ne fa uso è a rischio vulnerabilità.
            Tutto questo senza contare che si contano sulle dita di una mano i casi di desktop bucati per vulnerabilità di una libreria, e sono per lo più legati a tecnologie specifiche tipo Flash che sono esposte al web. I desktop come Windows e OSX sono bucati tramite adware, spyware e ransomware veicolati tramite ingegneria sociale.
            Senza contare che usando metodi di sandbox che introducono un set aggiuntivo di privilegi, molti degli attacchi vengono mitigati già in partenza.
            Ad esempio è molto difficile realizzare un attacco di remote code execution in un binario che non ha accesso alla rete.

  • Samael

    OH CASPITA!
    Abbiamo scoperto che questo malware può potenzialmente mettere in ginocchio l’OS A TUTTI I LIVELLI, partendo dal software di terze parti fino allo userland che non riesce a rilevarlo senza usare tool compilati con altre libc.
    CHI L’AVREBBE MAI DETTO! Chi avrebbe mai potuto pensare che si sarebbe potuto fare code injection al loader andando quindi a sostituire le librerie sane con versioni malate?

    Scusate, ma dove sono finiti tutti i sommi esperti che venivano a pontificare sulla sicurezza del linking dinamico rispetto a quello statico?

    • Fighi Blue

      So che il linking dinamico è preferibile per questioni di memoria (ricordo da un libro di stallman che lessi), comunque sarebbe stato problematico questo virus, usare librerie statiche arginava il problema ma non lo risolveva

      • Samael

        No, lo risolveva eccome perché questo virus attacca il loader e la libc, che sono problematiche in quanto condivise e di conseguenza chiamate a runtime.
        Ogni software statico ha una copia delle funzioni necessarie built-in e non viene caricato dal loader ld-linux . so in quanto è autosufficiente, al punto tale che con i software statici è possibile avviare applicazioni a 32-bit su OS a 64-bit privi di librerie di compatibilità a 32-bit.

        • Fighi Blue

          si, ma se io programmatore sviluppo un applicativo con un pc infetto sto di fatto linkando codice malevolo mentre compilo con una libreria statica (mi sembra di aver capito così)

          • Samael

            Sì, ma avrà effetto solo sul tuo binario e su nessun altro.
            Mi spiego:
            nel caso in questione, puoi sfruttare il social engineering (e quindi l’ignoranza dell’utente) per corrompere la libc del sistema ed il loader in modo da rendere vulnerabili TUTTI i binari con linking dinamico dell’OS.

            Nel caso di compilazione statica, anche qualora il tuo software avesse linkato la libc infetta NON potrebbe fare danno altrove, perché ogni binario avrebbe la SUA copia della libc.
            Il che vuol dire che i binari compilati dalla distro sarebbero di fatto indipendenti.
            Per poterli corrompere, dovresti patcharli singolarmente.

          • El Ninho

            Grazie a snappy il virus si propagherà meglio, visto che porta librerie in versioni specifiche per ogni snappy

          • Samael

            Eh? A parte che i bundle sono confinati e quindi per potersi propagare bisogna fare in modo che il virus faccia exploit della sandbox, andando quindi ad aggirare AppArmor. E la cosa è tutt’altro che semplice. Possibile, certo, come qualunque altra cosa; ma comunque molto più complessa di una roba descritta nell’articolo in questione.

            Ed in secondo luogo è tutto il contrario di ciò che dici.
            Il modello centralizzato ATTUALE con una libreria per tutti è quello che rende terribilmente meno sicure le infrastrutture, perché crea quello che nell’ingegneria del software viene definito “single point of failure”.

          • El Ninho

            Sono d’accordo con te, che il linking statico è molto più sicuro del dinamico.
            Ma ho dei seri dubbi sulla sicurezza di questi sistemi tipo snappy, secondo me saranno terreno fertile per nuovi virus, cmq rispetto la tua opinione e di sicuro tu ne capisci molto più di me.

  • DigiDavidex

    Questi Fokémon hanno rotto il…

No more articles