La mia bash è vulnerabile?
Questo semplice comando è un test sufficiente per vedere se la tua versione di bash è vulnerabile:
x = '() {:; }; echo VULNERABILE 'bash -c:
Non è necessario stampare del testo extra per indicare che il comando è stato effettivamente eseguito, perché le versioni patchate di bash riporteranno un avviso quando una variabile al suo avvio l'ambiente contiene codice di exploit per la vulnerabilità corretta.
Su un sistema vulnerabile:
$ x = '() {:;}; echo VULNERABILE 'bash -c: VULNERABILE
Su un sistema patchato:
$ x =' () {:;}; echo VULNERABILE 'bash -c: bash: warning: x: ignora la definizione della funzione trybash: errore durante l'importazione della definizione della funzione per `x'
Per una spiegazione dettagliata di cosa fa e fa non testare e perché, vedere "Altri bug di analisi delle funzioni" di seguito.
Il mio sistema è vulnerabile?
Se la tua bash non è vulnerabile, il tuo sistema non lo è non è vulnerabile.
Se la tua bash è vulnerabile, allora il tuo sistema è vulnerabile in quanto utilizza bash lungo vettori di attacco come script CGI, client DHCP e account SSH limitati. Controlla se / bin / sh è bash o qualche altra shell. La vulnerabilità è in una funzionalità specifica di bash e altre shell come dash e ksh non sono interessate. Puoi testare la shell predefinita eseguendo lo stesso test di cui sopra con sh invece di bash:
x = '() {: ;}; echo VULNERABILE 'sh -c:
- Se vedi un messaggio di errore, il tuo sistema ha una bash patchata e non è vulnerabile.
- Se tu vedi
VULNERABILE , la shell predefinita del tuo sistema è bash e tutti i vettori di attacco sono un problema. - Se non vedi alcun output, la shell predefinita del tuo sistema non è bash e solo parti del tuo sistema che usa bash sono vulnerabili. Controlla:
- Script eseguiti da bash (che iniziano con
#! / Bin / bash , non #! / Bin / sh ) da CGI o da un Client DHCP.
- Account SSH limitati la cui shell è bash.
Come funziona questo test
Esegue il comando bash -c: con il testo letterale () {:;}; echo VULNERABILE impostato come valore della variabile d'ambiente x.
-
Il builtin : esegue nessuna azione; è usato qui dove è richiesto un comando non vuoto.
-
bash -c: crea un'istanza di bash che esegue : ed esce.
Anche questo è sufficiente per consentire l'attivazione della vulnerabilità. Anche se bash viene invocato per eseguire un solo comando (e quel comando è un no-op), legge comunque il suo ambiente e interpreta ogni variabile il cui contenuto inizia con () { come una funzione (in almeno quelli i cui nomi sono nomi di funzione validi) e lo esegue in modo che la funzione venga definita.
L'intento dietro questo comportamento di bash è quello di eseguire solo una definizione di funzione, che rende una funzione disponibile per l'uso ma non in realtà non eseguo il codice al suo interno.
-
() {:;} è la definizione di una funzione che non esegue alcuna azione quando viene chiamata. È necessario uno spazio dopo { in modo che { venga analizzato come un token separato. È necessario un ; o un newline prima del } affinché venga accettato come sintassi corretta.
Vedi 3.3 Funzioni di shell nel Bash Reference Manual per maggiori informazioni sulla sintassi per la definizione delle funzioni di shell in bash. Ma nota che la sintassi usata (e riconosciuta) da bash come una valida funzione di shell esportata la cui definizione dovrebbe essere eseguita è più restrittiva:
- Deve iniziare con la stringa esatta
() { , con esattamente uno spazio tra ) e {.
- E sebbene le funzioni di shell occasionalmente abbiano la loro istruzione composta racchiusa in
() invece di {} , vengono comunque esportate all'interno della sintassi {} . Le variabili i cui contenuti iniziano con () ( invece di () { non testeranno o attiveranno in altro modo la vulnerabilità.
-
bash dovrebbe interrompere l'esecuzione del codice dopo la chiusura di } . Ma (a meno che non sia patchato) non lo fa! Questo è il comportamento sbagliato che costituisce CVE -2014-6271 ("Shellshock").
; termina l'istruzione che definisce la funzione, consentendo la lettura e l'esecuzione del testo successivo come comando separato. E il testo dopo ; non deve essere un'altra definizione di funzione: può essere qualsiasi cosa.
-
In questo test, il comando dopo ; è echo VULNERABLE . Lo spazio iniziale prima di echo non fa nulla ed è presente solo per leggibilità. Il comando code> echo scrive il testo nello standard output. Il comportamento completo di echo è in realtà un po 'complicato, ma qui non è importante: echo VULNERABLE è semplice . Visualizza il testo VULNERABLE.
Poiché echo VULNERABLE viene eseguito solo se bash non ha patch e esegue codice dopo le definizioni di funzione nelle variabili di ambiente, questo (e molti altri test simili ad esso) è un test efficace per verificare se il bash installato è vulnerabile o meno a CVE-2014-6271.
Altri bug di analisi delle funzioni (e perché quel test e quelli simili non li controllano)
La patch che è stata rilasciata al momento della stesura di questo documento, ei comandi descritti e spiegati sopra per controllare la vulnerabilità, si applicano al bug molto grave noto come CVE-2014-6271. Né questa patch né i comandi sopra descritti per il controllo della vulnerabilità si applicano al bug correlato CVE-2014-7169 (né si deve presumere che si applichino a qualsiasi altro bug che potrebbe non essere stato ancora scoperto o divulgato).
Il bug CVE-2014-6271 è nato da una combinazione di due problemi:
- bash accetta definizioni di funzioni in variabili di ambiente arbitrarie, e
- mentre lo fa, bash continua a eseguire qualsiasi codice esistente dopo la parentesi graffa di chiusura (
} ) di una definizione di funzione.
Al momento della stesura di questo documento, la correzione esistente per CVE-2014-6271 che è stata rilasciata (e implementata da molti fornitori a valle), ovvero la correzione che si otterrebbe aggiornando il sistema o applicando la patch esistente manualmente: è una correzione per 2”.
Ma in presenza di altri errori nel codice di bash, 1 è potenzialmente una fonte di molti bug di analisi aggiuntivi. E sappiamo che esiste almeno un altro bug simile, in particolare CVE-2014-7169.
Il comando presentato in questa risposta verifica se oppure no una bash installata è patchata con la correzione esistente (cioè la prima ufficiale) per CVE-2014-6271. Verifica la vulnerabilità a quello specifico bug di analisi: "GNU Bash fino alla 4.3 elabora le stringhe finali dopo le definizioni di funzione nei valori delle variabili di ambiente [...]"
Questo bug specifico è estremamente grave - e la patch disponibile lo lo risolve - mentre CVE-2014-7169 sembra essere meno grave ma è sicuramente ancora motivo di preoccupazione.
Come Stéphane Chazelas ( scopritore del bug di Shellshock) ha recentemente spiegato in una risposta a Quando è avvenuto lo shellshock (CVE -2014-6271) bug introdotto e qual è la patch che lo risolve completamente? su Unix.SE:
C'è una patch che impedisce bash dall'interpretazione di qualsiasi altra cosa oltre alla definizione della funzione contenuta ( https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html), e questo è quello che è stato applicato in tutti gli aggiornamenti di sicurezza dalle varie distribuzioni Linux.
Tuttavia, bash interpreta ancora il codice e qualsiasi bug nell'interprete potrebbe essere sfruttato. Uno di questi bug è già stato trovato (CVE-2014-7169) sebbene il suo impatto sia molto minore. Quindi ci sarà presto un'altra patch.
Ma se questo è l'aspetto dell'exploit ...
Alcune persone , qui e altrove, hanno chiesto perché x = '() {:;}; echo VULNERABILE 'bash -c: la stampa di VULNERABILE (o simile) dovrebbe essere considerata allarmante. E di recente ho visto circolare l'idea sbagliata che poiché devi già avere accesso interattivo alla shell per digitare quel particolare comando e premere invio , Shellshock in qualche modo non deve essere una grave vulnerabilità.
Sebbene alcuni dei sentimenti che ho sentito esprimere - che non dovremmo precipitarci nel panico, che gli utenti desktop dietro i router NAT non dovrebbero mettere le loro vite in attesa per costruire bash dal codice sorgente - sono abbastanza corretti, confusi la vulnerabilità stessa con la possibilità di testarla eseguendo un comando specifico (come il comando presentato qui) è un grave errore.
Il comando fornito in questo post è una risposta alla domanda: "C'è un breve comando per verificare se il mio server è sicuro contro il bug bash di shellshock?" non è una risposta a "Che aspetto ha lo shellshock quando viene usato contro di me da un vero attaccante?" e non è una risposta alla domanda: "Cosa deve fare qualcuno per sfruttare con successo questo bug?" (E anche non è una risposta a "è esiste un semplice comando per dedurre da tutti i fattori tecnici e sociali se sono personalmente ad alto rischio? ")
Quel comando è un test, per vedere se bash eseguirà codice scritto, in un modo particolare, in variabili d'ambiente arbitrarie. La vulnerabilità Shellshock non è x = '() {:;}; echo VULNERABILE 'bash -c: . Invece, quel comando (e altri simili) è una diagnostica per aiutare a determinare se uno è influenzato da Shellshock.
- Shellshock ha conseguenze di vasta portata, anche se è vero che il rischio è quasi certamente minore per gli utenti desktop che non utilizzano server di rete accessibili da remoto. (Quanto meno è qualcosa che non credo sappiamo a questo punto.)
- Al contrario, il comando
x = ' () {:;}; echo VULNERABLE 'bash -c: è del tutto irrilevante tranne per il fatto che è utile per testare Shellshock (in particolare, per CVE-2014-6271).
Per coloro che lo sono interessati, ecco alcune risorse con informazioni sul motivo per cui questo bug è considerato grave e sul perché le variabili di ambiente, in particolare sui server di rete, possono contenere dati non attendibili in grado di sfruttare il bug e causare danni:
Per illustrare ulteriormente la distinzione concettuale qui, si consideri due ipotetici:
-
Immagina se invece di suggerire x = '() {:;}; echo VULNERABLE 'bash -c: come test, avevo suggerito bash --version come test. (Ciò in realtà non sarebbe particolarmente appropriato, perché i fornitori di sistemi operativi spesso eseguono il backport di patch di sicurezza su versioni precedenti del software. Le informazioni sulla versione fornite da un programma possono, su alcuni sistemi, far sembrare che il programma sia vulnerabile, quando in realtà lo è stato patchato.)
Se venisse suggerito il test eseguendo bash --version , nessuno direbbe: "Ma gli aggressori non possono sedersi al mio computer e digitare bash --version , quindi devo stare bene! " Questa è la distinzione tra un test e il problema per cui viene eseguito il test.
-
Immagina se venisse emesso un avviso che suggerisce che la tua auto potrebbe avere qualche problema di sicurezza, come un guasto o uno scoppio dell'airbag in fiamme in caso di collisione, e le dimostrazioni in fabbrica erano state trasmesse in streaming. Nessuno direbbe: "Ma non guiderei o rimorcherei mai accidentalmente la mia macchina per 900 miglia fino alla fabbrica e la caricherò con un costoso manichino da crash e sbatterò contro un muro di cemento. Quindi devo stare bene!" Questa è la distinzione tra un test e il problema per cui viene eseguito il test.