Ja, Sie sind technisch verwundbar. Wenn Sie also Lust haben, einem Kunden, der in Panik geraten ist, ein paar Stunden lang Panik zu versetzen oder diese in Rechnung zu stellen, dann machen Sie mit!
In Wirklichkeit sind Sie jedoch nicht gefährdet, wenn Sie keinen SSH-Zugriff über Remoteverbindungen oder einen Webserver zulassen, auf dem serverseitige Skripts ausgeführt werden. Sie sind nur dann wirklich verwundbar, wenn jemand, den Sie nicht kennen, über Fernzugriff auf Ihren Computer zugreifen und dies auf eine Weise tun kann, bei der ein Bash-Befehl ausgeführt werden kann.
Das heißt, Ihr Desktop-Mac - auf dem wirklich keine Serveranwendungen ausgeführt werden - ist keinem ernsthaften Risiko ausgesetzt. Ich bin bereit, hier eine sprichwörtliche "bescheidene Torte" zu essen, aber ich glaube nicht, dass die Mehrheit der Mac-Benutzer am Ende des Tages einem Risiko ausgesetzt sein wird.
Daher ist dieses Problem hauptsächlich für Systemadministratoren auf Mac OS X- und Unix / Linux-Servern von Belang, nicht für Desktop-Benutzer, die die SSH-Freigabe nicht aktivieren.
Vielleicht besteht das Risiko, dass ein Mac-Schadprogramm oder ein Mac-Virus erstellt wird, um dieses Risiko auszunutzen, aber ich bezweifle es.
EDIT: Und nur um zu erläutern, wie dieses Problem - meiner bescheidenen Meinung nach - für die meisten Durchschnittsbenutzer eigentlich kein Problem darstellt, kann ich unter bashMac OS X 10.9.5 den folgenden Befehl ausführen:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
Und ich sehe das:
vulnerable
hello
Erraten Sie, was? Das ist nur erschreckend, wenn Sie dies nicht rational ausdenken. Ich musste bereits auf meinem Mac eingeloggt sein, um das Terminal öffnen zu können. Und um zu negieren, was ich oben über SSH gesagt habe, um überhaupt zu dem Punkt zu gelangen, an dem ich diesen Test ausführen kann, selbst wenn SSH aktiviert ist, müsste ich zunächst noch angemeldet sein. Und dann - sagen wir, ich erhalte Zugriff über SSH - kann ich mit dem Befehl NICHTS tun, das über meine normalen Benutzerrechte hinausgeht:
env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'
Das heißt, wenn Sie wirklich gefährdet sind, von diesem Hack ausgenutzt zu werden, müsste Ihre Kernsicherheit auf dem System so gefährdet sein, dass die Tatsache, dass bashein Fehler vorliegt, wirklich das allerwenigste Ihrer Probleme ist.
Dies ist ein Anliegen von einem Gesamtkontrolle und Rechte Problem , da es als das Potential unbeabsichtigten Zugang zu ermöglichen , da das Verhalten außerhalb der erwarteten Normen erstreckt. Meiner bescheidenen Meinung nach ist dies jedoch kein mit OpenSSL oder der Sorte garden vergleichbares Risiko.
Letztendlich patche ich immer noch alle meine Linux / Unix-Server, die ich als Standardprozedur ausführe. Und die Macs, die ich verwalte, werden glücklich gepatcht, sobald eine Korrektur abgeschlossen ist. Aber für den praktischen Alltag ist mir das völlig egal, da ich nicht verstehe, wie sich ein Fehler, der keine erhöhten Benutzerrechte zulässt, summiert.
UPDATE: Offizielles Wort von Apple hier veröffentlicht ; Hervorhebung von mir:
"Die überwiegende Mehrheit der OS X-Benutzer ist nicht gefährdet, kürzlich gemeldete Bash-Sicherheitslücken zu entdecken", sagte ein Apple-Sprecher gegenüber iMore Kontrolle anfälliger Systeme. Unter OS X sind Systeme standardmäßig sicher und können nur dann von Bash-Servern aus der Ferne ausgenutzt werden, wenn Benutzer erweiterte UNIX-Dienste konfigurieren.
Wir arbeiten daran, unseren fortgeschrittenen UNIX-Benutzern schnell ein Software-Update zur Verfügung zu stellen. “
Übersetzung: Was ich oben gesagt habe, ist dies ein Server- und kein Client-Problem? Genau.
EIN ENDGÜLTIGES UDPATE: Ab dem 29. September hat Apple offiziell Patches für Mac OS X 10.9.5, 10.8.5 und 10.7.5 veröffentlicht.
NOCH EIN ANDERES ENDGÜLTIGES UPDATE: Und jetzt hat Apple heute ein kombiniertes Sicherheitsupdate veröffentlicht, das auch das bashUpdate enthält !
Hinweis: Das Sicherheitsupdate 2014-005 enthält den Sicherheitsinhalt von OS X bash Update 1.0