[Update] Sicherheitslücken in Bash und APT

Sicherheitslücken gibt es immer wieder einmal in Betriebssystemen. Diese Woche wurden aber zwei sehr gravierende Mängel in der Bash und im Paketmanagementsystem APT gefunden.

ShellShock: Sicherheitslücke in der Bash¶

Es ist gerade einmal drei Monate her, dass ein kritischer Programmierfehler in der OpenSSL-Bibliothek zur Verschlüsselung von Verbindungen für Aufsehen sorgte. Heartbleed sorgte dafür, dass zahlreiche Server aktualisiert werden und Benutzer ihre Passwörter ändern mussten. Jetzt gibt es mit ShellShock eine neue Sicherheitslücke, diesmal in der Bash, die ähnlich schwerwiegend ist.

Hintergrund des Problem ist, dass es möglich ist, über Umgebungsvariablen beliebigen Code bei der Ausführung einer neuen Shell-Instanz ausführen zu lassen. Wie gezeigt wurde 🇬🇧, sind damit vor allem Webserver, die noch CGI nutzen, leicht angreifbar. Die meisten Linux-Distributoren haben die Lücke bereits behoben, das Update scheint aber dem Fehler noch nicht gänzlich entgegenzuwirken.

Ob das eigene System noch betroffen ist, kann man mittels

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

im Terminal prüfen. Ist das Ergebnis vulnerable, so ist man verwundbar. In dem Fall sollte man schnellsten die vom Distributor bereitgestellten Updates installieren. Bei einem gepatchten System erscheint:

bash: Warnung: x: ignoring function definition attempt
bash: Fehler beim Importieren der Funktionsdefinition für »x«.
this is a test

Update 30.09.2014¶

Nachdem ShellShock bekannt geworden ist, haben sich Entwickler weltweit darangesetzt, weitere Fehler der Bash aufzudecken. Hierbei sind weitere Lücken zum Vorschein gekommen. Hanno Böck von Golem hat ein Skript bashcheck geschrieben, welches man bei Github herunterladen und ausführen kann, um zu prüfen, welche Lücken die eigene Bash noch aufzeigt. Bei einem teils ungesicherten Ubuntu 12.04 LTS sieht die Ausgabe dann beispielsweise so aus:

$ ./bashcheck
bash: Warnung: x: ignoring function definition attempt
bash: Fehler beim Importieren der Funktionsdefinition für »x«.
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
./bashcheck: Zeile 18:  2653 Speicherzugriffsfehler  (Speicherabzug geschrieben) bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser still active, likely vulnerable to yet unknown parser bugs like CVE-2014-6277 (lcamtuf bug)

Quellen¶

Pufferüberlauf in APT¶

APT (Advanced Packaging Tool) ist das Paketmanagementsystem unter Debian, Ubuntu und deren Derivate. Diese Woche wurde von Googles Sicherheitsteam ein Fehler in der Paketverwaltung gefunden, der es ermöglicht, Schadcode auszuführen.

Als Angriffsszenario wird ein Man-in-the-middle-Angriff genannt, bei dem der Angreifer manipulierte Pakete einschleust und so einen Pufferüberlauf erzeugt. Hiermit ist es dann möglich, beliebigen Schadcode auszuführen. Problematisch ist dies auch deswegen, da APT in der Regel mit Root-Rechten läuft und somit vollen Zugriff auf das System hat.

Debian und Ubuntu haben bereits Updates bereitgestellt, die man baldmöglichst installieren sollte. Hierbei sollte man am besten darauf achten, die Pakete aus einer vertrauenswürdigen Quelle bzw. einem vertrauenswürdigem Netzwerk zu beziehen.

Letzte Woche wurde bereits eine Lücke bei den Signaturen in APT behoben.

Quellen¶

Veröffentlicht von Dee | 27. September 2014 13:00 | Kategorie: Linux und Open Source | Letzte Aktualisierung: 30. September 2014 08:10 | # Fehler im Artikel melden

juifeng

1 27. September 2014 14:22

Noch eine Anmerkung: Manche der Patches unterdrücken die Fehlerausgabe ("ignoring function definition attempt"), in dem Fall würde ein gepatchtes System nur "this is a test" ausgeben. Solange nicht "vulnerable" ausgegeben wird, ist es auf jeden Fall in Ordnung.

Mein Ubuntu gibt aber aktuell auch die Fehlermeldung noch aus. Könnte sich evtl. in Zukunft ändern.

Hintergrund ist, dass es wohl bei manchen unerwünscht ist, dass durch das Setzen einer Umgebungsvariablen Fehlermeldungen erzeugt werden können. (Wobei man AFAIK auch durch z.B. das Setzen ungültiger Locales oder so Fehler erzeugen kann, aber der Unterschied ist wohl, dass bei Bash jede beliebige Umgebungsvariable für die Erzeugung des Fehlers genutzt werden kann, nicht nur einige ausgewählte.)

praseodym

Supporter

2 28. September 2014 23:28

https://github.com/hannob/bashcheck

http://www.golem.de/news/shellshock-immer-mehr-luecken-in-bash-1409-109483.html

Das verlinkte bashcheck-Skript liefert auf einem aktuellen Xubuntu 14.04:

bash bashcheck.sh (bzw. auch mit ./bashcheck.sh)
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs

aber:

sh bashcheck.sh 
-e Not vulnerable to CVE-2014-6271 (original shellshock)
-e Not vulnerable to CVE-2014-7169 (taviso bug)
-e Not vulnerable to CVE-2014-7186 (redir_stack bug)
-e Vulnerable to CVE-2014-7187 (nessted loops off by one)
-e Variable function parser inactive, likely safe from unknown parser bugs

Im XFCE4-terminal:

./bashcheck.sh 
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs

Meinungen?

Dee

3 29. September 2014 06:40

Soll ich das Skript als Update noch einbauen? Finde das ganz sinnvoll.

Bei "sh bashcheck.sh" bin ich nicht sicher, auf was Du Dich genau beziehst. Du führst das Skript mit der Dash aus und startest aus ihr heraus dann die einzelnen Bash-Shells. Das verhält sich "natürlich" etwas anders als direkt aus der Bash heraus.

Oder war das "aber" auf etwas anderes als die unterschiedliche Ausgabe bezogen?

ingo2

4 29. September 2014 16:33

Kannst es natürlich auch hier in den Kommentaren belassen:

#!/bin/bash
r=`x="() { :; }; echo x" bash -c ""`
if [ -n "$r" ]; then
echo -e '\033[91mVulnerable to CVE-2014-6271 (original shellshock)\033[39m'
else
echo -e '\033[92mNot vulnerable to CVE-2014-6271 (original shellshock)\033[39m'
fi
cd /tmp;rm echo 2>/dev/null
X='() { function a a>\' bash -c echo 2>/dev/null > /dev/null
if [ -e echo ]; then
echo -e "\033[91mVulnerable to CVE-2014-7169 (taviso bug)\033[39m"
else
echo -e "\033[92mNot vulnerable to CVE-2014-7169 (taviso bug)\033[39m"
fi
bash -c "true $(printf '<<EOF %.0s' {1..79})" 2>/dev/null
if [ $? != 0 ]; then
echo -e "\033[91mVulnerable to CVE-2014-7186 (redir_stack bug)\033[39m"
else
echo -e "\033[92mNot vulnerable to CVE-2014-7186 (redir_stack bug)\033[39m"
fi
bash -c "`for i in {1..200}; do echo -n "for x$i in; do :;"; done; for i in {1..200}; do echo -n "done;";done`" 2>/dev/null
if [ $? != 0 ]; then
echo -e "\033[91mVulnerable to CVE-2014-7187 (nessted loops off by one)\033[39m"
else
echo -e "\033[96mTest for CVE-2014-7187 not reliable without address sanitizer\033[39m"
fi
r=`a="() { echo x;}" bash -c a 2>/dev/null`
if [ -n "$r" ]; then
echo -e "\033[93mVariable function parser still active, likely vulnerable to yet unknown parser bugs like CVE-2014-6277 (lcamtuf bug)\033[39m"
else
echo -e "\033[92mVariable function parser inactive, likely safe from unknown parser bugs\033[39m"
fi

P.S.: übrigens in Wheezy der gleiche Output.

DPITTI

5 29. September 2014 23:42

Gut das ich immer Updates einspiele per Synaptic ☺

Tuemmler

6 30. September 2014 15:05

XFCE

$ ./bashcheck
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs

Und nun eine Frage, wie ist die Gefährdung bei denen, die eine EoL nutzen und keine Updates einspielen? Das kann doch nur ins "Auge" gehen.

Gruß

ingo2

7 8. Oktober 2014 21:08

Habe ich gerade als News-Feed gelesen:

http://evolvisforge.blog.tarent.de/archives/93

Eigentlich traurig - nur Sid hat bis jetzt alle CVE's gefixt.

Gruß, Ingo