Was ist die CVE-2014-6271-Bash-Sicherheitsanfälligkeit (Shellshock) und wie kann ich sie beheben?


141

Kürzlich gab es Neuigkeiten in Bezug auf "CVE-2014-6271" (siehe USN-2362-1 ), eine Sicherheitsanfälligkeit in Bash. Woher weiß ich, ob ich davon betroffen bin, wie ich es beheben kann und warum es mich interessieren sollte?

Dies ist aufgrund seines Umfangs und seiner Schwere eine kanonische Antwort auf diese Sicherheitsanfälligkeit.


18
"Wie behebe ich das?" -> Führen Sie einfach Ihren Upgrade-Manager aus! Ubuntu veröffentlicht wirklich Sicherheitsupdates, es gibt ein dediziertes Sicherheitsteam. Bitte posten Sie keine Antworten zum Erstellen von Bash aus der Quelle! ; Es ist unnötig kompliziert und schwieriger, Ihr System in Zukunft zu warten.
Gertvdijk

5
Plus, auch die zusätzliche CVE für den unvollständigen Fix. CVE-2014-7169
gertvdijk

18
Bitte schreibe Antworten über das Bauen von der Quelle. Unabhängig davon, ob sie es sollten oder nicht, einige Leute haben uralte Ubuntu-Server, und das Bauen aus dem Quellcode ist möglicherweise ihre einzige Option.
GaryO

3
Hoppla, sorry, ich habe gerade gemerkt, dass ich Bash statt Dash in den Test gesteckt habe. Egal, es ist in Ordnung.
Matt H

4
Lesen Sie: oss-sec: Betreff: CVE-2014-6271: Remote-Codeausführung durch Bash . Der Bash-Fehler wurde noch nicht behoben
blade19899

Antworten:


126

Was ist Bash?

Bash ist die standardmäßige interaktive Shell in Ubuntu. Wenn Sie eine Schnittstelle zum Terminal herstellen (entweder über den Terminalemulator, über tty oder ssh), geben Sie im Allgemeinen Befehle ein, bashdie gelesen und ausgeführt werden. Auch wenn Sie das Terminal nicht benutzen, haben Sie immer noch Bash.

Auf Ubuntu /bin/shist nicht bash (es ist Bindestrich). Von dieser Sicherheitsanfälligkeit ist nur bash betroffen.

Wie wirkt sich der Exploit auf mich aus?

Bash und das Betriebssystem überwachen eine Reihe von Umgebungsvariablen , die den aktuell angemeldeten Benutzer beschreiben, wo nach Programmen auf der Festplatte gesucht werden soll, und andere solche Funktionen. Durch das Erstellen einer Umgebungsvariablen mit einer bestimmten Struktur kann ein Angreifer beim nächsten Start von Bash möglicherweise Code ausführen.

Der Angreifer kann diese Umgebungsvariable auf verschiedene Arten festlegen:

  • Stellen Sie eine Remoteverbindung zu einem Dienst wie SSH mit einem bestimmten Setup wie git over ssh her. Wie Mitre warnt, ist die Verwendung der ForceCommandOption sshd ein Angriffsvektor. Konten, deren Shell nicht bash ist, sind nicht betroffen.
  • Sie dazu bringen, die Umgebungsvariable festzulegen.
  • Bewirken, dass ein anderes Programm eine Umgebungsvariable mit diesem gestalteten Wert festlegt. Beispielsweise verfügen Sie möglicherweise über einen Webserver und ein Skript, die eine Umgebungsvariable mit bestimmten Benutzerinhalten festlegen müssen. Selbst wenn dieses Skript ein eigenes Skript erstellt und keine anderen Umgebungsvariablen berührt, reicht es aus. Eine einzige Umgebungsvariable mit einem beliebigen Namen und einem erstellten Wert reicht aus, damit der Exploit erfolgreich ist .
  • Andere Möglichkeiten habe ich hier nicht erwähnt.

Sobald diese Variable festgelegt wurde und das nächste Mal bashaus irgendeinem Grund geöffnet wird , wird der Code Ihres Angreifers ausgeführt. Dies ist besonders furchterregend sudo -s, da Bash als Superuser auftritt (eine Regel für administrative Benutzer, die die volle Kontrolle über die Daten und Programme Ihres Computers hat). Auch wenn Sie bash nur als Standardbenutzer starten, können die Dateien dieses Benutzers gelöscht werden.

Es ist wichtig zu beachten, dass viele Programme selbst dann Bash erzeugen, wenn Sie Bash nicht selbst verwenden. Auch in diesem Fall sind Sie anfällig. Ubuntu /bin/shist jedoch kein Bash, so dass nur Programme betroffen sind, die explizit Bash aufrufen und nicht die Standard-Scripting-Shell.

Laut Mitre:

Vektoren, die die ForceCommand-Funktion in OpenSSH sshd, die Module mod_cgi und mod_cgid im Apache HTTP-Server, von nicht angegebenen DHCP-Clients ausgeführte Skripts und andere Situationen, in denen das Festlegen der Umgebung über eine Berechtigungsgrenze hinweg von der Bash-Ausführung erfolgt, betreffen.

Bin ich verletzlich?

Verwenden Sie dpkg, um Ihre installierte Paketversion zu überprüfen:

dpkg -s bash | grep Version

Dadurch werden Informationen zu Ihrem bashPaket nachgeschlagen und die Ausgabe so gefiltert, dass nur die Version angezeigt wird. Die festen Versionen sind 4.3-7ubuntu1.4, 4.2-2ubuntu2.5und 4.1-2ubuntu3.4.

Zum Beispiel sehe ich:

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

und kann feststellen, dass ich nicht verwundbar bin.

Wie aktualisiere ich?

Der Standard-Update-Manager bietet Ihnen dieses Update an. Dies ist ein hervorragendes Beispiel dafür, wie wichtig Sicherheitsupdates sind, unabhängig davon, welches Betriebssystem Sie verwenden oder wie gut es gewartet wird.

Im USN Bulletin heißt es, dass neue Versionen für Ubuntu 14.04 Trusty Tahr, 12.04 Precise Pangolin und 10.04 Lucid Lynx veröffentlicht wurden. Wenn Sie nicht mit einer dieser LTS-Versionen, sondern mit einer relativ aktuellen Version arbeiten, können Sie höchstwahrscheinlich ein gepatchtes Paket finden.

Überprüfen Sie zunächst, ob Sie

Wenn Sie anfällig sind, sollten Sie zuerst die neuesten Paketlisten herunterladen:

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

Der erste Befehl stellt sicher, dass Sie die neueste Paketliste haben, die die feste Version enthält, und der zweite Befehl installiert die neueste (feste) Version von bash.

Obwohl der Fehler nur beim Auftreten von Bash ins Spiel zu kommen scheint, ist es immer noch eine gute Idee, sofort neu zu starten, wenn dies machbar ist.


20
Entschuldigung, Sie sind verwundbar . Der ursprüngliche Patch behebt nicht das gesamte Problem. Siehe cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169 AFAIAA. Derzeit ist kein öffentlich verfügbares Update verfügbar. Siehe z. B. people.canonical.com/~ubuntu-security/cve/pkg/bash.html
Mormegil,

4
@hexafraction Wo liest du, dass 12.10 ein Update dafür erhält? Ich denke nicht, 12.10, 13.04, 13.10 sind sehr viel End-of-Life ! Außerdem werden Backport-Repositorys nicht für Sicherheitsupdates verwendet .
Gertvdijk

2
@hexafraction Nein, das tun sie nicht! Das ist der springende Punkt bei End-of-Life: Keine Unterstützung mehr.
Gertvdijk

1
@ MichaelHärtl Wenn Sie mit Ubuntu 12.10 arbeiten, können Sie die Version 12.04 von bash von packages.ubuntu.com/precise/bash herunterladen und manuell installieren.
David

2
Das Update für CVE-2014-7169 ist im Update-Manager (für mich) verfügbar.
Calmarius

27

Hat das bei Hacker News gestohlen . Wenn Sie Probleme mit Ihren Repos wie mir (Odroid-XU) haben, sollte dies gut funktionieren, wenn Sie von der Quelle aus patchen / bauen möchten.

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

Dann renne:

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

Und wenn Sie bekommen:

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

Dann geht es euch allen gut!


WARNUNG: make install installiert bash in /usr/local/bin, wird also /bin/bashnicht geändert und kann von curl aufgerufen werden !!


1
Hier ist, wie man Bash 3.2 mit dem Patch auf Debian Lenny erstellt
Matt White

13
-1. Es ist nicht erforderlich, aus dem Quellcode zu erstellen. Ubuntu hat einen Sicherheitspatch in den Repositories. Wenn Sie "Probleme mit Ihrem Repo" haben, beheben Sie das stattdessen. Sie sind wahrscheinlich in vielerlei Hinsicht verwundbar, wenn Sie keine Sicherheitsupgrades erhalten!
Gertvdijk

1
@ Matt White Vielen Dank! Du hast mir gerade ein paar Stunden gespart :)
Florian Fida

5
@FlorianFida Das ist AskUbuntu! Von jedem auf dieser Site wird erwartet, dass er Antworten im Rahmen der Verwendung von Ubuntu veröffentlicht.
Gertvdijk

6
@ MichaelHärtl 12.10 ist End-of-Life. Es werden seit langem keine Sicherheitsupdates mehr empfangen. Aktualisierung!!!
Gertvdijk

9

Hinweis: Der Sicherheitspatch für CVE-2014-7169 wurde als Standard-Sicherheitsupdate veröffentlicht. Es ist nicht erforderlich, zusätzliche PPAs hinzuzufügen, um diesen Patch zu erhalten. Es wird nur Folgendes benötigt.

sudo apt-get update

sudo apt-get upgrade

Führen Sie den folgenden Befehl aus, um sicherzustellen, dass Sie Bash korrekt gepatcht haben

dpkg -s bash | grep Version

Wenn Sie auf 14.04 LTS sind, sollten Sie eine Ausgabe von sehen:

Version: 4.3-7ubuntu1.4

Wenn Sie mit 12.04 LTS arbeiten, sollte Ihre Ausgabe wie folgt aussehen:

 Version: 4.2-2ubuntu2.5

1
Dies war korrekt, aber jetzt wurde ein offizieller Patch zur Verfügung gestellt, sodass das Sicherheitsupdate veröffentlicht wurde. Folglich sind diese Schritte nicht mehr erforderlich.
Robie Basak

Das ist richtig. Ich werde den obigen Beitrag bearbeiten. Danke.
branch.lizard

1

Wenn Sie am 11.04 sind: Verwenden Sie die folgenden Schritte (es hat bei mir funktioniert)

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

Wenn es nicht heruntergeladen wird, muss patche installiert werden

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

So überprüfen Sie, ob der Patch angewendet wurde:

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

0

Ich verwende Natty 11.04, das ist EOL (und ich habe /etc/apt/sources.list aktualisiert, um old-releases.ubuntu.com zu verwenden), also muss ich aus dem Quellcode erstellen. Ich wollte eine .deb-Datei erstellen, damit zumindest die Paketverwaltung "merkt", dass die Bash-Version nicht die Standardversion ist. Ich bin nicht zu 100% erfolgreich - das Paket ist jedoch als "neuer" registriert und die bashBinärdatei wird repariert. Deshalb habe ich Folgendes getan:

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/

Nun gibt es im (Unter-) Verzeichnis bash-4.2/: eine Datei bash-4.2.tar.xz, die entpackt werden muss, um zur bashQuelle zu gelangen ; und ein Unterverzeichnis namens debian.

Ich habe die folgenden Änderungen vorgenommen, um Abhängigkeiten zu vermeiden 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

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

Um die Version zu ändern, gehen Sie in diesem bash-4.2/Verzeichnis wie folgt vor:

bash-4.2$ dch --local patchCVE

... und tragen Sie die Notizen im Changelog ein, wenn Sie gefragt werden. Dadurch wird sichergestellt, dass die .deb-Datei (und die zugehörigen Metadaten) aufgerufen werden (in meinem Fall) bash_4.2-0ubuntu3patchCVE1_i386.deb.

Dann können Sie versuchen, mit dpkg-buildpackage -us -ucoder debuildBefehl zu bauen. Hinweis: In beiden Fällen wird der Quellcode von der Zip-Datei neu entpackt. Dadurch werden alle Patches überschrieben, die Sie möglicherweise hatten. Führen Sie dennoch einen dieser debuildSchritte aus, damit die Quelle entpackt und erstellt wird (Hinweis: Möglicherweise schlägt dies am Ende aufgrund von texlive fehl, aber die Quelle sollte entpackt und erstellt werden).

Wenden Sie dann die Patches an. Hinweis, den Sie hier verwenden sollten -p1, da Sie sich derzeit im bash-4.2/Verzeichnis befinden:

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

Erstellen Sie dann die gepatchte Version neu, indem Sie Folgendes ausführen:

bash-4.2$ fakeroot debian/rules build 

Dies würde die ausführbare Datei neu erstellen. um es zu testen:

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

Führen Sie zum Erstellen der DEB-Dateien Folgendes aus:

bash-4.2$ fakeroot debian/rules binary

Dadurch werden die .deb-Dateien im übergeordneten Verzeichnis gespeichert. um ihren Inhalt aufzulisten:

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

So installieren Sie die .deb:

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

Aus irgendeinem Grund enthält diese .deb-Datei jedoch eine ungepatchte Binärdatei (?!), Weshalb ich zusätzlich Folgendes tun musste:

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

... und danach hat der Test für mich richtig bestanden:

$ 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

Frage: In der ursprünglichen Frage wird 1 möglicher Angriffsvektor als "von nicht angegebenen DHCP-Clients ausgeführte Skripte" angegeben. Was bedeutet das? Bedeutet dies, dass Ubuntus / sbin / dhclient <- anfällig ist?
Bran

Ich denke, die nicht spezifizierten Clients bedeuten möglicherweise, dass Ubuntu einen infizierten / sbin / dhclient hat, der dann Befehle ausführt, die dazu führen, dass das Bash-Skript Shellshock startet. Ist es das, was DHCP-Clients für Shellshock anfällig sind? (Hoffe das macht Sinn, siehe meine obige Nachricht vom 10. Oktober)
Bran
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.