ShellShock: grave (?) vulnerabilità della shell bash

[loric]

Grazie, comunque dal sito di attivissimo:

ShellShock: falla critica in Linux, Mac OS X e altri sistemi operativi basati su Unix | Il Disinformatico

Richiede, appunto, che vi sia un server HTTP accessibile dall'esterno.

Su openSSH il problema si pone quando questo è configurato con la direttiva "ForceCommand" per eseguire un comando arbitrario quando un utente si è già autenticato.

Immaginiamo questo scenario. Ho due utenti. Il primo è pippo, il secondo è pluto. Di pippo io mi fido, quindi lui con la sua password si può collegare al mio server con accesso alla shell (bash). Di pluto mi fido poco, ma mi serve che lui possa collegarsi per eseguire un singolo comando (per mancanza di fantasia diciamo che il comando è rsync) e per questo imposto, limitatamente a lui, la direttiva ForceCommand di sshd. Anche pluto ha ovviamente la sua password.

Se un achero riesce a compromettere l'account di pippo, del bug di bash non se ne fa nulla: ha già accesso libero alla shell.

Se un achero riesce a compromettere l'account di pluto, non ha accesso alla shell e, qualsiasi comando lui scriva sul terminale, viene eseguito solo rsync.

Scrive "W la figa", ma sshd esegue rsync. Scrive "Porca pupazza" e sshd riesegue rsync. Un po' frustrante. Ecco però che interviene il baco. Quando ssh esegue il comando specificato in "ForceCommand" lo fa con "bash -c" (vedi mio messaggio di sopra... vabbe', con $SHELL -c, ma se la shell è bash il risultato è quello). E fin qui non succederebbe nulla, se non fosse che il comando specificato dall'utente (o dall'achero) viene passato a bash -c attraverso una variabile d'ambiente ("$SSH_ORIGINAL_COMMAND"). Quindi se il tipo ha scritto qualcosa come '() { :;}; bash -l', ecco che, automagicamente, l'achero ottiene una shell di bash, di fatto bypassando la direttiva "ForceCommand" ed è pertanto libero di eseguire qualsiasi comando come pluto (salvo l'uso intelligente dei permessi dei file da parte del sysadmin).

Modificato 25 Settembre 2014 da loric

[loric]

Sono riuscito a riprodurre il bug con una particolare configurazione di DHCPclient ed un DHCPACK farlocco. In altre parole senza aver neanche bisogno di accedere alla macchina via ssh. Considerando che detta macchina ha su Mandriva e Mandriva non è più supportato (chi faceva la distro è fallito), comincio ad essere un po' preoccupato.

[jeby]

Insomma basta il server web attivo

[loric]

Insomma basta il server web attivo

No, nel caso di cui ho scritto non c'era alcun server web attivo, il DHCP è quello che serve per dare l'indirizzo IP all'interfaccia di rete.

[loric]

Bene, compilato ed installato bash 4.3 (patch level 25) anche su mandriva. Dovrei essere salvo

[Ospite]

Considerando che quanto scrivete per me è arabo, io uso Linux Ubuntu aggiornato puntualmente, rischio qualcosa?

[loric]

Considerando che quanto scrivete per me è arabo, io uso Linux Ubuntu aggiornato puntualmente, rischio qualcosa?

Probabilmente no.

Apri un terminale, incolla i comandi postati da jeby all'inizio della discussione e vedi se il sistema è vulnerabile.

- - - - - - - - - - AGGIUNTA al messaggio già esistente - - - - - - - - - -

La patch di bash a quanto pare non è perfetta.

$ env -i X='() { (a)=<\' bash -c '/etc/passwd cat'

D'oh...

[jeby]

Probabilmente no.

Apri un terminale, incolla i comandi postati da jeby all'inizio della discussione e vedi se il sistema è vulnerabile.

- - - - - - - - - - AGGIUNTA al messaggio già esistente - - - - - - - - - -

La patch di bash a quanto pare non è perfetta.

$ env -i X='() { (a)=<\' bash -c '/etc/passwd cat'

D'oh...

mi sa che c'è già in giro la patch della patch...

EDIT: su raspbian (Debian Wheezy) bash version version 4.2.37(1)-release-(arm-unknown-linux-gnueabihf) se faccio girare il comando che hai scritto tu dice:

env -i X='() { (a)=<\' bash -c '/etc/passwd cat'

bash: /etc/passwd: Permission denied

Modificato 27 Settembre 2014 da jeby

[loric]

Confermo, patch uscita ieri sera