Home > GNU/Linux, Sicurezza e GNU/Linux > Sicurezza e GNU/Linux (parte 3): vulnerabilità/2

Sicurezza e GNU/Linux (parte 3): vulnerabilità/2

"Non sono cattiva, è che mi disegnano così"

Vulnerabilità “by design”

E’ piuttosto difficile definire una vulnerabilità “by design”, cioè un “errore di progettazione”. Prendendo alla lettera l’espressione, praticamente tutti i programmi e i sistemi operativi, se considerati dal punto di vista della sicurezza, contengono svariati “errori” di progettazione. In realtà questo dipende molto da due principi della sicurezza informatica: a) la sicurezza è inversamente proporzionale alla facilità d’uso; b) la sicurezza è un concetto relativo.

Un esempio lampante del primo principio è l’User Access Control di Windows (Vista e Seven). L’UAC si manifesta all’utente con quella finestra che, soprattutto su Windows Vista, chiede in continuazione all’utente l’autorizzazione a fare qualcosa. E’ interessante studiare la differenza tra l’UAC e SUDO (o SU) su Unix.

Quando accediamo a Windows Vista con l’utente predefinito, questo utente è in realtà amministratore. Il sistema però gli toglie gran parte dei permessi, riducendolo ad un utente normale. Quando un programma utente chiede di fare qualcosa che richiede i permessi di amministrazione, l’utente viene avvertito di questo tentativo e chiede l’autorizzazione. In quel momento l’utente ri-diventa amministratore a tutti gli effetti.

E’ facile comprendere perché questo sistema sia insicuro: basta infatti aggirare l’UAC, in modi che sono peraltro non troppo complicati e già implementati in alcuni malware, per diventare amministratori e quindi fare quella che, in gergo, è chiamata una privilege escalation.

Tuttavia Microsoft ha preferito fare così, piuttosto che costringere l’utente a inserire una password ma anche per minimizzare l’impatto in termini di incompatibilità con i programmi studiati per le precedenti versioni di Windows.

SUDO e SU, invece, hanno un funzionamento opposto. L’utente di default, in quasi tutte le distro GNU/Linux e gli altri sistemi Unix, è un utente senza privilegi. Se si tenta di fare qualcosa che richiede i permessi amministrativi, semplicemente non si può fare. Non c’è quindi qualcosa che può essere “disattivato” per ottenere l’accesso completo al sistema.

E’ vero che esistono configurazioni insicure di SUDO (attraverso il suo file /etc/sudoers) ma queste vanno esplicitamente introdotte dall’utente amministratore.

Tuttavia non dobbiamo credere di essere totalmente al sicuro: anche su GNU/Linux, a volte, si scende a compromessi sulla sicurezza, sebbene molto meno che in altri sistemi e in genere cercando di minimizzare gli effetti collaterali. Il modo più comune di ottenere una privilege escalation su un sistema Unix è attaccare alcuni particolari eseguibili. Ma partiamo dall’inizio: in effetti, i sistemi Unix “classici” hanno una grande falla by design: l’utente root ha tutti i privilegi. Su Windows, invece, i privilegi sono “spezzettati” e possono essere assegnati ad utenti diversi. Questo problema, in GNU/Linux (ma anche in altri sistemi Unix), è affrontato in due modi: il primo, il più classico e usato, è chiamato separazione dei privilegi e  lo si realizza in genere sfruttando i permessi dei gruppi, il secondo sono le capabilities (un meccanismo molto simile a quello adottato da Windows). Appuntatevi queste due cose perché sono molto interessanti e dedicherò per intero il prossimo post per spiegarle.

Ma torniamo ai nostri eseguibili “pericolosi”. Alcuni programmi hanno bisogno di girare come root perché, ad esempio, devono accedere alle porte di rete “basse” (fino alla 1024) che sono riservate al sistema. Questi stessi programmi però devono essere eseguibili anche per l’utente normale. Per questo motivo vengono assegnati all’utente root come proprietario e poi dotati di un flag particolare, detto SUID, che permette loro di girare con i privilegi del loro proprietario (che come detto è l’utente root) anche quando vengono lanciati dall’utente normale. Uno di questi eseguibili è proprio SUDO, che altro non è che un programma che “trasmette” il suo privilegio di root ad un altro programma.

ls -l /usr/bin/sudo
-rwsr-xr-x 2 root root 127668 2011-01-19 19:01 /usr/bin/sudo

Guardate la prima tripletta di privilegi, quelli del proprietario del file (che è root): sono “rws”. Normalmente dovrebbe essere rwx (cioè: Read, Write, eXecute) ma la “s” indica proprio il bit suid.

Provate ad aprire un terminale e digitare:

sudo su

non inserite la password, ma aprite un altro terminale e digitate

ps aux | grep sudo

Otterrete qualcosa del genere:

root  5213  0.0  0.1  10588  2416 pts/2  S+  19:23  0:00 sudo su

come vedete, SUDO viene eseguito da root, anche se lo abbiamo lanciato come normale utente e non abbiamo ancora inserito nessuna password. E’ una vera e propria privilege escalation autorizzata! Tranquilli, non è un errore di progettazione, semplicemente SUDO serve davvero a diventare root.

Ora, a parte il caso di SUDO che fa semplicemente il suo lavoro, è chiaro che i programmi con il bit SUID, se infettati, avranno i privilegi di root e pieno accesso al sistema anche se lanciati dall’utente standard (e, cosa più terribile, da qualsiasi utente standard). Con tutto ciò che ne consegue in termini di sicurezza. Si tenga conto però che un malware locale che volesse infettare un eseguibile settato con SUID, dovrebbe avere già di suo i privilegi di root, visto che questi eseguibili sono nelle directory /bin, /usr/bin, /sbin e /usr/sbin.

Questo fatto riduce notevolmente la possibilità di un attacco su questi eseguibili. In altre parole, si dice in gergo che si riduce la superficie di attacco.

Per capire cosa significhi, pensiamo alla balistica: avete mai visto un film con una bella sparatoria? Forse avrete notato che chi spara si butta pancia a terra, oppure se non può farlo si mette di profilo. Questo perché una persona a terra o di profilo offre una superficie molto minore alle pallottole in arrivo e diventa un bersaglio più difficile da colpire.

Lo stesso concetto si applica alla sicurezza informatica: un programma insicuro, pieno di falle, ma che non può essere realmente attaccato perché “protetto” dal sistema o perché non comunica con l’esterno, o per qualsiasi altro motivo è, a tutti gli effetti, un programma sicuro (o almeno poco insicuro).

Rimane però il problema di un malware che, da remoto, attacca uno di questi eseguibili o qualsiasi programma di rete che gira come root, attraverso una connessione (pensiamo ad esempio a Samba). Questo problema viene spesso risolto con un meccanismo che spiegheremo in seguito, che è anch’esso una forma di separazione dei privilegi e consiste nell’esporre alla connessione un processo figlio con privilegi minimi.

Vulnerabilità per configurazione debole

Capita a molti utenti GNU/Linux alle prime armi di ritrovarsi cartelle zeppe di eseguibili per Windows .exe che, se analizzati con un antivirus, contengono qualche tipo di malware. Come è possibile?

Il motivo è che questi utenti hanno condiviso la cartella con Samba (che è l’implementazione libera del protocollo SMB usato da Windows per la condivisione dei file e delle stampanti) lasciando il permesso di scrittura a chiunque. E questo, si direbbe, è un errore dell’utente. Ma c’è di più. La configurazione standard di Samba suppone che l’utente lo usi in una rete locale (anche perché serve proprio a questo). Le reti locali di solito accedono ad Internet tramite un router e i router possiedono praticamente sempre un firewall che rende invisibile all’esterno quanto c’è all’interno della rete LAN. I pc portatili, però, sono fatti per muoversi e molti utenti li usano anche con chiavette GPRS o UMTS oppure collegati al cellulare. In questa situazione, il firewall non c’è, e pertanto si è esposti direttamente alla rete. Pertanto chiunque, dall’esterno, potrà depositare nelle cartelle dell’utente sprovveduto ciò che gli pare, o leggere i file condivisi e persino cancellarli.

Vedremo nelle prossime puntate quando e come usare un firewall, ma anticipo subito che esso non è, come molti ritengono, una specie di secondo antivirus che protegge dai cattivi hacker (e poi ricordiamoci che hacker vuol dire programmatore, non delinquente informatico).

  1. ripperhack
    8 aprile 2011 alle 7:17

    Complimenti per il post, chiaro e semplice

    ottimo lavoro

  2. Lightcastle
    8 aprile 2011 alle 11:39

    Ottima “rubrica” questa sulla sicurezza!
    Mi hai fatto imparare qualcosa di nuovo.

  3. 8 aprile 2011 alle 14:00

    davvero un bella rubrica, molto interessante😀

  4. 8 aprile 2011 alle 18:31

    Ciao,
    indipendentemente dall’argomento … che comunque in questo caso mi interessa molto, è davvero un piacere leggerti, quindi … tanto di cappello, attendo il seguito della guida.

    Grazie🙂

  5. PerryGi
    8 aprile 2011 alle 20:52

    Davvero ottimo, chiaro ed esplicativo, non vedo l’ora di leggere il prossimo capitolo.

  6. threshold
    8 aprile 2011 alle 20:55

    Mi unisco alle lodi. Davvero una bella serie di articoli.

  7. 8 aprile 2011 alle 22:03

    Me lo sono proprio goduto. Grazie!

  8. Luigi
    9 aprile 2011 alle 0:20

    Scusa Guiodic ma Jessica Rabbit cosa c’entra?

  9. aury88
    9 aprile 2011 alle 8:23

    Complimenti Guiodic, proprio un interessantissimo post.

  10. Cippaciong
    9 aprile 2011 alle 11:03

    @ Luigi:
    Jessica Rabbit credo sia stata messa per la frase che c’è scritta sotto e che se non ricordo male dice nel film “Chi ha incastrato Roger Rabbit” ed è un gioco di parole che gira attorno al fatto che design, nell’articolo inteso come programmazione/progettazione lì si rifersica a design come disegno.

    @Guido:
    Ottimo articolo come sempre. Sono particolarmente interessato alla parte relativa alla configurazione del firewall, spero che venga largamente approfondita!

    • 9 aprile 2011 alle 17:48

      sì esatto il motivo è questo, anche se il gioco di parole funziona solo in italiano: in inglese, infatti, disegnare si dice to draw non to design (che invece significa progettare).

  11. 10 aprile 2011 alle 21:34

    non mi è chiara una cosa riguardo alla differenza fra UAC e sudo: io su windows 7 ho creato un nuovo utente senza privilegi di amministratore, quindi la schermata di uac, se cerco di fare qualcosa che necessita di privilegi, mi chiede la password di un utente amministratore per proseguire. A questo punto il funzionamento non è lo stesso di sudo? La differenza è solo nel fatto che l’utente senza privilegi non viene creato di default in windows, o ci sono altre differenze strutturali che creano problemi anche con la soluzione che ho adottato io?

    • 11 aprile 2011 alle 10:01

      @Athos: come l’hai configurato tu è simile al comportamento di su e sudo, o per certi versi è simile a policykit. Però non è la configurazione di default.

  12. Judas
    11 aprile 2011 alle 0:46

    Provate ad aprire un terminale e digitare:

    sudo su
    non inserite la password, ma aprite un altro terminale e digitate

    ps aux | grep sudo
    Otterrete qualcosa del genere:

    root 5213 0.0 0.1 10588 2416 pts/2 S+ 19:23 0:00 sudo su

    come vedete, SUDO viene eseguito da root, anche se lo abbiamo lanciato come normale utente e non abbiamo ancora inserito nessuna password. E’ una vera e propria privilege escalation autorizzata! Tranquilli, non è un errore di progettazione, semplicemente SUDO serve davvero a diventare root.

    Per favore guido mi puoi chiarire meglio questo punto? Perchè devo aprire i due terminali?
    Grazie

    • 24 giugno 2011 alle 13:43

      Per favore guido mi puoi chiarire meglio questo punto? Perchè devo aprire i due terminali?

      perché il primo è occupato dal comando sudo su in attesa. Se vuoi puoi aprire un’altra tab, è lo stesso.
      Comunque sarebbe bastato provare e ti saresti risposto da solo🙂

  1. 18 maggio 2011 alle 18:34
  2. 6 dicembre 2011 alle 23:02

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: