Il recente rilascio, lo scorso 21 Aprile, di Ubuntu 16.04, al quale abbiamo dedicato moltissimi articoli qui su lffl, ha introdotto moltissime nuove feature, fra cui l’ormai noto Snap package format (supporto per l’installazione del software dei pacchetti SNAP).

Proprio questa nuova soluzione, che per ora affiancherà il sistema di Debian (i pacchetti .deb) con la prospettiva di sostituirlo in futuro, ha sollevato alcuni dubbi e uno degli sviluppatori di CoreOS ha affermato che non è sicura.

Ma andiamo con ordine, cerchiamo di capire la differenza tra i pacchetti .deb e la nuova soluzione.

La differenza principale tra i due sistemi è che Debian usa una gerarchia di dipendenze (un pacchetto può dichiarare di aver bisogno di un altro pacchetto il quale a sua volta potrebbe aver bisogno di altri pacchetti, finché tutte le richieste non sono soddisfatte), mentre un pacchetto SNAP contiene tutti file necessari per far funzionare un programma. La comodità è eviente: si puo’ scaricare un solo pacchetto invece che una moltitudine di pacchetti, e senza dover risolvere le dipendenze. Inoltre, essendo tutto pacchettizzato, il manutentore del pacchetto si deve preoccupare solo delle librerie incluse nel pacchetto e non affidarsi a qualcun altro.

Ubutnu 16.04

Alcuni dubbi…

La prima cosa che viene da chiedersi è la seguente: chi si occupa dello SNAP ha le competenze e il tempo di gestire e mettere in sicurezza tutte le librerie in esso contenute? In un sistema a dipendenze, proprio perché c’è qualcun altro che segue le librerie, è più snello pacchettizzare un software e il lavoro fatto su tali librerie diventa intrinsecamente disponibile per tutti i pacchetti che ne dipendono.

La falla evidenziata da Matthew Garrett

Matthew Garrett ha spiegato in un articolo molto preciso, lo trovate qui,  che la sicurezza viene completamente saltata nel caso di utilizzo del server X (ovvero quasi sempre perchè il server X è lo strumento con cui si ha una interfaccia grafica in linux). Questo perché X è un programma vecchio, concepito una trentina di anni fa e che  permette a qualsiasi applicazione grafica di intercettare ogni tipo di input.

Garrett è riuscito effettivamente a utilizzare questa falla, pertanto quanto afferma è stato verificato da lui stesso.

La soluzione più ovvia sarebbe non usare il server X. Da anni si propongono alternative, ma finora la tecnologia ben conosciuta del server ha sempre avuto la meglio, rendendo impossibile la sostituzione, soprattutto per un utilizzo quotidiano.

In realtà pensandoci un paio di alternative sono già previste in Ubuntu, mi riferisco al progetto MIR, già usato in Ubuntu Touch, e al progetto Wayland che continua a fare progressi: entrambi prevedono che ogni finestra sia ‘sigillata’, e quindi che i flussi di input e output non siano intercettabili, andando cosi’ a risolvere il problema alla radice.

Ad oggi i pacchetti SNAP non sono sicuri, e installare un pacchetto SNAP da una fonte sconosciuta potrebbe essere dannoso.

[Fonte]

  • Ilgard

    La falla in sé è sfruttabile da chiunque, non è una vulnerabilità di snap, ma di X.
    Il problema, come detto anche nell’articolo originale, è che Snap viene spacciato per sicuro ma è sicuro solo con un server grafico moderno, altrimenti ha le stesse vulnerabilità di altri tipi di pacchetto.

    ps: installare qualunque cosa da fonti sconosciute è insicuro, a prescindere dal tipo di pacchetto.
    pps: spero vivamente che X venga mandato in pensione il più presto possibile.

    • Maddo

      Che alla fine non è neanche il suo scopo, quello di fornire un livello di sicurezza in più. Per quello c’è già AppArmor e SELinux in casi estremi. Snappy, come Nix e altri progetti simili nascono per risolvere dependency hell e problemi di configurazioni di sistema app-specific, che tra i tanti problemi da essi derivati ci sono ANCHE problemi di sicurezza(i famosi privilege escalation exploits).

  • loki

    io non capisco sta ossessione per il server grafico che legge tutto che hanno garrett e quell’altro venditore di aspirapolvere di grasslin: non era un problema 20 anni fa e non è un problema neppure ora. è sufficiente piantarla di eseguire ogni porcata si trovi in rete, problema risolto

    • Ilgard

      X, come server grafico, è un rottame. Era nato per altro, è stato adattato per uno scopo a cui sopperisce decentemente. È ora di abbandonarlo.

      • loki

        non ho niente in contrario ad abbandonare xorg, a patto che con ciò che lo sostituirà possa essere in grado di fare come minimo tutto quello che riesco a fare ora: stesso desktop, stessi applicativi, stesso hardware e stessi driver, il tutto come minimo senza perdite in performance, stabilità e funzionalità. una volta raggiunti questi presupposti, ogni miglioria è ben accetta. in mancanza di questi presupposti, non se ne parla neppure lontanamente

        • Ilgard

          Il problema non è superare xorg, ma convincere gli sviluppatori a cambiare server grafico.

        • Samael

          Quindi Wayland rientra tranquillamente in questo esempio, dato che ciò che ha eliminato da X11 sono cose che tu non hai citato.

          • loki

            mah, vediamo un po’:

            1) attualmente nessun desktop è realmente usabile con wayland: gnome funzionicchia con qualche pezzo che crasha, kde parte a pezzi. gli altri desktop per ovvie ragioni non li prendo in considerazione;
            2) xwayland continua ad essere un layer che ammazza le performance, quando non mostra solo una finestra nera;
            3) driver, ma questo lo sappiamo già;

            4 extra) obbligo di usare systemd

            sì dai, funziona quasi come xorg…

          • Samael

            1) Non è un problema di Wayland, ma di supporto dei singoli toolkit e window manager.
            Dire che è colpa di Wayland è come dire che è colpa di Windows se Adobe Reader è un colabrodo.

            2) XWayland è un layer che si dovrebbe usare solo in casi estremi con app vecchie che fanno uso di libX11. Per il resto vale quanto detto nel punto 1.

            3) I driver di Wayland non esistono.
            Wayland non usa driver proxy come faceva Xorg, ma sfrutta direttamente i driver del kernel ed il framebuffer offerto dal KMS.
            I driver servono ad XWayland, e sono gli stessi driver xf86 che usi oggi.

            4) Non mi risulta, dato che Wayland non ha bisogno di logind.
            Dire che Wayland dipende da systemd è come dire che X11 dipende da ConsoleKit.

            Niente di ciò che hai citato dipende da Wayland.

          • loki

            1) non ho mica detto che è colpa di wayland, ho detto che nessun desktop al giorno d’oggi (come negli ultimi 6 anni) è realmente usabile su wayland;
            2) i primi che mi vengono in mente sono firefox o libreoffice, due programmini che non interessano a nessuno, e hanno seri problemi di rendering;

            3) so benissimo come funzionano i driver, e so benissimo anche quanto funzionano bene. gli unici accettabili sono intel e vedremo nei prossimi anni amdgpu. radeon e soprattutto nouveau sono dei bei giochini, ma sono tutto tranne che affidabili. nvidia ha messo uno sgangherato driver per il modesetting, ma senza framebuffer non serve a una beneamata ceppa;
            4) posso avviare qualunque desktop su xorg senza usare consolekit o simili, persino gnome

            è ovvio che tutto questo non dipende da wayland stesso, il mio punto fin dall’inizio era il flusso di lavoro di una persona. poi può scoppiare di vantaggi rispetto a xorg, ma se non posso fare altro che fissare il terminale di weston aspettando che il driver nouveau freezi tutto, questi vantaggi contano meno di niente

          • Samael

            E allora se sai bene che tutto ciò che hai scritto non dipende da Wayland, tutto il discorso non ha senso.
            Il flusso di lavoro è una questione del tutto relativa, perché nemmeno con Xorg si è mai stati a livelli adeguati.
            Basti pensare a chi ha una configurazione dual-GPU che non ha ancora niente di realmente paragonabile ad Optimus.
            O basti pensare che Firefox per anni ha avuto problemi di rendering su Xorg, poi fixati in upstream dopo molto tempo e molte lamentele.

            E proprio riguardo la questione Firefox e LibreOffice, qui i problemi sono che entrambi non usano widget toolkit veri e propri, ma hanno mostri interni (XUL in Firefox) che cercano di emulare l’ambiente nativo. E lo fanno nella peggior maniera possibile. Non c’entra niente Wayland col fatto che questi software siano ammassi di spazzatura.

            Per la questione driver, si sa che nvidia è nota per aver sempre voluto evitare di usare troppe API del kernel e AMD è un cancro che non andrebbe nemmeno considerata quando si acquista un prodotto.
            Ma rimane il fatto che questo non ha nulla a che vedere con Wayland. Neanche solo lontanamente.

            Per la questione ConsoleKit, GNOME ecc: che cosa c’entra con Wayland?
            Se GNOME o KDE hanno deciso di migrare a systemd è un problema LORO. Non è un problema del display grafico, che non ha niente a che vedere con logind, che è un session manager usato dai DM e dai WM.

          • loki

            un disco rotto. ti sei fissato su sta cosa della colpa che fin dall’inizio ti ho detto che non mi interessa e che il punto è ciò che puoi fare con uno e ciò che puoi fare con l’altro. sai come sarà il prossimo scambio di battute?
            tu: “non è colpa di wayland, è colpa del resto”
            io: “per la 100esima volta: non me ne frega niente di chi è la colpa, mi importa che con uno riesco a fare n cose e con l’altro n-100. sapere che non è colpa del protocollo grafico mi fa funzionare quelle cose? NO!”
            tu: “ma non è colpa di wayland!”
            io: “arrivederci e buona domenica”
            tu: “ma non è colpa di wayland!”

          • Samael

            Non è un disco rotto. Il punto è che stai semplicemente mischiando capre e cavoli per cercare di darti ragione da solo.
            Wayland in sé ti permette di fare tutto ciò che normalmente faresti con Xorg.
            Tuttavia se la singola applicazione non funziona, lamentati con chi la sviluppa. Fine della storia. Tutto il resto sono cose che lasciano il tempo che trovano.

            Senza contare che hai persino mosso accuse precise a Wayland, tipo l’essere dipendente da systemd. Accuse che non stavano né in cielo e né in terra.
            Quello che stai facendo si chiama FUD.

          • loki

            giuro che è l’ultima volta che ti rispondo seriamente perchè non ne posso più di sentirti ripetere la stessa cosa. non mi interessa di chi è la colpa, mi interessa cosa io utente sono in grado di fare.
            ti da fastidio sentir dire che l’esperienza desktop con wayland è ‘na ciofeca rispetto a xorg? dimostrami che non è così o fattene una ragione, di chiunque sia la colpa

            non ce la fai proprio a leggere questa cosa senza ripetere per la millesima volta “ma non è colpa di wayland”? e allora sforzati, perchè in tutta la discussione non ho detto una sola volta che è colpa di wayland e il tuo tentativo continuo di far credere questo comincia a farmi pensare tu abbia un po’ la coda di paglia

            faccio fud? è un po’ difficile fare fud dicendo cose dimostrabili da chiunque

            al limite rileggi la frase (che dovrebbe essere) in grassetto e poi tutta la conversazione tra una settimana, forse allora avrai le idee meno annebbiate

          • Samael

            Dimostrabili da chiunque? Non direi proprio.
            E se proprio vuoi che ti “dimostri” il contrario, allora ti dico che c’è tanta gente su reddit che dice che Wayland lo usa ogni giorno senza grossi problemi.
            E allora? La loro esperienza vale meno della tua? Entrambi all’atto pratico non abbiamo dimostrato nulla. Solo voci di corridoio…
            Ed è normale: niente di quanto detto da te è verificabile in senso oggettivo perché la tua esperienza non è quella di un altro.
            Ed ecco perché in nessuno dei miei post ho fatto leva su questo argomento; perché è una cosa troppo soggettiva da usare per dare giudizi su un software.

            Di sicuro è dimostrabile che Wayland non dipende da systemd. E su questa accusa falsa da te fatta vedo che stai sorvolando bellamente…

    • Samael

      Quando è nato X11 tutto ciò non era un problema perché all’epoca non esisteva neanche lontanamente l’idea di attaccare con remote code execution, eh.

      Mettere a paragone gli anni passati con quelli attuali per far finta che i problemi non esistano, direi che è un tantino pretestuoso.

      • loki

        se riesci ad eseguire codice da remoto puoi fare qualunque tipo di danno, a prescindere dal server grafico (sai cosa puoi fare con LD_PRELOAD, vero?)

        • Samael

          Conosco abbastanza bene LD_PRELOAD ed LD_LIBRARY_PATH e la loro idea di code injection ed infatti è proprio per quello che io sono contro il linking dinamico.

    • snizzo

      “quell’altro venditore di aspirapolvere di grasslin” hahaha hai vinto tutto 🙂

  • Aury88

    nessun sistema è assolutamente sicuro…il problema è semmai quanto insicuro un sistema sia.
    il confronto mi sembra un trovare il pelo nell’uovo quando i sistemi attuali hanno la trave nell’occhio…pur con questo difetto dovuto ad x (sfruttabile anche dall’attuale sistema di pacchettizzazione), rimane il vantaggio dei sistemi confinati ed in grado di scrivere unicamente nella propria cartella mentre allo stato attuale, x o non x, ogni programma può fare quello che vuole (leggere e scrivere) in tutte le cartelle dello stesso utente che lancia il suddetto programma.
    la storia della dipendenza aggiornata centralmente è vera, ma rimane il fatto che, mentre adesso un bug in una dipendenza può comportare danni ad un po’ tutto il sistema (fino al livello di root se quella dipendenza è usata da un programma lanciato da root) con gli snappy i danni rimarrebbero confinati al più alle cartelle di quei programmi che sfruttano quella particolare versione di quella particolare dipendenza.
    poi c’è la cosuccia che adesso il programmatore teoricamente con gli snappy ha meno lavoro da fare non dovendo più provare/compilare il proprio programma sulle varie distro/DE per vedere se i vari ambienti sono dotati di dipendenze sfruttabili/adeguate dal proprio programma…dovendo lavorare una sola volta per tutti confido che occupi una piccola parte di questo tempo risparmiato per testare e aggiornare le dipendenze all’interno dello snappy.

  • Samael

    chi si occupa dello SNAP
    ha le competenze e il tempo di gestire e mettere in sicurezza tutte le
    librerie in esso contenute?

    Stai implicando che quelli che fanno i pacchetti nelle distro abbiano sempre avuto tali competente. E così non è…
    Ti potrei fare l’esempio di Aegisub su ArchLinux che quando ancora faceva uso di wxgtk 2.9 smise di funzionare perché l’imbecille che pacchettizzò il toolkit, aggiornò quest’ultimo senza curarsi di verificare che TUTTI i software da esso dipendenti funzionassero. E quando lo si fece notare in un bug report disse che non avrebbe fatto downgrade perché le policy di Arch erano chiare: solo pacchetti bleeding edge.
    Oppure vogliamo parlare della storia della presunta backdoor nell’OpenSSL fornito da Debian, e che intaccava potenzialmente mezzo repository, a causa della dipendenza a ragnatele?
    Con un sistema a la snappy non sarebbe successo praticamente nulla. E spiegherò dopo il perché.

    Prima vorrei capire una cosa: perché questa smania di mettere in sicurezza le librerie? Pensi veramente che TUTTE le vulnerabilità trovate SIANO sfruttabili? Se è così, allora NeXSTEP e Mac OS X sarebbero dovuti diventare devi veri porcai di attacchi. Eppure, al di là dei ransomware o di roba che fa uso dell’ingegneria sociale non è che si vedano cose che già non si vedano altrove.
    Le vulnerabilità sono sfruttabili SOLO qualora ci sia un vettore utile per l’attacco.
    Mi spiego meglio: vi ricordate di ShellShock? La falla ULTRA-MEGA-IPER-PERICOLOSA che avrebbe dovuto sterminare Linux e portare all’apocalisse? Ecco, proprio quella.
    Sapete cos’è successo a causa di quella falla? Ehm…. aspetta…. ah sì, c’era quella storia… uhm, vediamo… com’è che si diceva…. ah giusto: NIENTE.
    L’unica cosa che si è ottenuta era una piccola botnet che ha cercato di bucare il sito della difesa americano senza riuscirci. E sapete come si è arrivati a costruire quella piccola botnet? Sfruttando TELNET. Il che la dice lunga sui problemi reali che aveva quel reparto IT.
    Questo perché? Perché ShellShock in sé non faceva priviledge escalation, quindi non era tecnicamente possibile prendere il controllo dei sistemi. Se a questo ci aggiungi che in molti casi, la shell in cui si penetrava era quella di un container LXC, allora beh… lascio a voi le conclusioni.
    Difatti al di là degli allarmismi e dei finti PoC, come l’avvio da root di un server DHCP in una Slackware tramite l’uso di sudo impostato con NOPASSWD, non poteva succedere niente.
    Ed onestamente il tizio che mostrò il PoC con sudo senza password era un vero genio della lampada che meritava l’oscar come miglior ritardato del pianeta.
    ShellShock comunque rimaneva importante perché se accompagnato da un’altra vulnerabilità che avesse fatto PE allora le cose sarebbero potute diventare un po’ più serie.

    Fatta la premessa, torniamo a Snappy.
    Ti faccio un esempio: se lo Snap è confinato da AppArmor ed è progettato per non avere accesso alla rete, come può una vulnerabilità sfruttabile da remoto diventare pericolosa?
    L’idea dietro Snappy ed i sistemi moderni di containerizzazione sta proprio in questo: smetterla di continuare a ricorrere la sicurezza ASSOLUTA che non serve a niente (tutti i software hanno bug, e patch o no altre falle ci saranno sempre), ma di raggiungere una sicurezza RELATIVA, andando a MITIGARE quelle che sono le vulnerabilità rendendole all’atto pratico inefficaci.

    In un sistema a dipendenze, proprio perché
    c’è qualcun altro che segue le librerie, è più snello pacchettizzare un
    software e il lavoro fatto su tali librerie diventa intrinsecamente
    disponibile per tutti i pacchetti che ne dipendono.

    E non è così. Questa è la favoletta che ci piace sempre raccontarci, salvo il fatto che quando hai a che fare con roba come OpenSSL che a volte cambia API pure nelle minor release ti ritrovi a dover ricompilare tutti i software che ne dipendono, a prescindere dall’uso o meno del linking dinamico.

No more articles