Domanda Qual è la vulnerabilità di bash CVE-2014-6271 (Shellshock) e come risolverlo?


Recentemente, ci sono state notizie in giro per "CVE-2014-6271" (Vedi USN-2362-1), che è una vulnerabilità in Bash. Come faccio a sapere se sono interessato da questo, come posso ripararlo e perché dovrei preoccuparmi?

Questo è stato progettato come risposta canonica per questa vulnerabilità, a causa della sua portata e gravità.


140
2017-09-24 21:48


origine


"come lo aggiusto?" -> basta eseguire il tuo gestore aggiornamento! Davvero, Ubuntu rilascia aggiornamenti di sicurezza, c'è un team dedicato alla sicurezza. Per favore non pubblicare risposte su come costruire Bash dalla fonte!; è inutilmente complicato e difficile mantenere il tuo sistema in futuro. - gertvdijk
Inoltre, anche il CVE aggiuntivo per la correzione incompleta. CVE-2014-7169 - gertvdijk
per favore fare posta risposte su come costruire dalla fonte. Sia che debbano o meno, alcune persone hanno server Ubuntu antichi, e costruire dalla fonte potrebbe essere la loro unica opzione. - GaryO
oops, scusate mi sono appena accorto di aver messo bash al posto del trattino nel test. Non importa, va bene. - Matt H
Leggere: oss-sec: Re: CVE-2014-6271: esecuzione di codice in modalità remota tramite bash. Il bug di Bash non è stato ancora risolto - blade19899


risposte:


Cos'è Bash?

Bash è la shell interattiva predefinita in Ubuntu. Quando si interfaccia il terminale (tramite l'emulatore di terminale, su un tty o ssh), si stanno generalmente digitando comandi che bash leggerà ed eseguirà. Anche se non usi affatto il terminale, hai ancora Bash.

Su Ubuntu, /bin/sh non è bash (è un trattino). Solo bash è interessato da questa vulnerabilità.

Come mi influenza l'exploit?

Bash e il sistema operativo tengono traccia di un insieme di variabili ambientali che descrive l'utente attualmente connesso, dove cercare i programmi sul disco fisso e altre funzioni simili. Creando una variabile di ambiente con una struttura specifica, un utente malintenzionato potrebbe essere in grado di eseguire il codice al successivo avvio di Bash.

L'utente malintenzionato può impostare la variabile di ambiente in più modi:

  • Connessione remota a un servizio come SSH con una configurazione specifica come git su ssh. Come avverte Mitre, l'uso di sshd ForceCommand l'opzione è un vettore di attacco. Gli account la cui shell non è bash non sono interessati.
  • Ti coinvolge nell'impostare la variabile d'ambiente.
  • Causando un altro programma per impostare una variabile di ambiente per avere quel valore creato. Ad esempio, potresti avere un server web e uno script che devono impostare una variabile di ambiente con contenuto utente specifico. Anche se quello script crea il suo, e non tocca altre variabili d'ambiente, è sufficiente. Una singola variabile d'ambiente con qualsiasi nome e valore elaborato è sufficiente perché l'exploit abbia successo.
  • Altri modi che non ho menzionato qui.

Una volta impostata questa variabile, la volta successiva bash si apre per qualunque motivo, verrà eseguito il codice del tuo aggressore. Questo è particolarmente spaventoso con sudo -s, in quanto genera bash come superutente (una regola utente amministrativa che ha pieno controllo dei dati e dei programmi del tuo computer). Anche se avvii solo bash come utente standard, i file di quell'utente possono essere cancellati.

È importante notare che anche se non si usa bash da soli, molti programmi genereranno bash da soli come parte della loro operazione. Anche in questo caso, sei vulnerabile. Tuttavia, Ubuntu /bin/sh non è bash, quindi sono interessati solo i programmi che invocano esplicitamente bash e non la shell di scripting predefinita.

Secondo Mitre:

i vettori che coinvolgono la funzione ForceCommand in sshd OpenSSH, i moduli mod_cgi e mod_cgid nel server HTTP Apache, gli script eseguiti da client DHCP non specificati e altre situazioni in cui l'impostazione dell'ambiente avviene attraverso un limite di privilegi dall'esecuzione di Bash.

Sono vulnerabile?

Usa dpkg per verificare la versione del pacchetto installato:

dpkg -s bash | grep Version

Questo cercherà informazioni sul tuo bash pacchetto e filtrare l'output per mostrare solo la versione. Le versioni fisse sono 4.3-7ubuntu1.4, 4.2-2ubuntu2.5, e 4.1-2ubuntu3.4.

Ad esempio, vedo:

wlan1-loopback% dpkg -s bash | grep Version
Version: 4.3-7ubuntu1.4

e posso determinare che non sono vulnerabile.

Come posso aggiornare?

Il gestore aggiornamenti standard ti offrirà questo aggiornamento. Questo è un esempio lampante di come gli aggiornamenti di sicurezza siano importanti, indipendentemente dal sistema operativo utilizzato o da quanto è ben gestito.

Il Bollettino USN afferma che sono state rilasciate nuove versioni per Ubuntu 14.04 Trusty Tahr, 12.04 Precise Pangolin e 10.04 Lucid Lynx. Se non si è in una di queste versioni LTS, ma si trovano in una versione abbastanza recente, molto probabilmente si sarà in grado di trovare un pacchetto patchato.

Per prima cosa, controlla se tu

Se sei vulnerabile, dovresti prima prendere i nuovi elenchi di pacchetti:

sudo apt-get update && sudo apt-get install bash

Il primo comando si assicura di avere l'ultima lista di pacchetti che include la versione fissa, e il secondo comando installa la versione più recente (fissa) di bash.

Mentre il bug sembra entrare in gioco solo quando bash viene generato, è comunque una buona idea riavviare immediatamente se possibile.


127
2017-09-24 21:48



Scusate, sei vulnerabile. La patch originale non risolve l'intero problema. Vedere cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169 AFAIAA, c'è al momento no correzione disponibile pubblicamente. Vedi per es. people.canonical.com/~ubuntu-security/cve/pkg/bash.html - Mormegil
@ hexafraction Dove leggi che 12.10 riceve un aggiornamento per questo? Io non la penso così, 12.10, 13.04, 13.10 sono molto di fine vita! E anche, i repository di backport sono non utilizzato per gli aggiornamenti di sicurezza. - gertvdijk
@hexafraction No, loro no! Questo è il punto di essere End-of-Life: nessun supporto più. - gertvdijk
@ MichaelHärtl Se sei su Ubuntu 12.10, puoi scaricare la versione 12.04 di bash da packages.ubuntu.com/precise/bash e installarlo manualmente. - David
La correzione per CVE-2014-7169 è disponibile nel gestore aggiornamenti (per me). - Calmarius


Ha rubato questo cft over a Hacker News. Se hai problemi con i tuoi repository come me (Odroid-XU), allora questo dovrebbe funzionare bene se vuoi patch / build dal sorgente.

TMPDIR=/tmp/bash-src
mkdir $TMPDIR
cd $TMPDIR
#download bash
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 1 999); do 
  wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i
  if [[ $? -ne "0" ]]; then
    MAX=$(expr $i - 1)
    break;
  fi
done
tar zxf bash-4.3.tar.gz 
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 1 $MAX);do
  echo apply patch bash43-$i
  patch -p0 < ../bash43-$i
done
#build and install
./configure && make
sudo make install
cd ../..
rm -r $TMPDIR

Quindi esegui:

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

E se ottieni:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Allora sei tutto a posto!


AVVERTIMENTO: make install install bash in /usr/local/bin, così /bin/bash non è modificato e può essere invocato dal ricciolo !!


27
2017-09-25 02:30



Ecco come costruire bash 3.2 con la patch su debian lenny: gist.github.com/mattwhite/86de50d30134129e44ef - Matt White
-1. Non c'è bisogno di costruire dalla fonte. Ubuntu ha una patch di sicurezza nei repository. Se hai "problemi con il tuo repository", risolvi quello invece. Probabilmente sarai vulnerabile in molti altri modi se non ricevi aggiornamenti di sicurezza! - gertvdijk
@Matt White Grazie! Mi hai appena salvato un paio d'ore :) - Florian Fida
@FlorianFida Questo è AskUbuntu! Ci si aspetta che tutti in questo sito pubblichino le risposte nell'ambito di utilizzo di Ubuntu. - gertvdijk
@ MichaelHärtl 12,10 è fine vita. Non riceve più alcun aggiornamento di sicurezza da molto tempo. Aggiornamento !!! - gertvdijk


Ud B B Bud B B B Bud B B Bud B Bud B B Bud Bud B B Bud Bud B B Bud Bud B Bud Bud B Bud Bud B B Bud B B B B B B B B B B B B B B B B B B B B B B B tutte Budud B Budud B Budud B Budud B Budud B Bud B Bud B B Non è necessario aggiungere ulteriori ppa per ricevere questa patch. È necessario solo quanto segue

sudo apt-get update

sudo apt-get upgrade

Per assicurarti di aver corretto la patch di bash, esegui il seguente comando

dpkg -s bash | grep Version

Se sei su 14.04 LTS, dovresti vedere un output di:

Version: 4.3-7ubuntu1.4

Se sei su 12.04 LTS, il tuo output dovrebbe essere:

 Version: 4.2-2ubuntu2.5

9
2017-09-25 18:30



Era corretto, ma ora è stata resa disponibile una patch ufficiale, quindi è stato rilasciato l'aggiornamento per la sicurezza. Di conseguenza, questi passaggi non sono più necessari. - Robie Basak
Questo è corretto. Modificherò il post sopra. Grazie. - branch.lizard


Se sei il 11.04: usa i passaggi seguenti (ha funzionato per me)

cd ~/
mkdir bash
wget https://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
for i in $(seq -f "%03g" 0 25); do wget https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done

se non è stato scaricato patche richiesto, installare il pacchetto ftp

apt-get install ftp
for i in $(seq -f "%03g" 0 25); do wget https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done
./configure && make && make install
apt-get install build-essential
./configure && make && make install

Per vedere se la patch è stata applicata:

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

1
2017-09-25 17:13





Sto usando Natty 11.04, che è EOL (e ho aggiornato /etc/apt/sources.list per usare old-releases.ubuntu.com), quindi devo compilare dal sorgente. Volevo creare un .deb, quindi almeno la gestione dei pacchetti è "consapevole" che la versione di bash non è quella di default. Non ho successo al 100% - tuttavia, il pacchetto è registrato come "più recente" e il bash binario finisce risolto, quindi ecco cosa ho fatto:

apt-get source bash
wget https://gist.githubusercontent.com/drj11/e85ca2d7503f28ebfde8/raw/31bd53ed2e47b220d3c728f5440758e0f76769de/gistfile1.c -O bash_CVE-2014-6271.patch
wget https://gist.githubusercontent.com/drj11/239e04c686f0886253fa/raw/046e697da6d4491c3b733b0207811c55ceb9d927/gistfile1.c -O bash_CVE-2014-6271_plus.patch
cd bash-4.2/

Ora, nella (sotto) directory bash-4.2/, c'è: un file bash-4.2.tar.xz, che deve essere decompresso per arrivare al bash fonte; e una sottodirectory chiamata debian.

Ho apportato le seguenti modifiche per evitare dipendenze texlive: in bash-4.2/debian/control:

Source: bash
...
Build-Depends: autoconf, autotools-dev, patch, bison, libncurses5-dev,
# texinfo, debhelper (>= 5), texi2html, locales, gettext, sharutils, time, xz-ut
ils
 debhelper (>= 5), locales, gettext, sharutils, time, xz-utils
# Build-Depends-Indep: texlive-latex-base, ghostscript
Build-Depends-Indep: ghostscript

... e in bash-4.2/debian/rules:

binary-doc: bash-install #bash-doc-build
        dh_testdir
        dh_testroot
        mkdir -p $(d_doc)/usr/share/doc/$(p)
        dh_installdocs -p$(p_doc) 
ifeq ($(with_gfdl),yes)
        #cp -p build-bash/doc/bashref.pdf $(d_doc)/usr/share/doc/$(p)/.
        #dh_link -p$(p_doc) \
        #    /usr/share/doc/$(p)/bashref.pdf /usr/share/doc/$(p_doc)/bashref.pdf
else
        rm -f $(d_doc)/usr/share/doc-base/bashref
endif
        rm -f $(d_doc)/usr/share/info/dir*
        #cp -p build-bash/doc/bash.html build-bash/doc/bash.pdf \
        #    $(d_doc)/usr/share/doc/$(p)/
        #dh_link -p$(p_doc) \
        #    /usr/share/doc/$(p)/bash.html /usr/share/doc/$(p_doc)/bash.html \
        #    /usr/share/doc/$(p)/bash.pdf /usr/share/doc/$(p_doc)/bash.pdf
        dh_installchangelogs -p$(p_doc) bash/CWRU/changelog
        ...

Per cambiare la versione, in questo bash-4.2/ directory, fare:

bash-4.2$ dch --local patchCVE

... e inserisci le note nel registro delle modifiche quando richiesto. Ciò assicurerà che il .deb (e i relativi metadati) sia chiamato (nel mio caso) bash_4.2-0ubuntu3patchCVE1_i386.deb.

Quindi puoi provare a costruire con dpkg-buildpackage -us -uc o debuild comando. Nota: uno di questi rimuoverà il codice sorgente dallo zip, ignorando così le eventuali patch che potresti avere! Ancora, esegui uno di questi una volta così la sorgente viene spacchettata e costruita (nota debuild potrebbe ancora fallire alla fine a causa di texlive, ma dovrebbe decomprimere e compilare il sorgente).

Quindi, applica le patch; nota che dovresti usare -p1 qui, perché attualmente sei nel bash-4.2/ directory:

bash-4.2$ patch -p1 < ../bash_CVE-2014-6271.patch 
bash-4.2$ patch -p1 < ../bash_CVE-2014-6271_plus.patch 

Quindi ricompilare la versione con patch eseguendo:

bash-4.2$ fakeroot debian/rules build 

Questo ricostruirebbe l'eseguibile; per testarlo:

bash-4.2$ env VAR='() { :;}; echo Bash is vulnerable!' ./build-bash/bash -c "echo Bash Test"

Per creare i file .deb, esegui:

bash-4.2$ fakeroot debian/rules binary

Ciò salverà i file .deb nella directory superiore; per elencare i loro contenuti:

bash-4.2$ dpkg -c ../bash_4.2-0ubuntu3patchCVE1_i386.deb

Per installare il .deb:

bash-4.2$ sudo dpkg -i ../bash_4.2-0ubuntu3patchCVE1_i386.deb

Tuttavia, per qualche ragione, questo .deb contiene un binario senza patch (?!), Quindi ho dovuto fare anche:

bash-4.2$ sudo cp bash-4.2/build-bash/bash /bin/

... e dopo questo, il test ha iniziato a passare correttamente per me:

$ env VAR='() { :;}; echo Bash is!' bash -c "echo Bash Test"
bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR'
Bash Test

0
2017-09-28 10:16



Domanda: la domanda originale indica 1 possibile vettore di attacco come "script eseguiti da client DHCP non specificati". Cosa significa questo? Questo significa che Ubuntu / sbin / dhclient <- è vulnerabile? - Bran
Penso che forse i client non specificati significano che Ubuntu ha un / sbin / dhclient infetto, che esegue quindi dei comandi che portano allo script di bash che lancia shellshock. È quello che i client DHCP sono vulnerabili allo shellshock? (Spero che abbia senso, vedi il mio messaggio precedente del 10 ottobre) - Bran