Sind Macs anfällig für den Bash-Shellshock-Bug?

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?

Um zu sehen, welche Aktionen sich auf OSX auswirken, siehe security.stackexchange.com/questions/68123/…
Die Frage wurde aktualisiert, sodass sie weniger ein Betrüger als vielmehr eine Bitte um Rat für Laien ist.
Apple hat jetzt einen Fix veröffentlicht: support.apple.com/kb/DL1769

Antworten (5)

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 bashMac 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 bashein 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 bashUpdate ebenfalls enthält !

Hinweis: Sicherheitsupdate 2014-005 enthält die Sicherheitsinhalte von OS X Bash Update 1.0

"oder ein Webserver, der serverseitiges Skripting ausführt" - oder eine Anwendung laufen lassen, die auf einem offenen Port lauscht, der RPC-Aufrufe zulässt, die schließlich Shell-Befehle ausführen. Dies kann eine beliebige Anzahl von Dingen sein, da es viele Standardanwendungen gibt, die ihren RPC ausführen. Ich finde diese Antwort sehr naiv. Es ist sehr einfach, versehentlich "einen Webserver auszuführen", während eine Anwendung ausgeführt wird, die eine Client-Server-artige Sache macht.
Ist das Gastkonto standardmäßig aus der Ferne zugänglich?
@IanC. Können Sie ein Beispiel geben, wo OS X standardmäßig wirklich anfällig wäre? Würde zum Beispiel so etwas wie WebEx oder GotoMeeting auch nur in die Nähe von Bash-Fähigkeiten kommen? Der Punkt ist, dass ich mir kein einfaches OS X-Installationsszenario vorstellen kann, das wirklich Dinge aufdecken würde. Kanst du?
Das Gastkonto ist für ssh nicht verfügbar. Tatsächlich ist es nicht einmal möglich, es ssh, IIRC, zur Verfügung zu stellen. Tatsache ist, dass die Bash-Schwachstelle für die überwiegende Mehrheit der OS X-Benutzer überhaupt kein Problem darstellt. Für diejenigen von uns, bei denen es ein Problem ist, müssen wir bash neu kompilieren, sobald ein getesteter Fix verfügbar ist, aber das ist nicht jetzt.
@JakeGould alles, was es braucht, ist ein laufender Server, der möglicherweise Befehle über die Shell ausführt. Plex zum Beispiel ist dort so einer – wo es in Echtzeit transkodiert und Videos von Ihrem Mac bereitstellt. Die Umcodierung erfolgt über einen Shell-Befehl und verfügt über eine offene API für die Interaktion mit ihm, die nicht authentifiziert ist. Knurren ist ein weiteres Beispiel. Offene Ports mit Listenern sind überall auf Ihrem Mac. Sogar nicht lauschende Anwendungen können unbeabsichtigt aussteigen, wenn sie Befehle erhalten.
@IanC. Okay, faire Beispiele. Aber Sie verfehlen immer noch den Punkt: Wie kann man eine solche Schwachstelle in jedem von Ihnen bereitgestellten Beispiel ausnutzen? In jedem Fall benötigt ein Benutzer zunächst Zugriff auf das System und was dann? Ich bin nicht leichtfertig, aber ich verstehe immer noch nicht, was das Risiko tatsächlich wäre? Jemand – zum Beispiel – müsste sich durch die Plex-API schlängeln, um dann was genau in Bash zu tun, um etwas außerhalb der normalen Benutzerrechte und Zugriffsrechte zu tun?
@danielAzuelos „Jeder ist angreifbar, solange das Gastkonto offen ist :[!“ Das Gastkonto hat damit nichts zu tun bash. Worauf basiert die Angst also genau? Auch wenn das Gastkonto offen & irgendwie bashnutzbar 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.
+1 für eine Stimme der Vernunft! Ja, technisch gesehen ist dies ein Problem, aber viel Glück beim Ausnutzen, es sei denn, Sie führen einen Dienst aus, der das Ausführen beliebiger Befehle zulässt, und wissen Sie was? Du hast schon ein Problem! Ich weiß, dass dies etwas schwerwiegender ist, da das Setzen einer Variablen niemals Code ausführen sollte, aber die meisten Programme übergeben Argumente als Argumente, nicht Umgebungsvariablen.
"Das ist nur erschreckend, wenn man das nicht rational durchdenkt." kann nicht unterschätzt werden. Dieselbe Regel gilt für alle Sicherheitsmoden, Computersicherheit, innere Sicherheit, persönliche Sicherheit. Menschen sind notorisch leicht in Panik zu versetzen und sehr schwer wieder herauszubekommen.
→ JakeGould: Wenn ein Gastkonto aktiviert ist, kann ein Benutzer es verwenden. Dann bashkann 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 sshZugriff ist ebenfalls deaktiviert :).
@danielAzuelos Das ist völlig falsch: „Dann kann er durch die Verwendung der Bash-Schwachstelle jeden Daemon zwingen, der als Root läuft und eine Bash verwendet, um jeden Befehl mit den Root-Rechten auszuführen.“ Woher kommt die Idee, dass dieser Shellshock/Bash-Fehler zu erhöhten Privilegien führt? Das tut es nicht. Wenn sich jemand als Gast auf einem ungepatchten System anmeldet, führt er einfach Code als Gast aus. Wenn ein Gast irgendwie ein Root-Konto bearbeiten oder beeinflussen kann, liegt dieser Fehler nicht an Shellshock/Bash, sondern an der mangelnden Sicherheit des Systems im Allgemeinen.
-1 Sehr falsch. Es gibt viele Tools, die Bash verwenden: Installationsskripte verwenden normalerweise Bash, wodurch Risiken für die Eskalation von Berechtigungen entstehen. Es sollte davon ausgegangen werden, dass alle Server bash verwenden, sofern Sie nichts anderes wissen , nicht nur sshd. Insbesondere Apache könnte mit Bash eine Remote-Schwachstelle schaffen. usw.
Es gibt wahrscheinlich auch Rechteausweitungsrisiken von einem Gastkonto. Aber wen interessiert das? Jeder Mac OS X-Computer ist extrem anfällig, sobald Benutzer Zugriff erhalten, insbesondere lokale Benutzer. Es sind Server-Daemons, die Sie erschrecken sollten, nicht nur sshd, sondern alle Server-Daemons.
@JeffBurdges „Apache könnte mit Bash eine Remote-Schwachstelle erstellen. etc." Wie? Sie sagen, dass Eskalationsrisiken bestehen, aber wie könnte ein nicht privilegierter Benutzer seine Berechtigungen auf diese Weise eskalieren? Apache hat keine besonderen Privilegien und muss bewusst über Konfigurations- oder Sudo-Rechte geändert werden, um Root-Dinge ausführen zu können.
Apache-Module, CGI-Skripte usw. rufen üblicherweise Bash auf. Sehr effektiver Hack hier: twitter.com/JZdziarski/status/515135854436962304 Und selbst wenn Ihre Apache-Konfiguration Bash im Normalbetrieb nicht aufruft, ist nicht abzusehen, wozu ein Angreifer sie überzeugen kann.
Wie ich unten sagte, sollte angenommen werden, dass ALLE Server Bash aufrufen, sofern nicht das Gegenteil bewiesen ist. Und Mac OS X ist voll von Privilegien-Eskalations-Exploits, sobald Sie eine Shell erreichen.
Tatsächlich ist Ihre Antwort völlig falsch !!! Die normale Verwendung von ssh ist nicht anfällig, da Sie bereits eine Shell öffnen, nur der eingeschränkte Anmeldebefehl von ssh ist anfällig. Fast kein Linux-Benutzer weiß davon, so wie es kein Mac-Benutzer tut.
@JeffBurdges Die von Ihnen bereitgestellten Beispiele beziehen sich auf Server-Exploits. Und wenn Sie den Threads zu diesen tatsächlich folgen, ist alles ziemlich theoretisch, ohne dass jemand bestätigt, dass sie funktionieren. Für einen Desktop-Benutzer von Mac OS X ist die Panik übertrieben. Aber wenn Sie ein Serveradministrator sind, müssen Sie sich Sorgen machen. Aber bitte, ermutigen Sie Anfänger weiterhin, ihre eigenen bashmanuell 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.
@JeffBurdges Wenn Sie glauben, dass meine Antwort eine Gefahr ist, beweisen Ihre OCD-Posts hier das Gegenteil. Wie gesagt, treten Sie einen Schritt zurück und sehen Sie sich das vernünftig an: Dies ist ein Risiko für SERVER. Nicht für KUNDEN. Dieses Board und diese Frage beziehen sich auf Mac OS X und hauptsächlich auf die CLIENT-Seite. Stimmen Sie also ab oder markieren Sie, aber Ihr zwanghaftes, panisches Verhalten spricht Bände gegen den Fall, den Sie vorbringen.
Ich habe bereits erwähnt, dass das Neukompilieren von Bash selbst zu viel des Guten ist. Die richtige Reaktion für gewöhnliche Desktop-Benutzer besteht darin, die Firewall einzuschalten und Freigabedienste auszuschalten ODER zu akzeptieren, dass sie der von ihrem Router bereitgestellten Firewall vertrauen. Das sagt mein Kommentar. Sie wählen einen wahrscheinlich normalerweise nicht anfälligen Server aus, ssh, und ignorieren, dass eine Menge Leute rudimentäre lokale Webserver mit unbekanntem aktivem Skripting betreiben.
@JeffBurdges „Ich habe bereits erwähnt, dass das Neukompilieren von Bash selbst zu viel des Guten ist. Die richtige Antwort für für ” Ihre OCD-Kommentare sprengen Ihre Möglichkeiten zum Posten. Entweder beruhigen oder aufhören. Ich lösche meine Antwort nicht. Wenn Sie damit nicht einverstanden sind, gehen Sie damit um. Wenn Sie der Meinung sind, dass Ihre Antwort auffälliger ist, freue ich mich auf den massiven Strom von positiven Stimmen, die Ihr weiser, besonnener Rat sammeln wird. Prost!
ha. SE-Bearbeitungsfelder mögen die Rechtschreibkorrektur des Mac nicht, erzeugen immer vorzeitige Kommentare. Das tut mir leid. Wie auch immer..
@JeffBurdges: Warum sollte ein böswilliges Installationsskript diesen Exploit verwenden ? Wenn der Benutzer ein bösartiges Installationsskript (ein Trojanisches Pferd) installiert, muss der Code diesen Fehler nicht aufrufen, er wird trotzdem root.
@nyuszika7h Ahhhh! In Ordnung. Das ist genau das, wonach ich gesucht habe. Wenn ein DHCP-Server gehackt und dieser Bash-Exploit eingesetzt wird, könnten sie im Grunde ein Opfer sein, wenn Bash nicht gepatcht wird. Ausgezeichnetes Beispiel. Sie sollten dies als Antwort für eine positive Abstimmung posten.
Hier dreht sich alles um FUD, Wahrnehmung und Realität. Die Risiken für 99 % der Mac-Benutzer bestehen nicht. ABER: Das ist keine Entschuldigung dafür, dass Apple eine ordentliche Lösung hinauszögert. Nach dem iCloud-Gate-Brouhaha hätte ich gedacht, dass die Geschäftsleitung von Apple ernsthaft besorgt wäre über etwas, das Apples Image trübt. Als normaler Benutzer würde ich mir Sorgen machen, dass Apple dieses Loch nicht stopft, zumal es so einfach ist, mit einer einzigen Codezeile zu beobachten!
@AlbertGodfrind „…Apple wäre ernsthaft besorgt über etwas, das Apples Image trübt.“ Apple kümmert sich 2014 nicht mehr so ​​sehr um Probleme mit der Desktop-Nutzung wie früher. Es dreht sich alles um iDevices, iOS und die Kommerzialisierung dieses Raums. Das ist eine ganz andere Diskussion, aber das exponentielle Wachstum von Apple hat ihre Sicht auf den Nicht-iOS-Markt verzerrt.
Für VMWare Fusion (das normalerweise nur auf Clients installiert wird) ist ein öffentlicher Exploit zur Rechteausweitung verfügbar: packetstormsecurity.com/files/128425/…
@ScottDudley: Das hat nichts mit VMWare zu tun. Und es hat nichts mit Mac OS zu tun. Es zeigt nur, dass, wenn Sie Linux in einer VM ausführen, diese Installation empfindlich auf die Bash-Schwachstelle reagiert, wenn sie noch nicht gepatcht wurde. Ich betreibe mehrere Linux-VMs auf meinem Laptop (mit Virtualbox) und sie sind alle anfällig, da ich sie noch nicht gepatcht habe. Sie betreiben keinen Webserver und sind nur von meinem Host aus zugänglich.
@AlbertGodfrind, das ist falsch - bitte lies die Seite noch einmal. Diese Seite behauptet, einen Exploit zur Eskalation von Privilegien für OS X zu enthalten (ich gebe zu, dass ich ihn nicht getestet habe). Es scheint ein Exploit gegen die VMWare Fusion-Installation unter OS X zu sein, und es hat überhaupt nichts mit Linux zu tun. Ein schnelles Lesen des Codes deutet darauf hin, dass Fusion möglicherweise nicht einmal ausgeführt werden muss, um es auszunutzen.
@ScottDudley Ihre Einschätzung des Exploits mit VMWare Fusion ist richtig. Aber völlig unklar, wie eine Nutzlast zu einer Host-Maschine gelangen würde, um den Schaden anzurichten. Wie würde der Exploit überhaupt mit der realen Nutzung auf einem Client- oder sogar einem Servercomputer beginnen?
@JakeGould Es handelt sich um eine Eskalation der Berechtigungen, sodass die Angriffsfläche erweitert wird, und jetzt kann eine Schwäche in jedem Benutzerprozess damit kombiniert werden, um root zu werden. Zum Beispiel haben die Leute oben darüber gesprochen, wie wenn httpd ausgenutzt würde (was bei Verwendung des Bash-Fehlers nicht passieren muss!), dann würde Ihnen nur der Userland-Zugriff übrig bleiben, der als Apache-Benutzer ausgeführt wird. Wenn Sie Fusion haben und bash nicht gepatcht ist, können Sie, sobald Sie einen Benutzer erhalten, auch root werden. Wählen Sie die Schwachstellen in verschiedenen Userland-Prozessen auf <=10.9.4 aus.
@ScottDudley Sie verpassen den Punkt: Wie würde dieses Skript überhaupt zu dem Punkt kommen, an dem es das tun könnte? Dieses Skript kann nicht außerhalb des Computers sein, auf dem VMWare Fusion ausgeführt wird, richtig? Wie kommt es ins Innere?
@JakeGould, Sie nutzen jede Schwachstelle in Benutzerprozessen aus (die durch Shellshock oder durch ein anderes Problem mit einem Userland-Prozess entstehen kann - beispielsweise eine der Schwachstellen im vorherigen Link). Deshalb heißt es Eskalation der Privilegien: en.wikipedia.org/wiki/Privilege_escalation
@ScottDudley Ich verstehe, was Privilegienausweitung ist. Ich verstehe das Risiko. Hast du meine Antwort sowie die Kommentare oben gelesen? Aber in dem Fall, den Sie hervorheben, ist es für mich schwer zu verstehen, wie ein einfacher OS X-Computer für das, was Sie zeigen, anfällig wäre. Wenn Sie das nicht verstehen, tut es mir leid. Lesen Sie nach, wie dieser Fehler funktioniert, und stellen Sie fest, dass er für Benutzer von Mac OS X-Clients keine so große Sache ist, selbst wenn er nicht gepatcht wird.
@JakeGould, ja, ich habe die Antwort gelesen und verstehe die Nuancen. Hier ist ein einfaches Beispiel. Einige Spambots senden eine bösartige PDF-Datei per E-Mail an Ihre @mac.comAdresse. 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.
@ScottDudley Okay, jetzt hast du es klarer gemacht! Ich würde jedoch vorschlagen, dass Sie diese Informationen in einer Antwort hier veröffentlichen, damit andere die Randrisiken besser verstehen können.

Ja!

Geben Sie dies in Ihre Shell ein

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Wenn es heißt, vulnerabledann 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

Danke. Ich habe die Frage aktualisiert: Wenn wir feststellen, dass wir anfällig sind, wie kann ein Mac-Benutzer das Problem beheben?
@abbyhairboat Habe meine Antwort gepostet. Sofern Sie keinen Server betreiben, der der Außenwelt ausgesetzt ist, besteht praktisch kein Risiko. Serveradministratoren sind diejenigen, die sich darum kümmern müssen.
→ abby: siehe diese verwandte Antwort: apple.stackexchange.com/a/146851/22003 .
Probieren Sie dies 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.
Sieht so aus, als wäre zsh auch anfällig.
@ Mark nein, zsh ist sicher. Sie müssen "bash -c" durch "zsh -c" ersetzen, um es zu testen.
Ich habe Bash 3.2 von Mac OS X gepatcht und Anweisungen hier eingefügt: github.com/ido/macosx-bash-92-shellshock-patched/blob/master/…
@TraneFrancks: Apple verwendet Bash in /bin/sh... Sie müssen beide /bin/sh ersetzen und /bin/bashgeschützt werden. /bin/shist eigentlich problematischer, da es die Shell ist, die Skriptsprachen wahrscheinlich verwenden, um Shell-Befehle auszuführen.
@Joe, ich bin mir bewusst, was gepatcht werden muss. Ich habe hier ein Tutorial zu dem Vorgang geschrieben: apple.stackexchange.com/a/146943/91441 Der Artikel war auch hier, wurde aber von Moderatoren als Duplikat gelöscht. Das Problem war, dass das Erstellen von Apple-Quellen mit xcodebuild beides bashund shin einem einzigen Schritt erledigt. Das Erstellen aus Vanilla-GNU-Quellen erfordert separate Kompilierungen. Außerdem bashbughat es unter OS X einen anderen Installationsort als die GNU-Ausgabe, sodass auch diese verschoben werden muss.
@nyuszika7h Ahhhh! In Ordnung. Das ist genau das, wonach ich gesucht habe. Wenn ein DHCP-Server gehackt und dieser Bash-Exploit eingesetzt wird, könnten sie im Grunde ein Opfer sein, wenn Bash nicht gepatcht wird. Ausgezeichnetes Beispiel. Sie sollten dies als Antwort für eine positive Abstimmung posten.

Überprüfen Sie als Endbenutzer Folgendes:

  • Ihr Gastkonto ist deaktiviert:

    Systemeinstellungen > Benutzer & Gruppen > Gastbenutzer

  • Ihr sshZugang 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 bashSchwachstelle behebt.

Diese sind irrelevant. Beide gewähren Benutzern naturgemäß Zugriff auf das Ausführen von Befehlen auf dem System. Wenn Sie sie also aktiviert haben, ist es Ihre Absicht, Benutzern das Ausführen von Befehlen zu ermöglichen. Der Shellshock-Bug ist ein Mittel für Benutzer, die nicht beabsichtigt haben, Befehle auszuführen, um dies tun zu können, z. B. ein Benutzer des von Ihnen ausgeführten Webservers. Ihre Antwort sollte also "Webfreigabe deaktivieren" lauten (aber das ist nur eine Sache, die Sie überprüfen sollten).
Ich bin verärgert, dass Apple nicht empfohlen hat, diese Einstellungen zu deaktivieren. Wer würde sie ermöglichen? Ich würde. Ich bin ein Mac-Benutzer seit 1986, ein Vollzeit-Entwickler von Webanwendungen (also ist ssh mein Leben) und ein Vater (also ist ein Gastkonto für die Kinder keine so schlechte Idee). Ich kenne viele Leute, die in dieser Hinsicht wie ich sind und Apple-Laptops verwenden. Willst du uns verlieren? Diese Schwachstelle offen zu lassen, ist eine gute Möglichkeit.

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 bashgeistesabwesend 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:

  • Deaktivieren Sie ALLE Freigabedienste in den Freigabeeinstellungen.
  • Aktivieren Sie die Firewall unter Sicherheit und Datenschutz.

Wenn Sie besonders besorgt sind, drücken Sie die FirewallOptionstaste, um:

  • Deaktivieren Sie Automatically allow signed software to receive incoming connections.
  • Überprüfen Sie 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". :)

Es besteht keine Chance, dass Macs für einen Angriff mit DHCP anfällig sind, da Bash nicht verwendet wird.
Wie kannst du das Wissen? Die anfängliche Empfehlung war ein anfälliger DHCP-Client. Und viele Artikel spekulieren, dass Mac OS X- und/oder iOS-DHCP-Clients anfällig sein könnten. Bis zum Beweis des Gegenteils sollte davon ausgegangen werden, dass alle Server anfällig sind.
Nein, das sollten sie nicht sein; das ist absoluter FUD. Sie können sowohl den Open-Source-Code für die DHCP-Implementierung von OS X untersuchen als auch Systemaufrufe selbst messen, um dies zu überprüfen.
@JeffBurdges, OS X hat seit 10.3 Shell Exec nicht mehr mit DHCP verwendet, und davor war Bash nicht auf dem System installiert. DHCP unter OS X ist bei Shellshock einfach kein Problem. (Eine Sorge weniger. :))
→ Jeff: Bitte beachte: 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 dhcpdvon MacOS X … aber diese allein :(.
Nicht ganz. Man muss die Symbole überprüfen, die von der Bibliothek aufgerufen werden, die otool -L /usr/libexec/bootpdmeldet, dass sie einen execAufruf enthält. Und der stringsBefehl ist sinnlos, da Umgebungsvariablen die aufgerufene Shell bestimmen. Ich bin jedoch beeindruckt, dass keine Bibliotheksanrufe gefallen haben system.
@JeffBurdges würde das Hinzufügen von "|SHELL" zur egrep-Suchzeichenfolge (für die Zeichenfolgenausgabe) das nicht erfassen?
Außerdem otool -L- die einzige Ausgabe, die ich davon erhalte, ist eine Liste von Bibliotheken (CoreFoundation, SystemConfiguration, OpenDirectory, libresolv.9.dylib und libSystem.B.dylib)
Ja strings .. | grep SHELList viel nützlicher als bash, aber nicht absolut. Imho nm -a ... | grep systemist das Wichtigste und exechilft 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/…
Ist keine so große Sache, aber ihr sagt immer wieder Dinge, die technisch falsch sind. Sie können nicht 100% sicher sein, ohne mehr Beinarbeit zu leisten. Apple hat vielleicht diese Kleinarbeit für ihre Server geleistet, die mit aktivierter Firewall aktiv bleiben, bevor sie ihre Erklärung herausgaben, aber ich bezweifle, dass sie überhaupt so viel getan haben. Es ist wahrscheinlich in Ordnung, aber man sollte Apple trotzdem die Hiebe dafür brechen, dass es so schmerzhaft langsam ist, bashsich selbst zu reparieren.
Ich bin ein Snow Lion-Benutzer und sehe, dass Apple nichts für 10.6.8 geplant hat. Aber ich habe jetzt den Systemeinstellungen einen Besuch abgestattet, die ich in Ihren Vorschlägen auf die paranoideste Stufe geändert habe. Danke Jeff.

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.

Vielleicht liegt es nur an mir ... aber die Idee, den Code einer zufälligen Person zum Testen auf einen Exploit auszuführen, scheint eine wirklich schlechte Idee zu sein, wenn Sie genauso einfach einen String (der eindeutig nur den Test ausführt und nichts weiter) in a einfügen kann Terminalfenster.
Ich stimme zu, deshalb befindet sich die Quelle auf code.google.com/p/shellshock-check
Manchmal kann es jedoch eine Benutzerfreundlichkeit zum Testen mehrerer Systeme bieten.
Ich sehe den Vorteil dieser Sache nicht. Das Überprüfen der Schwachstelle ist viel einfacher, wenn Sie eine einfache Befehlszeile in das Terminalfenster einfügen.
Wenn Sie jedoch mehrere Computer testen, insbesondere in meinem Fall, wie ich es tue, ist es viel einfacher, ein Flash-Laufwerk einzulegen und Shellshock Check.app zu öffnen, als Safari zu öffnen, den Bash-Befehl zum Überprüfen nachzuschlagen, dann Terminal zu öffnen und diesen einzufügen Befehl und drücken Sie dann die Eingabetaste. Es ist viel schneller, ein Flash-Laufwerk anzuschließen und eine Anwendung zu öffnen.
Wenn Sie mehrere Systeme überprüfen müssen, verwenden Sie einfach ein einfaches Shell-Skript, um die Schwachstelle zu testen, speichern Sie es auf Ihrem Memory Stick und führen Sie es vom Stick aus (öffnen Sie es einfach, um es auszuführen).
Dann sollten Sie dieses Flash-Laufwerk vielleicht auf den BadUSB-Bug überprüfen ( srlabs.de/badusb ) :-)
Sind Macs anfällig für den Bash-Shellshock-Bug?
AntwortenHierDatenschutz-Bestimmungen1y, 0v