Stato
Apple ha rilasciato le correzioni di sicurezza di Bash per Shellshock e le relative vulnerabilità come " Aggiornamento OS X bash 1.0 ". Possono essere installati tramite il normale aggiornamento del sistema per le persone che utilizzano OS X Mountain Lion v10.8.5 o OS X Mavericks v10.9.5 (sono inclusi nell'aggiornamento della sicurezza 2014-005 ) e possono anche essere installati manualmente. Le correzioni Apple ufficiali sono disponibili anche per OS X Lion v10.7.5 e OS X Lion Server v10.7.5 ma sono disponibili solo tramite download manuale. Le correzioni di sicurezza sono disponibili tramite diversi URL in base alla versione del sistema operativo:
(Se vengono rilasciate nuove patch, inseriscile qui ma ti preghiamo di conservare anche quelle esistenti come riferimento.)
La patch Apple si prende cura di Shellshock e di molte altre vulnerabilità e va bene per la maggior parte delle persone. tl; dr la gente può smettere di leggere qui.
TUTTAVIA, l'attenzione attirata da Bash dal bug Shellshock ha indotto molti ricercatori a dare un'occhiata dura a Bash e continuano a essere scoperte sempre più vulnerabilità (difficili da sfruttare). Se sei molto preoccupato per la sicurezza (perché forse stai eseguendo OS X Server per ospitare un sito Web disponibile pubblicamente), allora potresti voler (provare a) tenere il passo con le vulnerabilità e le patch mentre continuano a scorrere compilando tu stesso. Altrimenti, non preoccuparti.
Cerca Apple per rilasciare un altro aggiornamento per colpire un po 'di tempo in futuro quando la polvere si depositerà sulla ricerca di ulteriori vulnerabilità.
È disponibile un set ufficiale di patch di bash per bash 3.2, patch 52, 53 e 54 (che corrispondono alle patch 25, 26 e 27 di Bash 4.3) che risolvono sia CVE-2014-6271 che CVE-2014-7169, così come il "Game over" visualizzato di seguito. Questo è stato testato da me ( @alblue ) e il post è stato aggiornato di conseguenza (e quindi sono stati apportati ulteriori aggiornamenti: vedere la revisione 41 per il post che si interrompe alla patch 54).
Molte vulnerabilità aggiuntive sono state segnalate contro bash. Secondo il post di Michal Zalewski se hai la patch 54 (e presumibilmente la patch ufficiale di Apple) "non ha senso ossessionare lo stato di questi singoli bug, perché non dovrebbero più rappresentare un rischio per la sicurezza:"
CVE-2014-6271 - RCE originale trovato da Stephane. Risolto da bash43-025 e corrispondenti voci del 24 settembre per altre versioni.
CVE-2014-7169 - bug di creazione file / consumo token trovato da Tavis. Risolto da bash43-026 & co (26 set)
CVE-2014-7186 - un incidente qui-doc 10+ probabilmente senza rischi per secondi trovato da Florian e Todd. Risolto da bash43-028 & co (1 ottobre).
CVE-2014-7187 - un off-by-one non-crash, probabilmente senza rischi al secondo trovato da Florian. Risolto da bash43-028 & co (1 ottobre).
CVE-2014-6277 - problema di memoria non inizializzato, quasi sicuramente RCE trovato da Michal Zalewski. Nessuna patch specifica ancora.
CVE-2014-6278 - Iniezione comando RCE trovata da Michal Zalewski. Nessuna patch specifica ancora.
Diventa piuttosto confuso. Fortunatamente Chet Ramey, il manutentore ufficiale di bash, ha pubblicato un CVE per mappare le patch . Il suo post fa riferimento alle patch per bash 4.3, io (@OldPro) le ho tradotte in patch per bash 3.2, che è ciò che è applicabile a OS X. Inoltre, da questo post ha rilasciato la patch 57, quindi l'ho aggiunto di seguito:
bash32-052 CVE-2014-6271 2014-09-24
bash32-053 CVE-2014-7169 2014-09-26
bash32-054 exported function namespace change 2014-09-27 ("Game Over")
bash32-055 CVE-2014-7186/CVE-2014-7187 2014-10-01
bash32-056 CVE-2014-6277 2014-10-02
bash32-057 CVE-2014-6278 2014-10-05
Vedi il post di David A. Wheeler per una sequenza temporale e maggiori dettagli.
@alblue ha pubblicato le istruzioni di build tramite la patch 55. I (@OldPro) ho aggiunto le patch 56 e 57 alle istruzioni ma non l'ho testato.
Test per la vulnerabilità originale
È possibile determinare se si è vulnerabili al problema originale in CVE-2014-6271 eseguendo questo test:
$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello
L'output di cui sopra è un esempio di una bashversione non vulnerabile . Se vedi la parola vulnerablenell'output di quel comando, sei bashvulnerabile e dovresti aggiornarlo. Di seguito è una versione vulnerabile di OS X 10.8.5:
Test per la nuova vulnerabilità
C'è stato un aggiornamento al post originale e Bash 3.2.52 (1) è ancora vulnerabile a una variazione della vulnerabilità, definita in CVE-2014-7169
$ rm -f echo
$ 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
L'output di cui sopra è un esempio di una bashversione vulnerabile . Se vedi una data nell'output di quel comando, sei bashvulnerabile.
Disabilitazione delle funzioni di importazione automatica per impedire "Game Over"
I ricercatori hanno notato, senza classificarlo come una vulnerabilità, che uno script potrebbe dirottare una funzione in una subshell usando le funzioni di importazione automatica:
$ env ls="() { echo 'Game Over'; }" bash -c ls
Game over
Il codice sopra riportato su un sistema interessato verrà visualizzato al Game Overposto dell'elenco di directory che ti aspetteresti ls. Ovviamente, echo 'Game Over'potrebbe essere sostituito da qualsiasi codice nefasto che desideri. Questo divenne noto come bug "Game Over".
Prima della disponibilità della patch 54, sia NetBSD che FreeBSD disabilitavano automaticamente le funzioni bash di importazione automatica, in parte per impedire "Game Over" ma principalmente per contenere ulteriori errori nel parser (come CVE-2014-7169 ) così come erano continuando a essere scoperto e aggiunto un nuovo flag della riga di comando--import-functionsper riattivare il vecchio comportamento predefinito. Io (@alblue) ho preparato una patch (contro la 3.2.53) da usare per gli altri se vogliono adottare anche questo comportamento e l'ho inclusa di seguito. Per impostazione predefinita, questa patch non è abilitata nello script di compilazione di seguito. Io (@OldPro) credo che questa patch non sia più necessaria o una buona idea, perché rompe la compatibilità con le versioni precedenti e le vulnerabilità contro cui è protetta sono molto ben affrontate dalla patch 54 e dalle patch precedenti, e abilitando questa patch non ufficiale si impedisce l'applicazione di patch future .
(Nota per gli editor delle domande; per favore non abilitarlo per impostazione predefinita, in quanto si tratta di una patch non ufficiale.)
a0c5c4d66742fddd0a35001cb91798a5fbf8a2f5 import_functions.patch
La patch può essere abilitata eseguendo export ADD_IMPORT_FUNCTIONS_PATCH=YESprima di eseguire la build. Notare che abilitando questa patch si disabiliteranno la patch 54 e eventuali patch future poiché non è possibile garantire che le patch future siano compatibili con la patch non ufficiale.
Apple Patch ha una vulnerabilità legata al Game Over, una sorta di
Come sottolineato da @ake_____ su Twitter, la patch ufficiale di Apple è ancora vulnerabile all'ambiente che blocca gli eseguibili:
$ env '__BASH_FUNC<ls>()'="() { echo Game Over; }" bash -c ls
Game Over
Gli utenti dovrebbero decidere da soli quanto sia importante. Io (@OldPro) penso che non ci sia nulla di cui preoccuparsi perché non esiste un exploit noto per questo comportamento (non è stato nemmeno assegnato un identificatore CVE) perché in generale gli attaccanti remoti senza privilegi non possono impostare il nome di una variabile di ambiente e gli attaccanti con privilegi non possono usalo per ottenere i privilegi che non hanno già (almeno non senza sfruttare una vulnerabilità aggiuntiva).
Per fornire un piccolo background, bash consente di definire funzioni e inoltre consente di esportare tali funzioni in sottoshell tramite il export -fcomando. Questo veniva implementato creando una variabile d'ambiente con lo stesso nome della funzione con il suo valore impostato sulla definizione della funzione. Così
$ ls () { echo 'Game Over'; }
$ export -f ls
$ echo $ls
Game Over
Ciò è accaduto perché ha export -f lscreato una variabile di ambiente denominata ls. La vulnerabilità "Game Over" era che si poteva creare direttamente questa variabile d'ambiente senza dover prima definire la funzione, il che significava che se si potesse iniettare il nome della variabile giusta si potrebbe dirottare un comando. Apple ha provato a risolvere questo problema rendendo difficile la creazione di una variabile con il nome giusto. La patch 54 ufficiale di bash rende in realtà impossibile creare una variabile con il nome giusto usando nomi di variabili che includono %quale carattere non è permesso in un nome di variabile, inserendo effettivamente le definizioni delle funzioni esportate in un diverso spazio dei nomi riservato.
Se nessuna delle precedenti ha senso per te, non preoccuparti. Per ora stai bene con la patch Apple.
File binari di sistema
OS X 10.9.5 (l'ultima versione stabile al momento) viene fornita con Bash v3.2.51:
$ bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
Puoi ottenere e ricompilare Bash come segue , a condizione che tu abbia installato Xcode (e che tu abbia eseguito xcodebuildalmeno una volta prima di accettare la licenza):
$ # If you want to disable auto-imported functions, uncomment the following
$ # export ADD_IMPORT_FUNCTIONS_PATCH=YES
$ mkdir bash-fix
$ cd bash-fix
$ curl https://opensource.apple.com/tarballs/bash/bash-92.tar.gz | tar zxf -
$ cd bash-92/bash-3.2
$ curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 | patch -p0
$ curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-053 | patch -p0
$ # See note above about ADD_IMPORT_FUNCTIONS_PATCH
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] && curl http://alblue.bandlem.com/import_functions.patch | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-054 | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-055 | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-056 | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-057 | patch -p0
$ cd ..
$ # Note: DO NOT ADD SUDO TO XCODEBUILD HERE
$ xcodebuild
$ build/Release/bash --version # GNU bash, version 3.2.57-release
$ build/Release/sh --version # GNU bash, version 3.2.57-release
$ sudo cp /bin/bash /bin/bash.old
$ sudo cp /bin/sh /bin/sh.old
$ sudo cp build/Release/bash /bin
$ sudo cp build/Release/sh /bin
(Nota: puoi eseguirlo copiando e incollando il blocco di codice sopra, andando su Terminale e quindi eseguendolo pbpaste | cut -c 2- | sh. Fai sempre attenzione quando esegui script casuali da Internet però ...)
Successivamente, la versione di Bash dovrebbe essere v3.2.57:
$ bash --version
GNU bash, version 3.2.57-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
Per motivi di sicurezza e dopo i test, ti consiglio di utilizzare chmod -xle versioni precedenti per assicurarti che non vengano riutilizzate o di spostarle in un sito di backup.
$ sudo chmod a-x /bin/bash.old /bin/sh.old
Altre risposte hanno soluzioni per chi utilizza MacPorts o Homebrew; questi non risolvono il problema, installano solo versioni aggiuntive di Bash. Si prega di vedere quelle risposte se si desidera aggiornare quelle in particolare.
Grazie
Grazie a Chet, che si occupa di bash e ha reso disponibili queste patch. Grazie a tutti gli altri che hanno commentato questo e migliorato nel tempo.
Ora Apple ha rilasciato la vera correzione, anche se questo potrebbe essere ancora utile. Poiché hanno rilasciato solo una correzione per Lion e versioni successive e la patch ufficiale fornisce GNU bash, versione 3.2.53 (1)-release (x86_64-apple-darwin13), tuttavia, il bug di Game over è ancora piuttosto vulnerabile. A questo punto, ricostruire la tua versione di Bash su 3.2.57 è probabilmente più sicuro che fare affidamento sulla patch di Apple, a meno che tu non lo faccia in modo sbagliato.
