Ci risiamo e stavolta è BASHBleed

[LoryOne]

Interessante articolo di PuntoInformatico.
Mi sono un po informatico in giro e che ti trovo ?
--- Prima come verificare se si è potenzialmente a rischio, ossia:

se digitando dal vs. prompt bash
$ env x='() { :;}; echo Vulnerabile' bash -c "echo Questo è un test"
ricavate
Vulnerabile
Questo è un test

allora siete potenzialmente a rischio e fareste bene a patchare il prima possibile.
Dico "potenzialmente" perchè la vera minaccia è l'esecuzione di comandi da remoto direttamente sul server, sempre che esso fornisca un servizio web in ascolto.
Ebbene, sembrerebbe che manipolando opportunamente la stringa dello user-agent, si possa eseguire un comando bash come se ci si trovasse ad operare sul server. Certo la scrittura di files potrebbe essere difficoltosa, ma la lettura del contenuto di quelli presenti potrebbe essere molto agevole, sebbene pericolosa in egual modo.
Anche i router potrebbero essere presi di mira, soprattutto se consentissero l'amministrazione remota e non solo sulla classica porta 80/8080/443.

---Poi in che modo, ossia:
GET <hostname>/cgi-bin/<cgi> con User-Agent: () { :;}; /bin/bash -c "'+cmd+'"' ecc
Quel cmd può essere cmd&&cmd&&cmd&&...
Come si evince dall'esempio, è il componente CGI ad essere preso di mira, quindi senza scomodare Nessus, una veloce passata con nikto potrebbe rivelare diversi altri percorsi sfruttabili.
Ma perchè CGI ?
Ogniqualvolta vi collegate ad un sito web, il web server ricava tutta una serie di informazioni legate all'header trasmesso dal client e le immette in variabili che possono essere nuovamente elaborate attraverso script server-side e poi inviati nella pagina di ritorno.
Un esempio delle diverse variabili ricavate e ritrasmesse lo potete trovare qui: http://browserspy.dk/headers.php
Il web server, però, spesso si appoggia alla componente CGI per ricavare tali variabili ed il parser di BASH espleta il suo lavoro allo stesso modo con cui ricava le variabili d'ambiente, esegue i vari comandi e sequenzia le istruzioni presenti in uno script bash.
Se si prende in considerazione lo user-agent trasmesso nell'header di una richiesta GET, la variabile ad esso relativa è HTTP_USER_AGENT.
Se allo user-agent trasmesso si fanno precedere (), poi { :;}, ecco che ad HTTP_USER_AGENT viene assegnata una funzione e non una variabile, cioè:

HTTP_USER_AGENT() {
    :;
};

La funzione così ricavata è si una funzione (sintatticamente in linguaggio C), ma vuota: Il problema che costituisce il baco (gravissimo come gravissime possono essere le conseguenze) è che dopo quell'ultimo ";" alla funzione viene aggiunto il comando da eseguire che BASH non si rifiuta di prendere in considerazione, anzi...
Come avrete sicuramente intuito, non è tanto l'URL che viene richiesto e tantomeno il solo user-agent ad essere affetto da tale baco, bensì qualunque variabile presa in carico dal parser di BASH via CGI
...e questo ci rimanda all'inizio del test in locale sul server.
Quanti web server hanno Apache installato, ad esempio ?
Quanti web server utilizzano php, ad esempio ?
Ma soprattutto (e non è solo questione di Linux) Quanti web server, anche se non consentono l'esecuzione di cgi script nell'apposito percorso, ricavano le variabili associate all'header in quel modo ?