Sicherheitslücke in Bash

[jahlives]

Gemäss https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271 gibt es eine recht grosse Lücke in Bash Implementationen. Alle Distris sind betroffen. Patches sind vorhanden.
zusätzlich bei Heise: http://www.heise.de/newsticker/meld...ubt-das-Ausfuehren-von-Schadcode-2403305.html

 

[Matthieu]

Offenbar nicht vollständig gepatcht.
https://twitter.com/taviso/status/514887394294652929

MfG Matthieu

 

[dany]

In den Non-IT Medien wird er schon "Heartbleed 2" genannt. Irgendwie übertrieben.

Soweit ich es verstehe, solange von Aussen die Umgebungsvariable nicht verändert werden kann, kann ja nicht passieren.
Betroffen wären z.B. wenn über Apache CGI ein Shell Script aufgerufen wird. Oder liege ich da falsch?

Gruss Dany

 

[jahlives]

wurde ein neuer CVE gemacht: https://access.redhat.com/security/cve/CVE-2014-7169
RedHat hat zudem einen Patch draussen, der das als Notfallmassnahme vollständig patchen soll (https://access.redhat.com/articles/1200223). Allerdings wird die noch offene Lücke als weniger gravierend angeschaut

 

[jahlives]

I
Betroffen wären z.B. wenn über Apache CGI ein Shell Script aufgerufen wird. Oder liege ich da falsch?

grundsätzlich alles was eine Bash aufruft. RedHat listet u.A. folgendes auf

Common Configuration Examples:

Red Hat performed an analysis to better understand the magnitude of this issue and how it affects various configurations. The below list is not exhaustive, but is meant to give some examples of how this issue affects certain configurations, and why the high level of complexity makes it impossible to specify something is not affected by this issue. The best course of action is to upgrade Bash to a fixed version.

httpd	CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.
Secure Shell (SSH)	It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.
dhclient	The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.
CUPS	It is believed that CUPS is affected by this issue. Various user supplied values are stored in environment variables when cups filters are executed.
sudo	Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.
Firefox	We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.
Postfix	The Postfix server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.

Zudem auch gelesen, dass mitterweile auch zsh anfällig sein soll (https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c29)

 

[Udiuke]

Was bedeutet das für mich als IT-Laie? Ist Synology auch davon betroffen, da ebenfalls Linux-basiert? Soll ich die DS erst mal vom Netz nehmen bis die einen Patch bereitstellen?

Danke für euer Feedback.

LG
Urs

 

[dil88]

Ich wollte vorhin schon etwas genau zu dieser (potentiellen) Frage schreiben: Die bash ist nicht Bestandteil des DSM, also des Betriebssystems der DS. Die Standardshell ist Teil der buxybox und m.W. eine ash. Insofern gehe ich nicht davon aus, dass man die DS vom Netz nehmen muss.

 

[hopeless]

@ Udiuke

Das kannst du mit diesem einfachen String auf der Shell testen:

env x='() { :;}; echo Verwundbar!' bash -c "echo Dies ist ein Test."

 

[Udiuke]

Hi,

danke für Dein Feedback. Dann bin ich erst mal beruhigt

VG
Urs

 

[jahlives]

die DS kann nur betroffen sein, wenn du die Bash als Shell verwendest, was im Auslieferungszustand nicht der Fall ist. Bash muss man via ipkg installieren und zur Systemshell machen, erst dann wäre eine DS betroffen. Von dem her bist du mit einer DS nicht betroffen

 

[Udiuke]

@hopeless

Wie mache ich das? Beispielsweise mit PuTTY?

 

[Frogman]

...wenn das für eine gemeine DS relevant wäre, hätte das wohl jahlives auch nicht unter "Offtopic" gepostet

 

[prologos]

Vielen Dank ...

Ach Leute, bin ich froh, dass es Dieses Forum gibt. Kompetente und schnelle Information ist für mich als Laie sehr hilfreich und wichtig!

Einen Vorschlag hätte ich dann doch noch.

Wäre es möglich, dass wichtige Infos, wie diese hier, automatisch per e-mail gesendet werden?
Würde Voraussetzen, dass solche Meldungen in einem vorbestimmten Tread erscheinen,- welchen man abonnieren kann. Oder wie auch immer. Ich habe zuerst aus der Zeitung von diesem "Bash Dings" gelesen, und erst dann im Forum geschaut.

vielen Dank
prologos

 

[hopeless]

@hopeless

Wie mache ich das? Beispielsweise mit PuTTY?

Du meldest dich als root mit Putty an der DS an und gibst den String ein. Dann sieht das vermutlich so ähnlich bei dir aus:

nemesis> env x='() { :;}; echo Verwundbar!' bash -c "echo Dies ist ein Test."
env: bash: No such file or directory
nemesis>

auf meinem raspberry gibt es dagegen:

root@raspbmc:~# env x='() { :;}; echo Verwundbar!' bash -c "echo Dies ist ein Test."
Verwundbar!
Dies ist ein Test.
root@raspbmc:~#

 

[JensLPZ]

Mittlerweile gibts auch einen echten Namen dafür: ShellShock


Und: Bash-Lücke: ShellShock ist noch nicht ausgestanden:
http://www.heise.de/newsticker/meld...hock-ist-noch-nicht-ausgestanden-2403607.html


Man sollte das auf jeden Fall nicht so einfach abtun mit "Linux ist sicher" und so. Immerhin hat das Nicht-Patchen der Heartbleed-Lücke zum Syno-Locker geführt - was keiner im Vorfeld gedacht hätte.


Und auch solche Zeilen sind bedenkenswert (aus dem HEISE-Beitrag):

"...Unwirksamer Patch

Ähnlich wie bei Heartbleed schaut die ganze Hacker-Szene gerade auf Bash und klopft es nach weiteren Problemen ab. So ist jetzt schon herausgekommen, dass der am gestrigen Mittwoch von fast allen Linux-Distributionen ausgegebene Patch wohl die Lücke nicht vollständig stopft..."

 

[jahlives]

mmerhin hat das Nicht-Patchen der Heartbleed-Lücke zum Syno-Locker geführt - was keiner im Vorfeld gedacht hätte.[/QUOTE]
hast du Belege für diese Behauptung? Das waren eher Lücken im DSM, die da ausgenutzt wurden.

 

[Frogman]

...Und auch solche Zeilen sind bedenkenswert (aus dem HEISE-Beitrag): "...Unwirksamer Patch Ähnlich wie bei Heartbleed schaut die ganze Hacker-Szene gerade auf Bash und klopft es nach weiteren Problemen ab. So ist jetzt schon herausgekommen, dass der am gestrigen Mittwoch von fast allen Linux-Distributionen ausgegebene Patch wohl die Lücke nicht vollständig stopft..."

Das halte ich nicht für "bedenkenswert", sondern für begrüßenswert - denn jede verstärkte systematische Betrachtung schafft weitere Sicherheit. Und unter dem Begriff "Hacker" sind eben nicht nur Spitzbuben zu verstehen . Es wäre töricht, stattdessen nur den unmittelbaren Patch zu liefern und gut ist...

 

[dil88]

Und unter dem Begriff "Hacker" sind eben nicht nur Spitzbuben zu verstehen .

Im Gegenteil, die Spitzbuben kenne ich auch eher unter dem Begriff "Cracker". Ich will nicht wissen, wo wir sicherheitstechnisch stünden ohne Hacker.

 

[X5_492_Neo]

Im Gegenteil, die Spitzbuben kenne ich auch eher unter dem Begriff "Cracker". Ich will nicht wissen, wo wir sicherheitstechnisch stünden ohne Hacker.

Luke, komm auf die dunkle Seite der Macht! Wir haben Kekse!

 

[Frogman]

...Wir haben Kekse!

Du meinst das Keksgeschwader vom Regulator...?!