Come funziona il test di vulnerabilità Shellshock aggiornato per CVE-2014-7169?

Comprendo il test originale per CVE-2014-6271, che era:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Ma sono confuso dal test aggiornato e dall'output corrispondente per CVE-2014-7169:

$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Thu 25 Sep 2014 08:50:18 BST

Qualcuno potrebbe spiegare brevemente cosa sta succedendo qui e come ignora la patch per CVE-2014-6271?

Sto scavando un po 'intorno alle reti da quando ho pubblicato questa domanda per la prima volta.

Secondo lo scopritore originale del bug, bash prima della patch CVE-2014-6271 ha importato una funzione come:

foo=() {
  code
}

sostituendo il segno di uguale con uno spazio e interpretandolo ... il che significava che era possibile interpretare oltre la definizione della funzione.

La patch per CVE-2014-6271 ha introdotto una modalità speciale della funzione parse_and_execute () per limitare la valutazione alla definizione della funzione e non oltre.

Tuttavia, come spiegato in questo thread , la variabile di ambiente appositamente predisposta del test di vulnerabilità CVE-2014-7169 è progettata per 1) confondere il parser fino alla morte 2) lasciare gli scarti nel buffer 3) cambiare completamente ciò che fa il comando bash originale quando si combina con gli scarti già nel buffer.

Quindi per dissezionare la variabile d'ambiente:

X='() { (a)=>\'

• Il parser analizzerà () { (a)=>\. Nota che \fa parte della stringa; esso è non fuoriuscendo il trascinamento singolo preventivo.

() {

• Il parser identifica questo come una definizione di funzione.

(a)=

• Questo confonde il parser a morte.

>\

• Il parser lascia gli ultimi due caratteri seduti nel buffer.

>\[NEWLINE]

• Ad un certo punto prima shdell'esecuzione del comando, viene inserita una nuova riga nel buffer.

>\[NEWLINE]echo date

• Quando shviene chiamato (che in questo caso è probabilmente un link simbolico per bash), aggiunge i suoi argomenti di comando echo dateai caratteri già esistenti nel buffer.

>echo date

• Dato che la nuova riga è sfuggita, bash analizzerà il buffer di >echo date, che ha lo stesso effetto di date > echo. Viene echocreato un file denominato e lo stdout del datecomando viene reindirizzato in esso.

; cat echo

• Il secondo comando visualizza semplicemente il contenuto del file appena creato.

Non ti dà un output pulito, ma dimostra il bug.

Senza alcun bug, la variabile d'ambiente Xdovrebbe essere ignorata, bash dovrebbe essere eseguito echo datee cat dovrebbe lamentarsi che non esiste un file chiamato echo. Ad esempio, considera come si comporta il trattino:

me@myserver$ rm -f echo && env -i  X='() { (a)=>\' dash -c 'echo date'; cat echo
date
cat: echo: No such file or directory

Non ripeterò l'output che mostrerai nella tua domanda, e non farò finta di capire come funziona, ma bash è in esecuzione datee inserirà l'output in un file chiamato 'echo'. Puoi giocare con alternative per dateconvincerti che questo è utilizzabile e pericoloso.