ShellShock

È stato scoperto un baco serio in bash, che consente, in determinate situazioni, ad un attaccante di eseguire programmi arbitrari sul computer della vittima (RCE, Remote Code Execution).

bash è probabilmente la shell più diffusa tra i sistemi *NIX, in quanto è la shell di default della gran parte delle distribuzioni Linux ed è la shell utilizzata da OSX.

La shell è il programma che permette all’utente di eseguire altri programmi, interagire con il file system e il sistema operativo ed eseguire altre azioni in relazione all’ambiente e al tipo di shell. Oltre a bash, gli ambienti *NIX hanno, tra le altre, zsh, csh, sh. La shell di Windows è Explorer.exe, prima di Windows c’era COMMAND.COM, che alcuni sostituivano con 4DOS.

Il metodo veloce per scoprire se una bash è vulnerabile è eseguire questo comando:

env x='() { :;}; echo vulnerabile' bash -c "echo io sono un test"

Se bash non ritorna un warning, ma scrive semplicemente vulnerabile e poi io sono un test, la bash è vulnerabile.

Innanzi tutto: non è vero che ogni computer che ha bash a bordo è vulnerabile per il fatto di avere bash a bordo.

Perché un computer sia vulnerabile dall’esterno bisogna riuscire a convincere bash ad eseguire un comando arbitrario deciso dall’attaccante, la qual cosa può avvenire in vari modi.

Accesso interattivo. Ovviamente chi ha un accesso interattivo ad un sistema in cui è possibile eseguire una copia non patchata di bash può creare degli script sul sistema che lo espongono ulteriormente. Se è vero che non c’è aumento di privilegi, è anche vero che un attaccante con accesso interattivo potrebbe collocare degli script in directory non opportunamente protette per minare ulteriormente la sicurezza del sistema. Diversamente, chi ha già un accesso interattivo ha già un accesso shell, quindi…

ssh. La shell viene eseguita solamente dopo un login avvenuto con successo, quindi solo chi ha un account ssh (o una chiave valida per entrare) può sfruttare la vulnerabilità. A parte il caso dell’accesso interattivo, ssh può essere sfruttato per eseguire altri comandi come, ad esempio, rsync o il client di mysql; anche in questi casi si applica la vulnerabilità.

Client DHCP. Un computer su cui gira bash che utilizza DHCP per configurare la rete potrebbe essere vulnerabile. Se questo computer usa degli script shell per la configurazione (i sistemi Linux fanno così), un server DHCP opportunamente modificato potrebbe convincere un client ad eseguire comandi arbitrari.

Apache. Se sono abilitati gli script CGI oppure se interpreti come PHP sono eseguiti in CGI, la macchina è vulnerabile. Questo articolo di RedHat contiene alcune regole per mod_security per bloccare tentativi di exploit.

NAS. I NAS che hanno distribuzioni Linux a bordo potrebbero essere vulnerabili se utilizzano bash come shell.

Altri programmi potrebbero eseguire la shell passando parametri che non vengono verificati o sanificati, quindi l’elenco potrebbe essere lunghissimo. Questo è il motivo per cui il baco di bash è particolarmente insidioso ed è il caso di aggiornare quanto prima i propri sistemi.

In tema di aggiornamento, come è successo per Heartbleed, i sistemi vecchi non più manutenuti potrebbero non ricevere mai una patch.

Il NIST ha assegnato a questa vulnerabilità il codice CVE-2014-6271, la cui patch è risultata incompleta e, quindi ha assegnato il nuovo codice CVE-2014-7169 per il baco della versione di bash patchato solamente dopo CVE-2014-6271. È, quindi, possibile che le distribuzioni Linux rilascino due patch per bash. Ovviamente vale la pena aggiornare quanto prima e alla peggio aggiornare due volte.

Una dettagliata informazione tecnica sul baco di bash la si trova qui.