Come progettersi dallo Shellshock Bash bug

Shell Shocker
Shell Shocker

Introduzione

Il 24 Settembre 2014 è stata scoperta una vulnerabilità della GNU Bash molto grave, nominata Shellshock o “Bash Bug”. In parole povere la vulnerabilità consente ad un aggressore di eseguire del codice arbitrario (sotto certe condizioni) semplicemente passando una stringa di codice successivamente ad una assegnazione di una variabile d’ambiente.

Considerando la grande diffusione della shell Bash nei sistemi Linux, BSD, Max OS X sono moltissimi i computer vulnerabili. Tutte le versioni della Bash senza patch tra la 1.14 e la 4.3 (vale a dire tutte le versioni fino ad oggi) sono a rischio vulnerabilità.

Maggiori dettagli sul bug possono essere trovati nei bollettini ufficiali CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187.

Poichè la vulnerabilità ShellShock è molto diffusa, ancora più del bug OpenSSL Heartbleed, e facile da sfruttare, si raccomanda vivamente di verificare se i propri sistemi sono vulnerabili e in caso applicare le patch quanto prima.

Verifica della vulnerabilità

In ogni sistema che esegue la Bash è possibile la vulnerabilità a Shellshock semplicemente eseguendo questo comando:

env VAR='() { :;}; echo Bash is vulnerable!’ bash -c “echo Bash Test”

La porzione di codice scritta in neretto rappresenta il codice che un aggressore potrebbe iniettare; un codice arbitario subito dopo una funzione di definizione di una viariabile d’ambiente. Se l’output risulta come il seguente allora la versione di Bash è vulnerabile:

Bash is vulnerable!
Bash Test

In caso contrario se la versione della Bash non è vulnerabile la stringa “Bash is vulnerabile” non dovrebbe apparire e al massimo si dovrebbe vedere un messaggio del tipo:

bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR’
Bash Test

Come risolvere la vunlnerabilità

Il modo più semplice per risolvere la vulnerabilità è quello di usare il sistema di default di gestione degli aggiornamenti nelle varie distribuzioni di Linux incluso Ubuntu, Debian, CentOS, Red Hat e Fedora.

Ubuntu/Debian: APT-GET

L’aggiornamento della bash all’ultima versione è possibile con il comando:

apt-get update && apt-get install –only-upgrade bash

Al termine testare nuovamente la vulnerabilità.

CentOS/Red Hat/Fedora: YUM

L’aggiornamento della bash all’ultima versione è possibile con il comando:

yum update bash

Al termine testare nuovamente la vulnerabilità.

Conclusione

Assicuratevi di applicare la patch a tutti i server e client che gestite.

vSphere Client could not connect to “……..”. An unknown connection error occurred.

La virtualizzazione semplifica e risolve molti problemi comuni alle strutture fisiche, ma a volte le cose non vanno per il verso giusto.

Oggi mi è successo questo strano caso quando ho provato a connettermi tramite il client vSphere ad un host con su VMware ESXi 5.5.0:

vSphere Client could not connect to
vSphere Client could not connect to “….”

 

e le uniche informazioni contenute nel log erano:

...
 at System.Net.HttpWebRequest.GetResponse()
 at VirtualInfrastructure.Utils.WebDownload.GetResponse()
 at VirtualInfrastructure.Utils.WebDownload.get_ResponseStream()
 at VirtualInfrastructure.Utils.WebQuery.Request(String url, Nullable`1 timeoutSecs)
 System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 37.187.25.142:443
...
 at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)

Fortunamente nel host era abilitato l’SSH a cui ho potuto collegarmi senza problemi. Una volta dentro anche il comando esxcli dava problemi:

~ # esxcli
Connect to localhost failed: Connection failure

Dopo vari tentativi invani l’unica cosa da fare è stata quella di riavviare i servizi tramite il comando:

~ # services.sh restart
Running xorg stop
Running sfcbd stop
This operation is not supported.
Please use /etc/init.d/sfcbd-watchdog stop
Running snmpd stop
root: snmpd is not running.
Running wsman stop
Stopping openwsmand
....
....

al termine della procedura tutto è tornato a funzionare alla normalità.

P.S.: Le macchine virtuali non hanno subito nessun problema durante il restart dei servizi.