Da Bash 3.2 (die Version von OS X ausgeliefert) ist anfällig für die Remote - Ausführung Exploits bekannt als „Shell Shock“ ( CVE-2014-6271 und CVE-2014-7169 ) wie umbauen ich Bash und sichere mein System vor einem offizieller Apple Patch?

UPDATE: Beachten Sie, dass Apple jetzt den offiziellen Patch veröffentlicht hat. Siehe unten für Details.

Status

Apple hat Bash-Sicherheitsupdates für Shellshock und verwandte Sicherheitslücken als " OS X bash Update 1.0 " veröffentlicht. Sie können über ein normales Systemupdate für Benutzer von OS X Mountain Lion 10.8.5 oder OS X Mavericks 10.9.5 (im Sicherheitsupdate 2014-005 enthalten ) installiert und auch manuell installiert werden. Offizielle Apple-Fixes sind auch für OS X Lion 10.7.5 und OS X Lion Server 10.7.5 verfügbar, diese sind jedoch nur per manuellem Download verfügbar. Die Sicherheitsupdates sind abhängig von der Betriebssystemversion über verschiedene URLs verfügbar:

• http://support.apple.com/kb/DL1769 - Mavericks (10.9.5 und höher)
• http://support.apple.com/kb/DL1768 - Berglöwe (10.8.5)
• http://support.apple.com/kb/DL1767 - Lion & Lion Server (10.7.5)

(Wenn neue Patches veröffentlicht werden, fügen Sie diese hier ein. Bitte bewahren Sie auch diese vorhandenen als Referenz auf.)

Der Apple-Patch behebt Shellshock und mehrere andere Sicherheitslücken und ist für die meisten Menschen in Ordnung. Die Leute können hier aufhören zu lesen.

JEDOCH hat die Aufmerksamkeit, die durch den Shellshock-Bug auf Bash gelenkt wurde, viele Forscher veranlasst, sich intensiv mit Bash zu beschäftigen, und es werden immer mehr (schwer auszunutzende) Sicherheitslücken gefunden. Wenn Sie sich große Sorgen über die Sicherheit machen (weil Sie möglicherweise OS X Server ausführen, um eine öffentlich zugängliche Website zu hosten), sollten Sie versuchen, mit den Sicherheitsanfälligkeiten und Patches Schritt zu halten, indem Sie die Bash selbst kompilieren. Ansonsten mach dir keine Sorgen.

Achten Sie darauf, dass Apple in Zukunft ein weiteres Update veröffentlicht, um zu verhindern, dass der Staub nachlässt, dass weitere Sicherheitslücken gefunden werden.

Es gibt einen offiziellen Satz von Patches für Bash 3.2, Patches 52, 53 und 54 (die den Bash 4.3-Patches 25, 26 und 27 entsprechen), mit denen sowohl CVE-2014-6271 als auch CVE-2014-7169 behoben werden können. sowie das unten angezeigte "Game Over". Dies wurde von mir getestet ( @alblue ) und der Beitrag wurde entsprechend aktualisiert (und dann wurden zusätzliche Aktualisierungen vorgenommen: siehe Revision 41 für den Beitrag, der bei Patch 54 endet ).

Viele zusätzliche Sicherheitslücken wurden gegen Bash gemeldet. Laut Michal Zalewskis Post, wenn Sie Patch 54 (und vermutlich Apples offiziellen Patch) haben, "hat es keinen Sinn, über den Status dieser einzelnen Bugs nachzudenken, da sie kein Sicherheitsrisiko mehr darstellen sollten:"

• CVE-2014-6271 - Original RCE gefunden von Stephane. Korrigiert durch bash43-025 und entsprechende Einträge vom 24. September für andere Versionen.

• CVE-2014-7169 - Fehler bei der Dateierstellung / beim Token-Verbrauch, der von Tavis gefunden wurde. Behoben von bash43-026 & co (26. September)

• CVE-2014-7186 - Ein Absturz, bei dem Florian und Todd wahrscheinlich mehr als 10 Sekunden Risiko eingegangen sind. Behoben durch bash43-028 & co (1. Oktober).

• CVE-2014-7187 - ein nicht abstürzender, wahrscheinlich kein Sicherheitsrisiko durch Florian. Behoben durch bash43-028 & co (1. Oktober).

• CVE-2014-6277 - Nicht initialisiertes Speicherproblem, mit ziemlicher Sicherheit RCE von Michal Zalewski. Noch kein spezieller Patch.

• CVE-2014-6278 - Befehlseinspritzung RCE gefunden von Michal Zalewski. Noch kein spezieller Patch.

Es wird ziemlich verwirrend. Glücklicherweise hat Chet Ramey, der offizielle Betreuer der Bash, einen CVE für das Patch-Mapping veröffentlicht . Sein Beitrag bezieht sich auf Patches für Bash 4.3. Ich (@OldPro) habe sie in Patches für Bash 3.2 übersetzt, was auch für OS X gilt. Seit diesem Beitrag hat er Patch 57 veröffentlicht, also habe ich Folgendes hinzugefügt:

 bash32-052      CVE-2014-6271                           2014-09-24
 bash32-053      CVE-2014-7169                           2014-09-26
 bash32-054      exported function namespace change      2014-09-27 ("Game Over")
 bash32-055      CVE-2014-7186/CVE-2014-7187             2014-10-01
 bash32-056      CVE-2014-6277                           2014-10-02
 bash32-057      CVE-2014-6278                           2014-10-05

Siehe David A. Wheelers Beitrag für eine Zeitleiste und detailliertere Informationen.

@alblue hat über Patch 55 Build-Anweisungen veröffentlicht. Ich (@OldPro) habe die Patches 56 und 57 zu den Anweisungen hinzugefügt, sie jedoch nicht getestet.

Testen auf die ursprüngliche Sicherheitsanfälligkeit

Sie können feststellen, ob Sie für das ursprüngliche Problem in CVE-2014-6271 anfällig sind, indem Sie diesen Test ausführen:

$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

Die obige Ausgabe ist ein Beispiel für eine nicht anfällige bashVersion. Wenn Sie das Wort vulnerablein der Ausgabe dieses Befehls sehen, ist Ihr bashanfällig und Sie sollten aktualisieren. Im Folgenden finden Sie eine anfällige Version von OS X 10.8.5:

Testen auf die neue Sicherheitsanfälligkeit

Es wurde ein Update auf den Original - Beitrag 3.2.52 und Bash (1) ist nach wie vor anfällig für eine Variation der Verwundbarkeit, definierte in CVE-2014-7169

$ rm -f echo
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Thu 25 Sep 2014 08:50:18 BST

Die obige Ausgabe ist ein Beispiel für eine anfällige bashVersion. Wenn Sie ein Datum in der Ausgabe dieses Befehls sehen, ist Ihr bashanfällig.

Deaktivieren von automatisch importierten Funktionen, um "Game Over" zu verhindern

Die Forscher stellten fest, dass ein Skript, ohne es als Sicherheitsanfälligkeit einzustufen, mithilfe von automatisch importierten Funktionen eine Funktion in einer Subshell hijacken kann:

$ env ls="() { echo 'Game Over'; }" bash -c ls
Game over

Der obige Code auf einem betroffenen System würde Game Overanstelle der Verzeichnisliste angezeigt, die Sie von erwarten würden ls. Offensichtlich echo 'Game Over'könnte durch jeden schändlichen Code, den Sie wollen, ersetzt werden. Dies wurde als "Game Over" -Fehler bekannt.

Vor der Verfügbarkeit von Patch 54 haben sowohl NetBSD als auch FreeBSD die Bash-Funktionen für den automatischen Import standardmäßig deaktiviert, teilweise um "Game Over" zu verhindern, hauptsächlich aber, um weitere Fehler im Parser (wie CVE-2014-7169 ) so wie sie waren zu enthalten weiterhin entdeckt und ein neues Kommandozeilen-Flag hinzugefügt--import-functionsum das alte Standardverhalten wieder zu aktivieren. Ich (@alblue) habe einen Patch (gegen 3.2.53) vorbereitet, den andere verwenden können, wenn sie dieses Verhalten ebenfalls übernehmen möchten, und habe ihn unten aufgeführt. Standardmäßig ist dieser Patch im folgenden Build-Skript nicht aktiviert. Ich (@OldPro) halte diesen Patch nicht länger für notwendig oder für eine gute Idee, da er die Abwärtskompatibilität aufhebt und die Schwachstellen, vor denen er schützt, durch Patch 54 und frühere Patches sehr gut behoben werden. Wenn Sie diesen inoffiziellen Patch aktivieren, wird verhindert, dass zukünftige Patches angewendet werden .

(Hinweis für fragende Redakteure; bitte aktivieren Sie dies nicht standardmäßig, da es sich um einen inoffiziellen Patch handelt.)

a0c5c4d66742fddd0a35001cb91798a5fbf8a2f5 import_functions.patch

Der Patch kann aktiviert werden, indem er ausgeführt wird, export ADD_IMPORT_FUNCTIONS_PATCH=YESbevor der Build ausgeführt wird. Beachten Sie, dass das Aktivieren dieses Patches Patch 54 und alle zukünftigen Patches deaktiviert, da nicht garantiert werden kann, dass zukünftige Patches mit dem inoffiziellen Patch kompatibel sind.

Apple Patch hat eine Art Game Over-Schwachstelle

Wie von @ake_____ auf Twitter hervorgehoben, ist der offizielle Apple-Patch immer noch anfällig für das Aussterben von ausführbaren Dateien in der Umgebung:

$ env '__BASH_FUNC<ls>()'="() { echo Game Over; }" bash -c ls
Game Over

Der Benutzer sollte selbst entscheiden, wie wichtig dies ist. Ich (@OldPro) denke, es gibt keinen Grund zur Sorge, da für dieses Verhalten kein Exploit bekannt ist (es wurde nicht einmal eine CVE-ID vergeben), da unprivilegierte entfernte Angreifer im Allgemeinen nicht den Namen einer Umgebungsvariablen festlegen können und Angreifer mit Berechtigungen dies nicht können Verwenden Sie dies, um Berechtigungen zu erlangen, die sie noch nicht haben (zumindest nicht ohne eine zusätzliche Sicherheitsanfälligkeit auszunutzen).

Um ein wenig Hintergrund zu bieten, können Sie mit bash Funktionen definieren und diese Funktionen über den export -fBefehl in Subshells exportieren . Dies wurde früher implementiert, indem eine Umgebungsvariable mit demselben Namen wie die Funktion erstellt wurde, deren Wert auf die Funktionsdefinition gesetzt wurde. Damit

$ ls () { echo 'Game Over'; }
$ export -f ls
$ echo $ls
Game Over

Dies geschah, weil export -f lseine Umgebungsvariable namens erstellt wurde ls. Die "Game Over" -Anfälligkeit bestand darin, dass Sie diese Umgebungsvariable direkt erstellen konnten, ohne zuvor die Funktion definieren zu müssen. Wenn Sie also den richtigen Variablennamen eingeben konnten, konnten Sie einen Befehl missbrauchen. Apple hat versucht, dieses Problem zu beheben, indem es schwierig war, eine Variable mit dem richtigen Namen zu erstellen. Der offizielle Bash-Patch 54 macht es tatsächlich unmöglich, eine Variable mit dem richtigen Namen zu erstellen, indem Variablennamen verwendet werden, %die ein Zeichen enthalten, das in einem Variablennamen nicht zulässig ist, wodurch exportierte Funktionsdefinitionen effektiv in einen anderen reservierten Namespace verschoben werden.

Wenn Ihnen keines der oben genannten Dinge Sinn macht, machen Sie sich darüber keine Sorgen. Der Apple-Patch ist vorerst in Ordnung.

System-Binärdateien

OS X 10.9.5 (die aktuellste stabile Version) wird mit Bash v3.2.51 ausgeliefert:

$ bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.

Sie können Bash wie folgt beziehen und neu kompilieren , sofern Sie Xcode installiert haben (und xcodebuildmindestens einmal ausgeführt haben, um die Lizenz zu akzeptieren):

$ # If you want to disable auto-imported functions, uncomment the following
$ # export ADD_IMPORT_FUNCTIONS_PATCH=YES
$ mkdir bash-fix
$ cd bash-fix
$ curl https://opensource.apple.com/tarballs/bash/bash-92.tar.gz | tar zxf -
$ cd bash-92/bash-3.2
$ curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 | patch -p0    
$ curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-053 | patch -p0  
$ # See note above about ADD_IMPORT_FUNCTIONS_PATCH
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] && curl http://alblue.bandlem.com/import_functions.patch | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-054 | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-055 | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-056 | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-057 | patch -p0
$ cd ..
$ # Note: DO NOT ADD SUDO TO XCODEBUILD HERE
$ xcodebuild
$ build/Release/bash --version # GNU bash, version 3.2.57-release
$ build/Release/sh --version   # GNU bash, version 3.2.57-release
$ sudo cp /bin/bash /bin/bash.old
$ sudo cp /bin/sh /bin/sh.old
$ sudo cp build/Release/bash /bin
$ sudo cp build/Release/sh /bin

(Hinweis: Sie können dies ausführen, indem Sie den obigen Codeblock kopieren und einfügen, in Terminal gehen und dann ausführen pbpaste | cut -c 2- | sh. Seien Sie jedoch immer vorsichtig, wenn Sie zufällige Skripte aus dem Internet ausführen ...)

Danach sollte die Bash-Version v3.2.57 sein:

$ bash --version
GNU bash, version 3.2.57-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.

Aus Sicherheitsgründen und nach dem Testen empfehle ich, chmod -xdie alten Versionen zu verwenden, um sicherzustellen, dass sie nicht wiederverwendet werden, oder sie auf eine Sicherungssite zu verschieben.

$ sudo chmod a-x /bin/bash.old /bin/sh.old

Andere Antworten bieten Lösungen für Benutzer von MacPorts oder Homebrew. Diese beheben das Problem nicht, sondern installieren lediglich zusätzliche Versionen von Bash. Bitte lesen Sie diese Antworten, wenn Sie diese speziell aktualisieren möchten.

Vielen Dank

Vielen Dank an Chet, der sich um Bash kümmert und diese Patches zur Verfügung stellt. Vielen Dank an alle anderen, die dies kommentiert und im Laufe der Zeit verbessert haben.

Jetzt hat Apple das echte Update veröffentlicht, obwohl dies immer noch nützlich sein könnte. Da sie nur ein Update für Lion und höher veröffentlicht haben und der offizielle Patch GNU Bash, Version 3.2.53 (1), zur Verfügung stellt (x86_64-apple-darwin13), ist der Game-Over-Bug immer noch etwas anfällig. Zu diesem Zeitpunkt ist es wahrscheinlich sicherer, eine eigene Version von Bash gegen 3.2.57 wiederherzustellen, als sich auf Apples Patch zu verlassen, es sei denn, Sie machen etwas falsch.

Macports

Damit erhalten Sie eine Bash-Version 4.3.28 (1), die sowohl Schwachstellen (CVE-2014-6271 und CVE-2014-7169) als auch einige später entdeckte Schwachstellen behebt. Dies ist nützlich, wenn Sie die Shells so geändert haben, dass Macports Bash verwendet wird, um die Funktionen von Version 4 zu erhalten.

Es wird das Problem von Standard-Betriebssystemskripten als have #!/bin/shoder #!/bin/bashals erste Zeile nicht lösen . Diese Art von Problem ist der Grund, warum Macports versucht, die von Apple bereitgestellten Programmversionen nicht zu verwenden, da Macports in der Regel schneller aktualisiert wird (z. B. eine neuere Version von bash).

Sie können dies wie in der Homebrew-Antwort festlegen

So installieren Sie Macports folgen Sie diese Anweisungen , die
1. Installieren Sie Xcode und die Xcode Kommandozeilen - Tools
2. zu Xcode Lizenz im Terminal einig: sudo xcodebuild -license
3. Download MacPorts Pkg für Ihre Version von OS X: Links sind auf der Seite
4. Führe das Paket aus

Wenn Sie Macports installiert haben, benötigen Sie die neuesten Versionen

sudo port selfupdate

und kompilieren Sie oder erhalten Sie die neuesten Binärdateien von

sudo port upgrade outdated

HINWEIS zum offiziellen Apple OS X Bash-Update 1.0: Dieses Software-Update bringt nur die offizielle Apple Bash-Version auf 3.2.53. Die Patch-Revision 3.2.54 bietet die folgende Änderung:

Dieser Patch ändert die Codierungs-Bash-Verwendung für exportierte Funktionen, um Konflikte mit Shell-Variablen zu vermeiden und um zu vermeiden, dass sie nur vom Inhalt einer Umgebungsvariablen abhängen, um zu bestimmen, ob sie als Shell-Funktion interpretiert werden sollen oder nicht.

Für Benutzer, die das System bereits mit 3.2.54-Binärdateien gepatcht haben, können Sie entweder Ihre kompilierten Binärdateien durch den Apple-Patch ersetzen oder die Dinge so lassen, wie sie sind, aber dies ist nicht ratsam. Obwohl Apple seine Binärversionierung bei 3.2.53 belassen hat, enthält der Apple-Patch die Korrektur für den folgenden Exploit-Test:

env X='() { (a)=>\' sh -c "echo date"; cat echo

Dies bedeutet, dass die offizielle Apple-Version 3.2.53 eine der Vanilla GNU-Version 3.2.54 entsprechende Sicherheit enthält. Ein unglücklicher Punkt der Verwirrung, aber es ist was es ist. Apples Verlegenheit ist nicht halb gebacken. Es scheint eine vollständige Lösung für das Problem zu sein. Daher sollte der unten stehende Fahrplan zum Kompilieren von Vanille bashund shaus GNU-Quellen als historisches Artefakt betrachtet und möglicherweise als Vorlage für zukünftige Patches herangezogen werden.

HINWEIS: In Verbindung mit der Vanilla GNU-Quelle treten shProbleme mit der Rechteerweiterung auf , die zu Fehlern bei verschiedenen Installationsprogrammen führen, z. B. Adobe Flash. Ich empfehle dringend, bei den mit Apple gepatchten Binaries zu bleiben. Betrachten Sie dieses Patch-Schema als veraltet und schlecht beraten.

Es gibt einen neuen GNU Bash 3.2.55 Patch, der das folgende Update beschreibt:

Bug-Beschreibung:

In parse.y gibt es zwei lokale Pufferüberläufe, die dazu führen können, dass die Shell den Core auslagert, wenn viele Here-Dokumente an einen einzelnen Befehl oder viele verschachtelte Schleifen angehängt werden.

Wir überlassen es dem aufmerksamen Leser, zu entscheiden, ob er sich an die offiziellen, von Apple gepatchten Binärdateien hält oder seine eigenen, um sich mit den neuen möglichen Exploits zu befassen. Persönlich werde ich mich an die Apple-Binaries halten.

Dieser Beitrag beschreibt , wie zu kompilieren und eine Vanille zu installieren bashund shauf OS X. wählte ich diese Route Beispielen wie folgt detailliert mit Apple-spezifischer Quelle habe mich nicht mit der richtigen Patch Revision verlassen. YMMV. Diese Vanille-Installation zielt jedoch darauf ab, die OS X-Binärdateien zu ersetzen, sodass diese Vanille-Ersetzungen von den entsprechenden Apple-Partnern übernommen werden, wenn Apple schließlich ein Sicherheitsupdate veröffentlicht.

Meine Basiskonfiguration ist:

OS X Lion 10.7.5 und Xcode 4.6.3 mit allen installierten Befehlszeilenprogrammen.

Meine Schritte, um dies zu beheben, waren:

Laden Sie den Base-Bash-Quellcode für 3.2.48 herunter von:

https://ftp.gnu.org/gnu/bash/bash-3.2.48.tar.gz

Laden Sie die Patches bash3.2.49, .50, .51, .52, .53, .54 und .55 herunter von:

https://ftp.gnu.org/gnu/bash/bash-3.2-patches/

Ich habe sie als $ filename.patch gespeichert, zB bash3.2.50.patch.

CD in Ihr Download-Verzeichnis und…

Entpacke den Hauptquellzweig:

tar xzvf bash-3.2.48.tar.gz

cd bash-3.2.48

Angenommen, Sie haben Ihre heruntergeladenen Patch-Dateien wie oben beschrieben umbenannt.

cp ../*.patch .

Dann …

for file in *.patch ; do
  patch -p0 < $file
done

Dies sollte erfolgreiche Patches verschiedener Dateien anzeigen. Wenn nicht, bereiten Sie sich auf eine Erkundung und Untersuchung vor.

Nächster:

sudo cp /bin/bash /bin/bash_old
sudo cp /bin/sh /bin/sh_old
sudo chmod -x /bin/bash_old
sudo chmod -x /bin/sh_old

Das hat im Grunde genommen Ihre alten, verwundbaren Bash- und Shellsicherungen gesichert und ihre ausführbaren Berechtigungen entfernt. Dadurch haben Sie die Möglichkeit, die Befehle nach Bedarf wiederherzustellen, können jedoch in der Zwischenzeit keinen Schaden mehr anrichten.

Nächster:

./configure --prefix=/ ; make ; sudo make install

Dies sollte die neue Bash-Binärdatei in / bin korrekt konfigurieren, kompilieren und installieren. Nachdem dies erledigt ist, beenden Sie das Terminal und öffnen Sie es erneut.

Sie sollten in der Lage sein, alle Dinge glücklich und lächelnd zu sehen bash --versionund jetzt 3.2.55, zB:

Gaia:Downloads trane$ bash --version
GNU bash, version 3.2.55(1)-release (i386-apple-darwin11.4.2)
Copyright (C) 2007 Free Software Foundation, Inc.

Die genaue Ausgabe im obigen Befehl hängt von Ihrer Version von OS X ab.

Sie sollten auch in der Lage sein, Ihre Sicherheitsanfälligkeit zu testen bashund festzustellen, dass sie in Ordnung ist.

HINWEIS: Bisher haben wir nur Bash behoben, aber die /bin/shausführbare Datei befindet sich immer noch in ihrem anfälligen Zustand. Das reine Kopieren bashauf sheinem Linux- Computer ist eine Art, Dinge zu tun. Die shImplementierung von OS X weist jedoch einige Unterschiede auf bash, sodass Sie den Compiler erneut verschieben möchten. Weitere Informationen darüber, wie bashund welche shUnterschiede in OS X bestehen, finden Sie hier:

https://apple.stackexchange.com/a/89327/91441

In deinem Download-Verzeichnis mache:

make clean

Öffnen Sie die Datei in Ihrem bevorzugten Editor Makefile.inund scrollen Sie zu Zeile 99. Wir werden die Programmzeile so ändern, dass die von uns ausgegebene Binärdatei nicht wie folgt shaussieht bash:

Program = sh$(EXEEXT)

Speichern Sie es und dann

./configure --prefix=/ --enable-xpg-echo-default --enable-strict-posix-default
make ; sudo make install

Jetzt haben Sie shfast genau so gebaut , wie es Apple tun würde.

Ein letzter Hinweis: Auf einigen (allen?) Systemen scheint Apple die bashbugausführbare Datei im Allgemeinen zu platzieren /usr/bin. Unsere Kompilierung wird es hineingelegt haben /bin. Also, die letzten Schritte hier:

sudo mv /usr/bin/bashbug /usr/bin/bashbug_old
sudo chmod -x /usr/bin/bashbug_old
sudo mv /bin/bashbug /usr/bin/bashbug

Für alle, die mit dem Kompilieren aus dem Quellcode zu kämpfen haben, hat Apple ab dem 29. September offiziell Patches für Mac OS X 10.9.5, 10.8.5 und 10.7.5 veröffentlicht:

• OS X Bash Update 1.0 - OS X Mavericks
• OS X Bash Update 1.0 - OS X Mountain Lion
• OS X Bash Update 1.0 - OS X Lion

Erstens führt das Patchen von bash und sh für diese Sicherheitsanfälligkeit wahrscheinlich dazu, dass einige Skripts auf Ihrem Mac beschädigt werden. Sie müssen dies wirklich nicht tun, es sei denn, Sie bieten Webdienste für das öffentliche Internet direkt von Ihrem Mac aus an. Wenn dies wirklich nicht erforderlich ist, warten Sie, bis ein offizielles Sicherheitsupdate von Apple vorliegt.

Im Folgenden finden Sie einige Anweisungen zur Durchführung dieses Updates mit Brew on Mavericks 10.9.

Stellen Sie zunächst sicher, dass Sie eine veraltete Bash verwenden:

$ which bash
/bin/bash
$ /bin/bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.

Die aktuellste Bash ist 4.3.25

Wenn Sie Xcode nicht installiert haben, benötigen Sie die Xcode-Befehlszeilentools, die von installiert werden können

$ xcode-select --install

Oder über das Entwicklerportal .

So installieren Sie Brew ( http://brew.sh ):

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Dann mach:

$ brew doctor

Befolgen Sie bei Problemen die Anweisungen. Viele häufige Probleme werden hier angesprochen .

Aktualisieren Sie dann brew auf die neueste Liste der Pakete:

$ brew update

So erhalten Sie die neueste Bash-Version 4.3.25:

$ brew install bash

Dies installiert Bash in /usr/local/Cellar/bash/4.3.25/bin/bash

Das alte bashund shnoch vorhandene at /bin, so dass Sie nach der Installation die alten ausführbaren Dateien in eine neue Datei umbenennen.

$ sudo mv /bin/bash /bin/bash_old
$ sudo mv /bin/sh /bin/sh_old

Wenn Sie sehr paranoid sind, können Sie die Ausführungsberechtigungen für das entfernen bash_old

$ sudo chmod a-x /bin/bash_old /bin/sh_old

Erstellen Sie dann einen symbolischen Link zu der neuen Bash 4.3.25, die Sie installiert haben.

$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/bash
$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/sh

Starten Sie neu und es ist abgeschlossen.

Eine Warnung - Dies kann einige vorhandene Shell-Skripte beschädigen, die möglicherweise auf Bash 3.2 oder den Unterschieden beruhen, die der Mac shgegenüber Linux aufweist sh. Es gibt eine viel raffiniertere Antwort auf das Ersetzen von bash und sh aus Quellen, basierend auf einer Antwort von @TraneFranks in demselben Thread.

OS X 10.6.8 - Snow Leopard

Der Beitrag von @AlBlue ist sehr vollständig. Auf meinem OS X 10.6.8-Server funktioniert sein Fix jedoch nicht. Apple hat keinen Fix für 10.6.8 und die von @AlBlue beschriebenen Schritte funktionieren nicht mit Xcode 3.2.6 (der neuesten Version für Snow Leopard). Ich erhalte einen Fehler:

** BUILD FAILED **

The following build commands failed:
sh:
    CodeSign /Users/bas/bash-fix/bash-92/build/Release/sh
bash:
    CodeSign /Users/bas/bash-fix/bash-92/build/Release/bash
(2 failures)

Aus diesem Grunde bin ich mit brew.sh . Bitte kommentieren Sie Ihre Gedanken, wenn Sie eine bessere Lösung für OS X 10.6.8 Snow Leopard haben. Siehe auch den Kommentar von @Jerome, er hatte einen erfolgreichen Patch auf OS X 10.6.8 Snow Leopard mit der @ AlBlue-Lösung. Sowieso:

Installieren Sie zuerst das Gebräu mit dem folgenden Oneliner:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Aktualisieren brew

brew update

Installieren Sie jetzt einfach die neueste Version von bashund ersetzen Sie die aktuelle:

brew install bash
sudo sh -c 'echo "/usr/local/bin/bash" >> /etc/shells'
chsh -s /usr/local/bin/bash
sudo mv /bin/bash /bin/bash-backup
sudo ln -s /usr/local/bin/bash /bin/bash

Sie können die Standardanmeldeshell ' Command (complete path)' für die Terminal.app in ihren Einstellungen festlegen ( Command,)

Hinweis: In den Kommentaren halten einige Benutzer diese Methode nicht für angemessen. Für mich ist dies jedoch die einzige nachvollziehbare Methode, um BASH unter OS X 10.6.8 Snow Leopard zu aktualisieren.

Sie können den Anweisungen hier folgen: https://github.com/tjluoma/bash-fix Grundsätzlich können Sie in einem Terminal Folgendes tun:

curl -s https://raw.githubusercontent.com/tjluoma/bash-fix/master/bash-fix.sh | zsh -f