Rischio di aggiungere all'heap di domande relative a "Shellshock" ...
La patch Shellshock impedisce l'esecuzione di codice arbitrario dopo le definizioni di funzione nelle variabili di ambiente. Ad esempio, ecco cosa fa una versione con patch di Bash quando si tenta di sfruttare il buco:
$ env foo='() { :;}; echo derp' bash -c 'echo herp'
bash: foo: ignoring function definition attempt
bash: error importing function definition for 'foo'
herp
Questo è ancora consentito dalla progettazione:
$ env foo='() { echo derp; }' bash -c foo
derp
Ma se la definizione della funzione attraverso l'ambiente è possibile, allora chiunque abbia la possibilità di modificare l'ambiente può sostituire i comandi con codice arbitrario (assumendo che lo script di destinazione non specifichi i comandi per il percorso assoluto):
$ env ls='() { echo derp; }' bash -c ls
derp
Mentre la patch Shellshock impedisce cose come l'attacco dell'header HTTP User-Agent, dove la variabile d'ambiente qualsiasi può essere usata per eseguire il codice, non fa nulla per impedire di ridefinire i comandi esistenti.
Un attacco simile è già possibile senza ereditarietà delle funzioni, modificando PATH in modo che faccia riferimento a una directory contenente eseguibili arbitrariamente denominati, ma tale scenario richiede l'accesso al filesystem. Questo non lo fa.
La domanda, quindi: la possibilità di ridefinire i comandi attraverso l'ambiente conta come una vulnerabilità? Esiste una situazione comune in cui potrebbe essere sfruttata a scopi nefandi? (Ad esempio, Git / Mercurial su SSH, Gitolite ...)