Vraag Wat is de CVE-2014-6271-bash-kwetsbaarheid (Shellshock) en hoe los ik deze op?


Onlangs is er nieuws geweest met betrekking tot "CVE-2014-6271" (Zie USN-2362-1), wat een kwetsbaarheid is in Bash. Hoe weet ik of ik hier last van heb, hoe kan ik dit oplossen en waarom zou ik mij zorgen maken?

Dit is ontworpen als een canoniek antwoord op dit beveiligingslek, vanwege het bereik en de ernst.


140
2017-09-24 21:48


oorsprong


"hoe los ik het op?" -> voer gewoon uw upgrade manager uit! Echt waar, Ubuntu geeft beveiligingsupdates vrij, er is een speciaal beveiligingsteam. Plaats geen antwoorden over het bouwen van Bash vanaf de bron!; het is onnodig ingewikkeld en moeilijker om uw systeem in de toekomst te onderhouden. - gertvdijk
Plus, ook de extra CVE voor de onvolledige oplossing. CVE-2014-7169 - gertvdijk
alsjeblieft do antwoorden plaatsen over bouwen vanaf de bron. Of ze dat nou zouden moeten of niet, sommige mensen hebben oude Ubuntu-servers, en bouwen vanaf de bron kan hun enige optie zijn. - GaryO
oeps, sorry dat ik me net realiseerde dat ik bash gebruikte in plaats van een streepje in de test. Laat maar, het is goed. - Matt H
Lezen: oss-sec: Re: CVE-2014-6271: uitvoering van externe code via bash. Bash bug is nog steeds niet opgelost - blade19899


antwoorden:


Wat is Bash?

Bash is de standaard interactieve shell in Ubuntu. Wanneer u verbinding maakt met de terminal (via de terminalemulator, via een tty of ssh), typt u meestal opdrachten die bash zal lezen en uitvoeren. Zelfs als je de terminal helemaal niet gebruikt, heb je nog steeds Bash.

Op Ubuntu, /bin/sh is niet bash (het is streepje). Alleen bash wordt beïnvloed door dit beveiligingslek.

Hoe beïnvloedt de exploit mij?

Bash en het besturingssysteem houden een set bij omgevingsvariabelen die de huidige aangemelde gebruiker beschrijven, waar te zoeken naar programma's op de harde schijf en andere dergelijke functies. Door een omgevingsvariabele met een specifieke structuur te maken, kan een aanvaller de code volgende keer dat Bash start, kunnen uitvoeren.

De aanvaller kan die omgevingsvariabele op verschillende manieren instellen:

  • Op afstand verbinding maken met een service zoals SSH met een specifieke instelling zoals git over ssh. Zoals Mitre waarschuwt, het gebruik van de sshd ForceCommand optie is een aanvalsvector. Accounts waarvan de shell niet bash is, worden niet beïnvloed.
  • Tricking u in het instellen van de omgevingsvariabele.
  • Veroorzaken van een ander programma om een ​​omgevingsvariabele in te stellen om die bewerkte waarde te hebben. U hebt bijvoorbeeld een webserver en script die een omgevingsvariabele met specifieke gebruikerscontent moeten instellen. Zelfs als dat script zijn eigen script maakt en andere omgevingsvariabelen niet raakt, volstaat het. Een enkele omgevingsvariabele met een naam en een gemaakte waarde is voldoende om de exploit te laten slagen.
  • Andere manieren die ik hier niet heb genoemd.

Nadat ze deze variabele de volgende keer hebben ingesteld bash opent voor ieder reden, de code van uw aanvaller wordt uitgevoerd. Dit is vooral angstaanjagend met sudo -s, omdat het bash als de super-gebruiker spawnt (een administratieve gebruikersregel die dat wel heeft vol controle over de gegevens en programma's van uw computer). Zelfs als u bash alleen als standaardgebruiker start, kunnen de bestanden van die gebruiker worden verwijderd.

Het is belangrijk om op te merken dat, zelfs als je jezelf niet bash gebruikt, veel programma's zelf bashen zullen veroorzaken als onderdeel van hun werking. Zelfs in dit geval ben je kwetsbaar. Ubuntu's echter /bin/sh is geen bash, dus alleen programma's die expliciet bash aanroepen en niet de standaard scripting-shell worden beïnvloed.

Volgens Mitre:

vectoren met de ForceCommand-functie in OpenSSH sshd, de mod_cgi en mod_cgid modules in de Apache HTTP Server, scripts uitgevoerd door niet-gespecificeerde DHCP-clients en andere situaties waarin het instellen van de omgeving plaatsvindt over een privilege-grens van de uitvoering van de Bash.

Ben ik kwetsbaar?

Gebruik dpkg om uw geïnstalleerde pakketversie te controleren:

dpkg -s bash | grep Version

Dit zal info over je opzoeken bash pakket en filter de uitvoer om u alleen de versie te laten zien. De vaste versies zijn 4.3-7ubuntu1.4, 4.2-2ubuntu2.5, en 4.1-2ubuntu3.4.

Ik zie bijvoorbeeld:

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

en kan bepalen dat ik niet kwetsbaar ben.

Hoe kan ik updaten?

De standaard update manager biedt u deze update. Dit is een goed voorbeeld van hoe beveiligingsupdates belangrijk zijn, ongeacht welk besturingssysteem u gebruikt of hoe goed onderhouden het is.

De USN Bulletin stelt dat nieuwe versies zijn vrijgegeven voor Ubuntu 14.04 Trusty Tahr, 12.04 Precise Pangolin en 10.04 Lucid Lynx. Als u niet in een van deze LTS-versies bent, maar een redelijk recente versie hebt, zult u waarschijnlijk een gepatcht pakket kunnen vinden.

Controleer eerst of jij

Als je kwetsbaar bent, moet je eerst de nieuwste pakketlijsten pakken:

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

De eerste opdracht zorgt ervoor dat u de nieuwste pakketlijst hebt met de vaste versie en de tweede opdracht installeert de nieuwste (vaste) versie van bash.

Hoewel de bug alleen in het spel lijkt te komen als bash wordt aangemaakt, is het nog steeds een goed idee om onmiddellijk opnieuw op te starten als dit haalbaar is.


127
2017-09-24 21:48



Sorry, je bent kwetsbaar. De originele patch repareert niet het hele probleem. Zien cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169 AFAIAA, er is momenteel Nee openbaar beschikbare oplossing. Zie b.v. people.canonical.com/~ubuntu-security/cve/pkg/bash.html - Mormegil
@hexafraction Waar lees je dat 12.10 hier een update voor ontvangt? Ik denk het niet, 12.10, 13.04, 13.10 zijn heel veel End-of-Life! En ook back-uprepository's zijn dat niet gebruikt voor beveiligingsupdates. - gertvdijk
@hexafraction Nee, dat doen ze niet! Dat is het hele punt van End-of-Life zijn: helemaal geen ondersteuning meer. - gertvdijk
@ MichaelHärtl Als je op Ubuntu 12.10 zit, kun je de 12.04-versie van bash van downloaden packages.ubuntu.com/precise/bash en installeer het handmatig. - David
Oplossing voor CVE-2014-7169 is beschikbaar in de updatebeheerder (voor mij). - Calmarius


Heb dit gestolen cft over op Hacker News. Als je problemen hebt met je repo's zoals ik (Odroid-XU), dan zou dit goed moeten werken als je wilt patchen / bouwen vanaf de bron.

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

Voer dan uit:

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

En als je krijgt:

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

Dan ben je helemaal goed!


WAARSCHUWING: make install zal bash in installeren /usr/local/bin, dus /bin/bash is niet gewijzigd en kan worden opgeroepen door krul !!


27
2017-09-25 02:30



Zo kun je bash 3.2 bouwen met de patch op debian lenny: gist.github.com/mattwhite/86de50d30134129e44ef - Matt White
-1. Het is niet nodig om vanaf de bron te bouwen. Ubuntu heeft een beveiligingspatch in de repositories. Als je "problemen hebt met je repo", repareer dat dan. Je zult waarschijnlijk op veel meer manieren kwetsbaar zijn als je geen beveiligingsupgrades ontvangt! - gertvdijk
@Matt White Bedankt! Je hebt me een paar uur bespaard :) - Florian Fida
@FlorianFida Dit is AskUbuntu! Iedereen op deze site zal naar verwachting antwoorden plaatsen in het kader van het gebruik van Ubuntu. - gertvdijk
@ MichaelHärtl 12.10 is End-of-life. Het ontvangt al sinds lange tijd geen beveiligingsupdates meer. Upgrade!!! - gertvdijk


Opmerking: de beveiligingspatch voor CVE-2014-7169 is vrijgegeven als een standaard beveiligingsupdate. Het is niet nodig om extra ppa's toe te voegen om deze patch te ontvangen. Alleen het volgende is nodig.

sudo apt-get update

sudo apt-get upgrade

Voer de volgende opdracht uit om er zeker van te zijn dat u de juiste bash-bash hebt gebruikt

dpkg -s bash | grep Version

Als je op 14.04 LTS zit, zou je een output moeten zien van:

Version: 4.3-7ubuntu1.4

Als je op 12.04 LTS staat, zou je output moeten zijn:

 Version: 4.2-2ubuntu2.5

9
2017-09-25 18:30



Dit was correct, maar er is nu een officiële patch beschikbaar, dus de beveiligingsupdate is vrijgegeven. Daarom zijn deze stappen niet langer nodig. - Robie Basak
Dit is correct. Ik zal het bovenstaande bericht bewerken. Dank je. - branch.lizard


Als je op 11.04 bent: gebruik onderstaande stappen (het werkte voor mij)

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

als het niet de vereiste patche is, installeer dan het ftp-pakket

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

Om te zien of de patch is toegepast:

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

1
2017-09-25 17:13





Ik gebruik Natty 11.04, wat EOL is (en ik heb /etc/apt/sources.list bijgewerkt om old-releases.ubuntu.com te gebruiken), dus ik moet van de bron bouwen. Ik wilde een .deb bouwen, dus het beheren van het pakket is "bewust", de bash-versie is niet de standaardversie. Ik ben niet 100% succesvol - het pakket is echter geregistreerd als "nieuwer" en het bash binair eindigt vast, dus hier is wat ik deed:

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/

Nu in de (sub) map bash-4.2/, er is: een bestand bash-4.2.tar.xz, die moet worden uitgepakt om bij de bash bron; en een submap genaamd debian.

Ik heb de volgende wijzigingen aangebracht om afhankelijkheden te voorkomen 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

... en 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
        ...

Om de versie te veranderen, hierin bash-4.2/ map, doe:

bash-4.2$ dch --local patchCVE

... en vul de opmerkingen in het changelog in wanneer hierom wordt gevraagd. Dit zorgt ervoor dat de .deb (en bijbehorende metadata) wordt aangeroepen (in mijn geval) bash_4.2-0ubuntu3patchCVE1_i386.deb.

Dan kun je proberen met te bouwen dpkg-buildpackage -us -uc of debuild opdracht. Let op - een van deze zal de bron opnieuw uitpakken uit de zip - dus alle patches die je hebt gehad, overschrijven! Voer toch een van deze één keer uit, zodat de bron wordt uitgepakt en gebouwd (let op debuild kan uiteindelijk toch falen vanwege texlive, maar het moet de bron uitpakken en bouwen).

Breng vervolgens de pleisters aan; opmerking die je zou moeten gebruiken -p1 hier, omdat je momenteel in de 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 

Breid vervolgens de gepatchte versie opnieuw uit door het volgende uit te voeren:

bash-4.2$ fakeroot debian/rules build 

Dit zou het uitvoerbare bestand opnieuw opbouwen; om het te testen:

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

Ga als volgt te werk om de .deb-bestanden te maken:

bash-4.2$ fakeroot debian/rules binary

Hiermee worden de .deb-bestanden in de bovenliggende map opgeslagen; om hun inhoud op te sommen:

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

Om de .deb te installeren:

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

Om een ​​of andere reden bevat dit .deb echter een niet-gepatcht binair getal (?!), Dus ik moest ook doen:

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

... en daarna begon de test correct voor mij te verlopen:

$ 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



Vraag: De oorspronkelijke vraag noemt 1 mogelijke aanvalsvector als "scripts uitgevoerd door niet-gespecificeerde DHCP-clients". Wat betekent dit? Betekent dit dat Ubuntu's / sbin / dhclient <- kwetsbaar is? - Bran
Ik denk dat de niet-gespecificeerde clients misschien bedoelen dat de Ubuntu een geïnfecteerde / sbin / dhclient heeft, die dan opdrachten uitvoert die leiden naar het bash-script dat shellshock start. Is dat wat DHCP-clients kwetsbaar zijn voor shellshock? (Hoop dat het logisch is, zie mijn bovenstaande boodschap van 10 oktober) - Bran