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

Capisco il test originale per CVE-2014-6271, che è stato:

$ 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 brevemente spiegare cosa sta succedendo qui e come esclude la patch per CVE-2014-6271?

  • Accesso ai sisthemes di produzione per non sys-admins
  • Devo acquistare il certificato SSL per il dominio principale?
  • Come posso aggiornare apache in Ubuntu 14.04 LTS
  • Il ricordo ipmitool
  • Proteggere per installare i servizi DHCP e gateway sulla stessa macchina?
  • Quanto è sicuro per proteggere una chiave ssh senza passphrase utilizzando l'opzione "command" nel file authorized_keys?
  • Quanto serio è un problema sono le reti multi-homed?
  • IIS 7 Che cosa significa il tipo di accesso di credenziali del path fisico?
  • 2 Solutions collect form web for “Come funziona il test di vulnerabilità Shellshock aggiornato per CVE-2014-7169?”

    Ho scavato intorno i web per un po 'da quando ho pubblicato questa domanda.

    Secondo lo scopritore originale del bug, bash prima della patch CVE-2014-6271 importto una function come:

     foo=() { code } 

    sostituendo il segno uguale con uno spazio e interpretandolo … il che significava l'interpretazione oltre la definizione delle funzioni.

    La patch per CVE-2014-6271 ha introdotto una modalità speciale della function parse_and_execute () per limitare la valutazione alla definizione delle funzioni 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 a morte 2) lasciare gli scarti nel buffer 3) modificare completamente ciò che il command bash basha quando si combina con gli scarti già nel buffer.

    Così per dissecciare la variabile d'ambiente:

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

    • Il parser analizzerà () { (a)=>\ . Si noti che \ è parte della string; non è fuggire dalla singola citazione che trascina.

    () {

    • Il parser lo identifica come una definizione di function.

    (a)=

    • Ciò confonde il parser a morte.

    >\

    • Il parser lascia i due caratteri finali seduti nel buffer.

    >\[NEWLINE]

    • A un certo punto prima che il command sh venga eseguito, una nuova row viene inserita nel buffer.

    >\[NEWLINE]echo date

    • Quando viene chiamato sh (che è probabilmente un simbolo di bash in questo caso), aggiunge i suoi argomenti di command, echo date , ai caratteri già esistenti nel buffer.

    >echo date

    • Dato che la nuova row viene fatta, bash analizza il buffer come >echo date , che ha lo stesso effetto della date > echo . Viene creato un file denominato echo e viene reindirizzato lo stdout del command date .

    ; cat echo

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

    Non ti dà una bella output pulita, ma dimostra il bug.

    Senza alcun errore, la variabile di ambiente X dovrebbe essere ignorata, bash dovrebbe eseguire la echo date , e il gatto dovrebbe lamentarsi che non esiste alcun file denominato echo. Ad esempio, considerare come il comportmento si comport:

     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 mostri nella tua domanda e non farò finta di capire come funziona, ma bash sta eseguendo la date e mettendo l'output in un file chiamato 'echo'. Puoi giocare con alternative fino ad date per convincerti che questo è utile e pericoloso.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.