Red Hat hat kürzlich einen großen sicherheitsrelevanten Fehler in der Bash-Shell bekannt gegeben. Manche nennen es den "Shellshock"-Bug. Da OS X auf Unix basiert, ist es anfällig für Angriffe, die diesen Fehler ausnutzen?
Muss ich mir als Endbenutzer Sorgen um eine sofortige Lösung machen? Oder sollte ich besser auf ein offizielles Software-Update von Apple warten?
Ja, Sie sind technisch anfällig. Wenn Sie also Lust haben, in Panik zu geraten oder einem in Panik geratenen Kunden ein paar Stunden Panikarbeit in Rechnung zu stellen, tun Sie es!
Aber die Realität ist, dass Sie kein Risiko eingehen, es sei denn, Sie erlauben den SSH-Zugriff von Remote-Verbindungen oder einem Webserver, der serverseitiges Skripting ausführt. Sie sind nur dann wirklich angreifbar, wenn jemand, den Sie nicht kennen, aus der Ferne auf Ihren Computer zugreifen kann und dies so tut, dass ein Bash-Befehl ausgeführt werden kann.
Das bedeutet, dass Ihr Desktop-Mac – auf dem wirklich keinerlei Serveranwendungen ausgeführt werden – keinem ernsthaften Risiko ausgesetzt ist. Ich bin bereit, hier einen sprichwörtlichen „bescheidenen Kuchen“ zu essen, aber ich glaube nicht, dass die Mehrheit der Mac-Benutzer da draußen am Ende des Tages gefährdet sein wird.
Daher betrifft dieses Problem hauptsächlich Systemadministratoren auf Mac OS X- und Unix/Linux-Servern, die der Welt ausgesetzt sind, nicht Desktop-Benutzer, die die SSH-Freigabe nicht aktivieren.
Vielleicht besteht ein Randrisiko, dass eine Mac-Malware oder ein Virus erstellt wird, um dieses Risiko auszunutzen, aber ich bezweifle es.
BEARBEITEN: Und nur um näher darauf einzugehen, dass dieses Problem – meiner bescheidenen Meinung nach – für die meisten durchschnittlichen Benutzer nicht wirklich ein Problem ist, ja, ich kann den folgenden Befehl unter bash
Mac OS X 10.9.5 ausführen:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
Und ich sehe das:
vulnerable
hello
Erraten Sie, was? Das ist nur erschreckend, wenn man das nicht rational durchdenkt. Ich musste bereits an meinem Mac angemeldet sein, um überhaupt das Terminal zu öffnen. Und um das zu negieren, was ich oben über SSH gesagt habe, um überhaupt zu dem Punkt zu kommen, an dem ich diesen Test ausführen kann, selbst wenn SSH aktiviert ist, müsste ich zunächst immer noch angemeldet sein. Und dann – nehmen wir an, ich bekomme Zugriff über SSH – erlaubt mir der Befehl NICHTS über meine normalen Benutzerrechte hinaus zu tun, wie zum Beispiel:
env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'
Das heißt, wenn Sie wirklich anfällig dafür sind, von diesem Hack ausgenutzt zu werden, müsste Ihre Kernsicherheit auf dem System so gefährdet sein, dass die Tatsache, dass bash
ein Fehler vorliegt, wirklich das allergeringste Ihrer Probleme ist.
Dies ist ein Problem aus einem allgemeinen Kontroll- und Rechteproblem, da es das Potenzial hat , unbeabsichtigten Zugriff zuzulassen, da das Verhalten außerhalb der erwarteten Normen liegt. Aber meiner bescheidenen Meinung nach ist es kein Risiko, das mit OpenSSL oder der Gartenvariante „Lass mich mein Passwort auf einer Notiz auf meinem Bildschirm hinterlassen“ vergleichbar ist.
Am Ende des Tages patche ich immer noch alle meine Linux/Unix-Server, die ich als Standardverfahren betreibe. Und werde gerne die Macs patchen, die ich verwalte, sobald ein Fix herauskommt. Aber für den praktischen täglichen Gebrauch fühle ich mich gut, wenn ich mir darüber keine Gedanken mache, da ich nicht verstehe, wie ein Fehler, der keine erhöhten Benutzerrechte zulässt, zu irgendetwas führt.
UPDATE: Offizielles Wort von Apple hier gepostet ; Betonung von mir:
„Die überwiegende Mehrheit der OS X-Benutzer ist nicht durch kürzlich gemeldete Bash-Sicherheitslücken gefährdet“, sagte ein Apple-Sprecher gegenüber iMore Kontrolle anfälliger Systeme. Mit OS X sind Systeme standardmäßig sicher und keinen Remote-Exploits von Bash ausgesetzt, es sei denn, Benutzer konfigurieren erweiterte UNIX-Dienste. Wir arbeiten daran, unseren fortgeschrittenen UNIX-Benutzern schnell ein Software-Update bereitzustellen.“
Übersetzung: Was ich oben gesagt habe, ist ein Serverproblem und kein Clientproblem? Genau.
EIN LETZTES UDPATE: Für alle, die mit dem Kompilieren aus dem Quellcode zu kämpfen haben, hat Apple am 29. September offiziell Patches für Mac OS X 10.9.5, 10.8.5 sowie 10.7.5 veröffentlicht:
NOCH EIN WEITERES LETZTES UPDATE: Und jetzt hat Apple gerade ein kombiniertes Sicherheitsupdate veröffentlicht, das das bash
Update ebenfalls enthält !
Hinweis: Sicherheitsupdate 2014-005 enthält die Sicherheitsinhalte von OS X Bash Update 1.0
bash
. Worauf basiert die Angst also genau? Auch wenn das Gastkonto offen & irgendwie bash
nutzbar ist, was dann? Soweit ich sehe, hätte eine Vermutung, dass die Verwendung dieses Exploits keine erhöhten Privilegien oder ähnliches hätte. Im Ernst, ich bin bereit, von meiner Haltung zurückzutreten, aber das scheint eher eine Panik zu sein, die auf nicht viel basiert, während OpenSSL ein echtes Problem war.bash
kann er durch Ausnutzen der Schwachstelle jeden Daemon zwingen, als Root zu laufen und eine Bash zu verwenden, um jeden Befehl mit den Root- Privilegien auszuführen. Standardmäßig ist bei Mavericks das Gastkonto deaktiviert, und der ssh
Zugriff ist ebenfalls deaktiviert :).bash
manuell aus der Quelle zu patchen. Aufgrund von Ratschlägen wie diesem wird den Client-Rechnern TONNENWEISE mehr Schaden zugefügt werden, als es bei einem echten „Shellshock“-Exploit der Fall wäre.@mac.com
Adresse. Sie tun nichts, außer an der Nachricht in Mail.app vorbeizublättern, die das PDF im Vorschaufenster anzeigt, was dann die Payload auslöst (CVE-2014-4377). Ihre ungepatchte Bash könnte diesen Userland-Exploit (schlecht) in einen Root-Level-Exploit (schlimmer) verwandeln.Ja!
Geben Sie dies in Ihre Shell ein
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
Wenn es heißt, vulnerable
dann sind Sie verwundbar.
Wenn es heißt
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello
dann bist du gut.
Edit: Link zum Fix
env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
aus -- Selbst nachdem ich mein System gepatcht habe, hustet dieses hier auf der Befehlszeile ein "Busted". Bah./bin/sh
... Sie müssen beide /bin/sh
ersetzen und /bin/bash
geschützt werden. /bin/sh
ist eigentlich problematischer, da es die Shell ist, die Skriptsprachen wahrscheinlich verwenden, um Shell-Befehle auszuführen.bash
und sh
in einem einzigen Schritt erledigt. Das Erstellen aus Vanilla-GNU-Quellen erfordert separate Kompilierungen. Außerdem bashbug
hat es unter OS X einen anderen Installationsort als die GNU-Ausgabe, sodass auch diese verschoben werden muss.Überprüfen Sie als Endbenutzer Folgendes:
Ihr Gastkonto ist deaktiviert:
Systemeinstellungen > Benutzer & Gruppen > Gastbenutzer
Ihr ssh
Zugang ist deaktiviert:
Systemeinstellungen > Freigabe > Remote-Anmeldung
Standardmäßig sind diese beiden auf Mavericks deaktiviert.
Als Endbenutzer ist es sicherer , auf ein offizielles Apple-Sicherheitsupdate zu warten, das diese bash
Schwachstelle behebt.
Alle Mac OS X-Maschinen sind technisch anfällig für „Shellshock“, bis Apple ein Sicherheitsupdate veröffentlicht, das Bash patcht, aber …
Ihre Frage sollte lauten: Kann ich aus der Ferne gehackt werden?
Es gibt so viel Software, die bash
geistesabwesend verwendet wird, dass die Beantwortung dieser Frage extrem schwierig ist. Wenn Sie sich Sorgen machen, würde ich einige Änderungen vorschlagen System Preferences
, um Remote-Exploits zu verhindern:
Wenn Sie besonders besorgt sind, drücken Sie die Firewall
Optionstaste, um:
Automatically allow signed software to receive incoming connections
.Block all incoming connections
.Es besteht immer noch eine respektable Chance, dass Sie für einen Level-Angriff mit DHCP, Bonjour usw. anfällig sind, aber hey, wenn Sie einen anderen Dienst benötigen, können Sie ihn natürlich laufen lassen, während Sie hoffen, dass er nicht ausgenutzt wird. Und Sie müssen auch die Firewall offener lassen. Es wird wahrscheinlich in Ordnung sein, wenn Ihre Maschine hinter einer anderen Firewall lebt.
Gibt es auch lokale Privilegien-Eskalationsangriffe, die durch „Shellshock“ ermöglicht werden? Ja, fast sicher. Ich würde mir jedoch keine Sorgen machen, da Mac OS X genug ähnliche Angriffe hat. Apple patcht lokale Rechteeskalationsfehler nicht schnell. Und Apple erstellt sie häufig mit Apple Script-fähigen Diensten. Gehen Sie einfach davon aus, dass alle Mac OS X-Rechner immer anfällig für lokale Angriffe sind. Wenn Sie an Hacker-Konferenzen wie DEFCON teilnehmen müssen, kaufen Sie sich für diesen Zweck eine Linux-Box.
Update: Es gibt Anweisungen zum Neukompilieren Ihrer eigenen festen Bash und weitere Fragen, die dabei behandelt werden . Ich werde das selbst machen, aber meiner Meinung nach ist das übertrieben, wenn Sie keine Server betreiben und Apples Firewall sowieso eingeschaltet lassen.
Update: Wenn Sie mit der Terminalnutzung vertraut sind, gibt es hier ein Programm namens erwähntexecsnoop
, mit dem Sie testen können, ob Bash normalerweise von Ihren Serverprozessen aufgerufen wird. Ist kein Wundermittel, da der Serverprozess bash möglicherweise nur in ungewöhnlichen Situationen aufruft, aber es gibt Ihnen eine gute Idee.
Schließlich ist Apple nicht sehr gut darin, Sicherheitslücken zu patchen, aber sie sind gut in PR, also wird das hier relativ schnell gepatcht. Es ist daher vernünftig zu denken "Ich muss nicht schneller laufen als der Bär, ich muss nur schneller laufen als die große Anzahl leicht ausnutzbarer Server im Internet". :)
strings /usr/libexec/bootpd | egrep '/bin|bash'
und nm -a /usr/libexec/bootpd | egrep 'fork|exec'
. Wenn Sie diese Befehlsausgabe auf verschiedenen Versionen von MacOS X lesen, überdenken Sie möglicherweise Ihre Risikoanalyse aufgrund dhcpd
von MacOS X … aber diese allein :(.otool -L /usr/libexec/bootpd
meldet, dass sie einen exec
Aufruf enthält. Und der strings
Befehl ist sinnlos, da Umgebungsvariablen die aufgerufene Shell bestimmen. Ich bin jedoch beeindruckt, dass keine Bibliotheksanrufe gefallen haben system
.otool -L
- die einzige Ausgabe, die ich davon erhalte, ist eine Liste von Bibliotheken (CoreFoundation, SystemConfiguration, OpenDirectory, libresolv.9.dylib und libSystem.B.dylib)strings .. | grep SHELL
ist viel nützlicher als bash
, aber nicht absolut. Imho nm -a ... | grep system
ist das Wichtigste und exec
hilft auch, aber das ist nur für Vanilla-BSD-, Linux- usw. Software. Apples Bibliotheken bieten verschiedene Routinen an. Verwenden Sie zum Beispiel einfach den Cocoa-Weg: stackoverflow.com/questions/412562/…bash
sich selbst zu reparieren.Ich habe dieses Tool erstellt , sobald ich von dieser Schwachstelle gehört habe. Es stellt Ihnen einen Link zu einem Artikel zur Verfügung, mit dem Sie Ihre Shell patchen können, wenn das Tool feststellt, dass Sie anfällig sind.
Erfordert Mac OS X 10.6 und höher.
kein Hang
mmmmmm
Haarboot
BEI