Étant donné que Bash 3.2 (la version fournie par OS X) est vulnérable à l' exploit d'exécution à distance appelé "Shell Shock" ( CVE-2014-6271 et CVE-2014-7169 ), comment puis-je reconstruire Bash et sécuriser mon système avant une patch Apple officiel?

UPDATE: Notez qu'Apple a publié le correctif officiel. Voir ci-dessous pour plus de détails.

Statut

Apple a publié des correctifs de sécurité Bash pour Shellshock et des vulnérabilités connexes sous le nom " OS X bash Update 1.0 ". Ils peuvent être installés via une mise à jour système normale pour les personnes utilisant OS X Mountain Lion v10.8.5 ou OS X Mavericks v10.9.5 (ils sont inclus dans la mise à jour de sécurité 2014-005 ). Ils peuvent également être installés manuellement. Des correctifs Apple officiels sont également disponibles pour OS X Lion v10.7.5 et OS X Lion Server v10.7.5, mais ceux-ci ne sont disponibles que par téléchargement manuel. Les correctifs de sécurité sont disponibles via différentes URL en fonction de la version du système d'exploitation:

• http://support.apple.com/kb/DL1769 - Mavericks (10.9.5 et versions supérieures)
• http://support.apple.com/kb/DL1768 - Lion de montagne (10.8.5)
• http://support.apple.com/kb/DL1767 - Lion & Lion Server (10.7.5)

(Si de nouveaux correctifs sont publiés, mettez-les ici, mais conservez-les également pour référence.)

Le correctif Apple corrige Shellshock et plusieurs autres vulnérabilités et convient à la plupart des utilisateurs. les gens peuvent arrêter de lire ici.

CEPENDANT, l'attention portée à bash par le bogue Shellshock a poussé de nombreux chercheurs à regarder de près ce qui se passe et de plus en plus de vulnérabilités (difficiles à exploiter) continuent à être trouvées. Si vous êtes très préoccupé par la sécurité (car vous utilisez peut-être OS X Server pour héberger un site Web accessible au public), essayez de suivre les vulnérabilités et les correctifs au fur et à mesure de leur progression en compilant vous-même. Sinon, ne vous inquiétez pas pour ça.

Pensez à Apple pour publier une autre mise à jour à venir dans le futur lorsque la poussière s’installera pour trouver de nouvelles vulnérabilités.

Un ensemble officiel de correctifs de bash lui-même est disponible pour les bash 3.2, 52, 53 et 54 (qui correspondent aux correctifs 25, 26 et 27 de Bash 4.3), qui corrigent à la fois CVE-2014-6271 et CVE-2014-7169, ainsi que le «Game over» affiché ci-dessous. Cela a été testé par moi ( @alblue ) et la publication a été mise à jour en conséquence (et des mises à jour supplémentaires ont été apportées: voir révision 41 pour la publication qui s'arrête au correctif 54).

De nombreuses vulnérabilités supplémentaires ont été rapportées contre bash. Selon le message de Michal Zalewski, si vous possédez le correctif 54 (et probablement le correctif officiel d'Apple) "il ne sert à rien de devenir obsédé par le statut de ces bogues individuels, car ils ne devraient plus poser de risque pour la sécurité:"

• CVE-2014-6271 - RCE original trouvé par Stéphane. Corrigé par bash43-025 et les entrées correspondantes du 24 septembre pour les autres versions.

• CVE-2014-7169 - Bug de consommation de fichier / création de fichier trouvé par Tavis. Fixé par bash43-026 & co (26 septembre)

• CVE-2014-7186 - un crash probablement sans risque d'au moins 10+ ici-doc trouvé par Florian et Todd. Fixé par bash43-028 & co (1er octobre).

• CVE-2014-7187 - une off-by-one trouvée par Florian, qui ne s'est probablement pas effondrée. Fixé par bash43-028 & co (1er octobre).

• CVE-2014-6277 - problème de mémoire non initialisée, presque certainement un RCE découvert par Michal Zalewski. Pas de patch spécifique pour le moment.

• CVE-2014-6278 - RCE d'injection de commande trouvé par Michal Zalewski. Pas de patch spécifique pour le moment.

Cela devient assez déroutant. Heureusement, Chet Ramey, le responsable officiel de bash, a posté un fichier CVE pour appliquer les correctifs . Son article fait référence aux correctifs de bash 4.3, I (@OldPro) les a traduits en correctifs pour bash 3.2, ce qui est applicable à OS X. En outre, depuis qu'il publie le correctif 57, j'ai ajouté ce qui suit:

 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

Voir le post de David A. Wheeler pour une chronologie et plus de détails.

@alblue a publié les instructions de construction via le correctif 55. J'ai ajouté les correctifs 56 et 57 aux instructions, mais je ne l'ai pas testé.

Test de la vulnérabilité d'origine

Vous pouvez déterminer si vous êtes vulnérable au problème d'origine dans CVE-2014-6271 en exécutant ce test:

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

La sortie ci-dessus est un exemple de bashversion non vulnérable . Si vous voyez le mot vulnerabledans le résultat de cette commande, votre bashest vulnérable et vous devez le mettre à jour. Vous trouverez ci-dessous une version vulnérable d'OS X 10.8.5:

Test de la nouvelle vulnérabilité

Une mise à jour de la publication d'origine a été mise à jour et Bash 3.2.52 (1) est toujours vulnérable à une variante de la vulnérabilité définie dans 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

La sortie ci-dessus est un exemple de bashversion vulnérable . Si vous voyez une date dans la sortie de cette commande, votre bashest vulnérable.

Désactivation des fonctions importées automatiquement pour empêcher le "Game Over"

Les chercheurs ont noté, sans le qualifier de vulnérabilité, qu'un script pourrait détourner une fonction d'un sous-shell à l'aide de fonctions importées automatiquement:

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

Le code ci-dessus sur un système affecté s'afficherait à la Game Overplace de la liste de répertoires attendue ls. De toute évidence, echo 'Game Over'pourrait être remplacé par tout code néfaste que vous voulez. Cela est devenu connu comme le "Game Over" bug.

Avant la mise à jour du correctif 54, NetBSD et FreeBSD désactivaient par défaut les fonctions bash de l'importation automatique, en partie pour empêcher "Game Over", mais surtout pour éviter toute erreur dans l'analyseur (tel que CVE-2014-7169 ). continue à être découvert, et a ajouté un nouvel indicateur de ligne de commande--import-functionspour réactiver l'ancien comportement par défaut. J'ai (@alblue) préparé un correctif (contre 3.2.53) que les autres utilisateurs pourraient utiliser s'ils souhaitaient également adopter ce comportement, et l'ai inclus ci-dessous. Par défaut, ce correctif n'est pas activé dans le script de construction ci-dessous. (@OldPro) pense que ce correctif n’est plus nécessaire ni une bonne idée, car il rompt la compatibilité ascendante et les vulnérabilités contre lesquelles il protège sont très bien corrigées par les correctifs du correctif 54 et des correctifs antérieurs, et permettre à ce correctif non officiel d’empêcher l’application de futurs correctifs .

(Note aux éditeurs de questions; ne l'activez pas par défaut, il s'agit d'un correctif non officiel.)

a0c5c4d66742fddd0a35001cb91798a5fbf8a2f5 import_functions.patch

Le correctif peut être activé en l'exécutant export ADD_IMPORT_FUNCTIONS_PATCH=YESavant d'exécuter la construction. Notez que l' activation de ce correctif désactivera le correctif 54 et tous les futurs correctifs car il est impossible de garantir la compatibilité des futurs correctifs avec le correctif non officiel.

Apple Patch a la vulnérabilité Game Over, en quelque sorte

Comme l'a souligné @ake_____ sur Twitter, le correctif officiel d'Apple est toujours vulnérable à la saturation de l'environnement des exécutables:

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

Les utilisateurs devraient décider eux-mêmes de l'importance Je (@OldPro) pense qu'il n'y a pas lieu de s'inquiéter car il n'existe aucun exploit connu pour ce comportement (il n'a même pas reçu d'identifiant CVE) car en général, les attaquants distants non privilégiés ne peuvent pas définir le nom d'une variable d'environnement et les attaquants dotés de privilèges ne peuvent pas. utilisez-le pour obtenir des privilèges qu’ils ne possèdent pas déjà (du moins pas sans exploiter une vulnérabilité supplémentaire).

Pour fournir un peu d’arrière-plan, bash vous permet de définir des fonctions et vous permet en outre d’ exporter ces fonctions dans des sous-shell via la export -fcommande. Auparavant, cela était implémenté en créant une variable d'environnement portant le même nom que la fonction et dont la valeur était définie sur la définition de la fonction. Alors

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

Cela est dû à la export -f lscréation d'une variable d'environnement nommée ls. La vulnérabilité "Game Over" était que vous pouviez créer directement cette variable d'environnement sans avoir à définir la fonction, ce qui signifiait que si vous pouviez injecter le nom de variable correct, vous pourriez détourner une commande. Apple a essayé de résoudre ce problème en rendant difficile la création d'une variable portant le bon nom. Le correctif bash 54 officiel rend en effet impossible de créer une variable avec le nom correct en utilisant des noms de variables incluant le %caractère non autorisé dans un nom de variable, plaçant ainsi les définitions de fonctions exportées dans un espace de noms réservé différent.

Si rien de ce qui précède n'a de sens pour vous, ne vous en faites pas. Le patch Apple vous convient pour le moment.

Binaires du système

OS X 10.9.5 (la dernière version stable pour le moment) est fourni avec Bash v3.2.51:

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

Vous pouvez obtenir et recompiler Bash comme suit , à condition que Xcode soit installé (et exécuté xcodebuildau moins une fois auparavant pour accepter la licence):

$ # 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

(Remarque: vous pouvez exécuter ceci en copiant-collant le bloc de code ci-dessus, en allant dans Terminal puis en l'exécutant pbpaste | cut -c 2- | sh. Faites toujours attention lorsque vous exécutez des scripts aléatoires à partir d'Internet, bien que ...)

Après cela, la version de Bash devrait être la v3.2.57:

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

Pour des raisons de sécurité et après les tests, je vous recommande d'utiliser chmod -xles anciennes versions pour vous assurer qu'elles ne sont pas réutilisées ou de les déplacer vers un site de sauvegarde.

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

D'autres réponses ont des solutions pour ceux qui utilisent MacPorts ou Homebrew; ceux-ci ne résolvent pas le problème, ils installent simplement des versions supplémentaires de Bash. S'il vous plaît voir ces réponses si vous souhaitez mettre à niveau ceux spécifiquement.

Merci

Merci à Chet, qui s’occupe de Bash et qui a mis ces correctifs à disposition. Merci à tous ceux qui ont fait des commentaires à ce sujet et l’ont amélioré avec le temps.

Maintenant, Apple a publié le correctif réel, bien que cela puisse encore être utile. Comme ils ne publient qu'un correctif pour Lion et les versions ultérieures, et que le correctif officiel fournit GNU bash, version 3.2.53 (1) -release (x86_64-apple-darwin13), le bogue Game over est toujours quelque peu vulnérable. À ce stade, il est probablement plus sûr de reconstruire votre propre version de Bash par rapport à la version 3.2.57 que de vous fier au correctif d’Apple, à moins que vous ne le fassiez pas.

Macports

Cela vous donne une version 4.3.28 (1) de Bash qui a corrigé les deux vulnérabilités (CVE-2014-6271 et CVE-2014-7169) ainsi que des vulnérabilités découvertes par la suite. Ceci est utile si vous avez changé de shell pour utiliser Macports bash afin d’obtenir les fonctionnalités de la version 4.

Cela ne résoudra pas le problème des scripts OS standard, que ce #!/bin/shsoit #!/bin/bashen première ligne ou en mode standard. Ce genre de problème est la raison pour laquelle Macports essaie de ne pas utiliser les versions de programmes fournies par Apple, car Macports a tendance à être mis à jour plus rapidement, par exemple, il possède une version plus récente de bash).

Vous pouvez faire en sorte que le terminal utilise ceci comme dans la réponse Homebrew

Pour installer macports, suivez ces instructions :
1. Installez Xcode et les outils de ligne de commande Xcode
2. Acceptez la licence Xcode dans Terminal: sudo xcodebuild -license
3. Téléchargez MacPorts pkg pour votre version d’OS X: les liens se trouvent à la page
4. Exécuter le pkg

Lorsque vous avez installé macports, vous devez disposer des dernières versions. Pour ce faire, exécutez la commande

sudo port selfupdate

et recompiler ou obtenir les derniers fichiers binaires par

sudo port upgrade outdated

REMARQUE concernant la mise à jour 1.0 officielle de Apple OS X bash: cette mise à jour logicielle porte uniquement la version officielle de Apple bash en version 3.2.53. La révision du correctif 3.2.54 offre la modification suivante:

Ce patch modifie l'encodage utilisé par bash pour les fonctions exportées afin d'éviter les conflits avec les variables shell et d'éviter de dépendre uniquement du contenu d'une variable d'environnement pour déterminer si elle doit être interprétée ou non comme une fonction shell.

Pour les utilisateurs qui ont déjà corrigé le système avec des fichiers binaires 3.2.54, vous pouvez remplacer vos fichiers binaires compilés par le correctif Apple ou vous pouvez laisser les choses en l'état, mais cela est déconseillé. Bien qu'Apple ait laissé sa version binaire à 3.2.53, le correctif Apple contient le correctif pour le test d'exploitation ci-dessous:

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

Cela signifie que le binaire officiel 3.2.53 d’Apple contient une sécurité équivalente à celle du binaire GNU 3.2.54 vanille. Un malheureux point de confusion, mais c'est ce que c'est. La solution d'Apple n'est pas à moitié cuite. Cela semble être une solution complète au problème. En tant que tel, la feuille de route ci-dessous pour la compilation de vanilla bashet à shpartir de la source GNU devrait être considérée comme un artefact historique et éventuellement consultée comme modèle pour la manière de créer des correctifs à l'avenir, si nécessaire.

REMARQUE: La source GNU vanilla shprésente des problèmes d’élévation des privilèges qui entraînent des défaillances dans divers programmes d’installation, tels que Adobe Flash. Je vous recommande vivement de vous en tenir aux fichiers binaires patchés par Apple. Considérez ce schéma de correctif comme obsolète et peu judicieux.

Un nouveau correctif GNU bash 3.2.55 décrit le correctif suivant:

Description du bug:

Il y a deux dépassements de tampon locaux dans parse.y qui peuvent causer le dump du shell lorsque de nombreux documents here sont attachés à une seule commande ou à plusieurs boucles imbriquées.

Le lecteur avisé décidera s’il convient de s’asseoir avec les fichiers binaires officiels avec les correctifs Apple ou de lancer le vôtre pour faire face aux nouveaux exploits possibles. Personnellement, je vais rester avec les fichiers binaires Apple.

Cet article explique en détail comment compiler et installer une version de vanilla bashet shsur OS X. J'ai choisi cette route comme exemple suivant détaillant l'utilisation d'un code source spécifique à Apple ne m'a pas laissé avec la révision de correctif appropriée. YMMV. Cette installation vanilla vise toutefois à remplacer les fichiers binaires OS X, de sorte que, lorsque Apple publiera enfin une mise à jour de sécurité, ces remplaçants à la vanille seront usurpés par leurs homologues Apple.

Ma configuration de base est:

OS X Lion 10.7.5 et Xcode 4.6.3 avec tous les utilitaires de ligne de commande installés.

Mes étapes pour résoudre ce problème étaient les suivantes:

Téléchargez le code source bash pour 3.2.48 à partir de:

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

Téléchargez les correctifs bash3.2.49, .50, .51, .52, .53, .54 et .55 depuis:

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

Je les ai sauvegardés sous $ filename.patch, par exemple bash3.2.50.patch.

CD dans votre répertoire de téléchargement et…

Décompressez la branche source principale:

tar xzvf bash-3.2.48.tar.gz

cd bash-3.2.48

En supposant que vous ayez renommé les fichiers de correctif téléchargés comme décrit précédemment,

cp ../*.patch .

Ensuite …

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

Cela devrait montrer des correctifs réussis de divers fichiers. Sinon, soyez prêt à faire de l'exploration et des recherches.

Prochain:

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

Cela a essentiellement permis de sauvegarder vos vieux et vulnérables shells et de supprimer leurs privilèges exécutables. Cela vous donne la capacité de restaurer les commandes si nécessaire, mais leur permet également d’endommager entre-temps.

Prochain:

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

Cela devrait correctement configurer, compiler et installer le nouveau fichier binaire bash dans / bin. Ensuite, quittez Terminal et rouvrez-le.

Vous devriez, toutes les choses heureuses et souriantes, pouvoir bash --versionet voir maintenant 3.2.55, par exemple:

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.

La sortie exacte dans la commande ci-dessus diffère selon votre version d'OS X.

Vous devriez également pouvoir tester votre vulnérabilité bashet constater qu'elle va bien.

REMARQUE: Jusqu'à présent, nous n'avons résolu que bash, mais l' /bin/shexécutable est toujours vulnérable. Simplement copier bashsur le dessus shest un style de travail sous Linux. L' shimplémentation d' OS X présente toutefois quelques différences bash, vous devrez donc à nouveau faire glisser le compilateur. Vous trouverez plus d’informations sur la manière bashet les shdifférences sous OS X ici:

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

Dans votre répertoire de téléchargement, faites:

make clean

Dans votre éditeur favori, ouvrez le fichier Makefile.inet faites défiler jusqu'à la ligne 99. Nous allons modifier la ligne Programme afin que le fichier binaire que nous produisons soit à la shplace de la suivante bash:

Program = sh$(EXEEXT)

Enregistrez-le et ensuite

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

Maintenant, vous aurez construit shpresque exactement comme Apple.

Une dernière remarque: sur certains (tous?) Systèmes, Apple semble généralement placer l’ bashbugexécutable dans /usr/bin. Notre compilation l'aura mis dans /bin. Donc, les dernières étapes ici:

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

Pour ceux qui ont du mal à compiler leurs sources, le 29 septembre, Apple a officiellement publié des correctifs pour Mac OS X 10.9.5, 10.8.5 et 10.7.5:

• OS X bash mise à jour 1.0 - Mavericks OS X
• OS X bash mise à jour 1.0 - OS X Mountain Lion
• OS X bash mise à jour 1.0 - OS X Lion

Premièrement, patcher bash et sh pour cette vulnérabilité risque de casser certains scripts sur votre Mac. Vous n’avez vraiment pas besoin de le faire, sauf si vous proposez des services Web à l’Internet public directement à partir de votre Mac. Par conséquent, si cela n’est vraiment pas nécessaire, attendez qu’une mise à jour de sécurité officielle d’Apple soit disponible.

Étant prévenu, voici quelques instructions sur la façon d'effectuer cette mise à jour à l'aide de Brew on Mavericks 10.9.

Commencez par confirmer que vous utilisez une bash obsolète:

$ 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.

Le bash le plus récent est 4.3.25

Si Xcode n'est pas installé, vous aurez besoin des outils de ligne de commande Xcode, qui peuvent être installés à l'aide de

$ xcode-select --install

Ou du portail de développeur .

Pour installer Brew ( http://brew.sh ):

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

Alors fais:

$ brew doctor

Suivez les instructions s'il y a des problèmes. Beaucoup de problèmes communs sont abordés ici .

Puis mettez à jour brew avec la dernière liste de paquets:

$ brew update

Pour obtenir la dernière version 4.3.25:

$ brew install bash

Cela installe bash dans /usr/local/Cellar/bash/4.3.25/bin/bash

L'ancien bashet shexiste toujours /bin, donc après l'installation, vous renommerez les anciens exécutables en un nouveau fichier.

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

Si vous êtes très paranoïaque, vous pouvez supprimer les autorisations d'exécution sur le bash_old

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

Créez ensuite un lien symbolique vers la nouvelle version 4.3.25 de cette brassée installée.

$ 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

Redémarrez et c'est complet.

Un avertissement - cela peut casser certains scripts shell existants qui pourraient s’appuyer sur bash 3.2 ou les différences que le Mac sha sur le Linux sh. Il existe une réponse beaucoup plus sophistiquée pour remplacer bash et sh à partir de sources, à partir d'une réponse de @TraneFranks dans le même fil.

OS X 10.6.8 - Snow Leopard

Le post de @AlBlue est très complet. Cependant, sur mon serveur OS X 10.6.8, son correctif ne fonctionnera pas. Apple n'a pas de correctif pour 10.6.8 et les étapes expliquées par @AlBlue ne fonctionnent pas avec Xcode 3.2.6 (qui est la dernière version de Snow Leopard). Je reçois une erreur:

** 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)

Pour cette raison , je me sers brew.sh . Veuillez commenter vos pensées lorsque vous avez une meilleure solution pour OS X 10.6.8 Snow Leopard. Voir également le commentaire de @Jerome, il a eu un correctif sous OS X 10.6.8 Snow Leopard utilisant la solution de @ AlBlue. En tous cas:

Commencez par installer le brew avec le oneliner suivant:

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

Mise à jour brew

brew update

Maintenant, installez la dernière version de bashet remplacez la version actuelle:

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

Vous pouvez définir le shell de connexion par défaut ' Command (complete path)' pour le Terminal.app dans ses préférences ( Command,)

Remarque: dans les commentaires, certains utilisateurs ne pensent pas que cette méthode est appropriée. Pour moi, il s'agit de la seule méthode compréhensible pour mettre à niveau BASH sous OS X 10.6.8 Snow Leopard.

Vous pouvez suivre les instructions ici: https://github.com/tjluoma/bash-fix En gros, procédez comme suit dans un terminal:

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