Dado que Bash 3.2 (la versión incluida por OS X) es vulnerable al exploit de ejecución remota conocido como "Shell Shock" ( CVE-2014-6271 y CVE-2014-7169 ), ¿cómo reconstruyo Bash y aseguro mi sistema antes de un parche oficial de Apple?

ACTUALIZACIÓN: Tenga en cuenta que Apple ahora ha lanzado el parche oficial. Ver abajo para más detalles.

Estado

Apple ha lanzado correcciones de seguridad de Bash para Shellshock y vulnerabilidades relacionadas como " OS X bash Update 1.0 ". Se pueden instalar mediante la actualización normal del sistema para las personas que usan OS X Mountain Lion v10.8.5 o OS X Mavericks v10.9.5 (se incluyen en la Actualización de seguridad 2014-005 ) y también se pueden instalar manualmente. Las correcciones oficiales de Apple también están disponibles para OS X Lion v10.7.5 y OS X Lion Server v10.7.5, pero solo están disponibles mediante descarga manual. Las correcciones de seguridad están disponibles a través de diferentes URL según la versión del sistema operativo:

• http://support.apple.com/kb/DL1769 - Mavericks (10.9.5 y superior)
• http://support.apple.com/kb/DL1768 - Mountain Lion (10.8.5)
• http://support.apple.com/kb/DL1767 - Lion & Lion Server (10.7.5)

(Si se lanzan nuevos parches, colóquelos aquí, pero conserve estos existentes también como referencia).

El parche de Apple se ocupa de Shellshock y varias otras vulnerabilidades y está bien para la mayoría de las personas. tl; dr la gente puede dejar de leer aquí.

SIN EMBARGO, la atención atraída por bash por el error Shellshock ha provocado que muchos investigadores analicen detenidamente bash y sigan encontrando más y más vulnerabilidades (difíciles de explotar). Si está muy preocupado por la seguridad (porque tal vez está ejecutando OS X Server para alojar un sitio web disponible públicamente), entonces puede (intentar) mantenerse al día con las vulnerabilidades y los parches a medida que continúan compilando bash usted mismo. De lo contrario, no te preocupes por eso.

Busque que Apple lance otra actualización para atacar en algún momento en el futuro cuando el polvo se decida a encontrar más vulnerabilidades.

Hay disponible un conjunto oficial de parches de bash para bash 3.2, parches 52, 53 y 54 (que corresponden a los parches Bash 4.3 25, 26 y 27) que reparan tanto CVE-2014-6271 como CVE-2014-7169, así como el "Juego terminado" que se muestra a continuación. Esto lo probé yo ( @alblue ) y la publicación se actualizó en consecuencia (y luego se realizaron actualizaciones adicionales: consulte la revisión 41 para ver la publicación que se detiene en el parche 54).

Se han informado muchas vulnerabilidades adicionales contra bash. Según la publicación de Michal Zalewski, si tiene el parche 54 (y presumiblemente el parche oficial de Apple) "no tiene sentido obsesionarse sobre el estado de estos errores individuales, porque ya no deberían representar un riesgo de seguridad:"

• CVE-2014-6271 - RCE original encontrado por Stephane. Solucionado por bash43-025 y las entradas correspondientes del 24 de septiembre para otras versiones.

• CVE-2014-7169: error de creación de archivos / consumo de tokens encontrado por Tavis. Solucionado por bash43-026 & co (26 de septiembre)

• CVE-2014-7186: probablemente un accidente de más de 10 seg. Aquí-doc encontrado por Florian y Todd. Solucionado por bash43-028 & co (1 de octubre).

• CVE-2014-7187 - un no-choque, probablemente sin riesgo, encontrado por Florian. Solucionado por bash43-028 & co (1 de octubre).

• CVE-2014-6277: problema de memoria no inicializada, casi con certeza RCE encontrado por Michal Zalewski. No hay parche específico todavía.

• CVE-2014-6278 - comando de inyección RCE encontrado por Michal Zalewski. No hay parche específico todavía.

Se vuelve bastante confuso. Afortunadamente, Chet Ramey, el responsable oficial de bash, publicó un CVE para mapear parches . Su publicación se refiere a parches para bash 4.3, yo (@OldPro) los he traducido a parches para bash 3.2, que es lo que es aplicable a OS X. Además, desde esta publicación ha lanzado el parche 57, así que agregué eso a continuación:

 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

Vea la publicación de David A. Wheeler para una línea de tiempo y más detalles.

@alblue publicó instrucciones de compilación a través del parche 55. Yo (@OldPro) agregué los parches 56 y 57 a las instrucciones, pero no lo he probado.

Prueba de la vulnerabilidad original

Puede determinar si es vulnerable al problema original en CVE-2014-6271 ejecutando esta prueba:

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

El resultado anterior es un ejemplo de una bashversión no vulnerable . Si ve la palabra vulnerableen la salida de ese comando, bashes vulnerable y debe actualizar. A continuación se muestra una versión vulnerable de OS X 10.8.5:

Prueba de la nueva vulnerabilidad

Ha habido una actualización de la publicación original y Bash 3.2.52 (1) sigue siendo vulnerable a una variación de la vulnerabilidad, definida en 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

El resultado anterior es un ejemplo de una bashversión vulnerable . Si ve una fecha en la salida de ese comando, bashes vulnerable.

Desactivar las funciones de importación automática para evitar "Game Over"

Los investigadores notaron, sin clasificarlo como una vulnerabilidad, que un script podría secuestrar una función en una subshell usando funciones de importación automática:

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

El código anterior en un sistema afectado se mostraría en Game Overlugar de la lista de directorios que esperaría ls. Obviamente, echo 'Game Over'podría ser reemplazado por cualquier código nefasto que desee. Esto se conoció como el error "Game Over".

Antes de la disponibilidad del parche 54, tanto NetBSD como FreeBSD desactivaron las funciones bash de importación automática de forma predeterminada, en parte para evitar "Game Over" pero principalmente para contener cualquier error adicional en el analizador (como CVE-2014-7169 ) como estaban continúa siendo descubierto, y agregó una nueva bandera de línea de comando--import-functionspara volver a habilitar el antiguo comportamiento predeterminado. Yo (@alblue) he preparado un parche (contra 3.2.53) para que otros lo usen si también quieren adoptar este comportamiento y lo he incluido a continuación. Por defecto, este parche no está habilitado en el script de compilación a continuación. Yo (@OldPro) creo que este parche ya no es necesario o una buena idea, porque rompe la compatibilidad con versiones anteriores y las vulnerabilidades que protege están muy bien abordadas por el parche 54 y parches anteriores, y habilitar este parche no oficial evita que se apliquen parches futuros .

(Nota para los editores de preguntas; no habilite esto de manera predeterminada, ya que es un parche no oficial).

a0c5c4d66742fddd0a35001cb91798a5fbf8a2f5 import_functions.patch

El parche se puede habilitar ejecutando export ADD_IMPORT_FUNCTIONS_PATCH=YESantes de ejecutar la compilación. Tenga en cuenta que habilitar este parche deshabilitará el parche 54 y cualquier parche futuro porque no se puede garantizar que los parches futuros sean compatibles con el parche no oficial.

Apple Patch tiene vulnerabilidad Game Over, más o menos

Como lo señaló @ake_____ en Twitter, el parche oficial de Apple todavía es vulnerable al bloqueo ambiental de ejecutables:

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

Los usuarios deben decidir por sí mismos lo importante que es esto. Yo (@OldPro) creo que no hay nada de qué preocuparse porque no hay un exploit conocido para este comportamiento (ni siquiera se le dio un identificador CVE) porque en general los atacantes remotos no privilegiados no pueden establecer el nombre de una variable de entorno y los atacantes con privilegios no pueden use esto para obtener privilegios que aún no tiene (al menos no sin explotar una vulnerabilidad adicional).

Para proporcionar un poco de información de fondo, bash le permite definir funciones, y además le permite exportar esas funciones a subcapas a través del export -fcomando. Esto solía implementarse creando una variable de entorno con el mismo nombre que la función con su valor establecido en la definición de la función. Entonces

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

Esto sucedió porque export -f lscreó una variable de entorno llamada ls. La vulnerabilidad "Game Over" era que podía crear directamente esta variable de entorno sin tener que definir primero la función, lo que significaba que si podía inyectar el nombre correcto de la variable podría secuestrar un comando. Apple intentó solucionar esto dificultando la creación de una variable con el nombre correcto. El parche oficial de bash 54 en realidad hace que sea imposible crear una variable con el nombre correcto mediante el uso de nombres de variables que incluyen %un carácter no permitido en un nombre de variable, colocando efectivamente las definiciones de funciones exportadas en un espacio de nombres reservado diferente.

Si nada de lo anterior tiene sentido para usted, no se preocupe por eso. Estás bien con el parche de Apple por ahora.

Binarios del sistema

OS X 10.9.5 (la última versión estable en este momento) viene con 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.

Puede obtener y recompilar Bash de la siguiente manera , siempre que tenga instalado Xcode (y lo haya ejecutado xcodebuildal menos una vez antes para aceptar la licencia):

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

(Nota: puede ejecutar esto copiando y pegando el bloque de código anterior, yendo a la Terminal y luego ejecutándolo pbpaste | cut -c 2- | sh. Siempre tenga cuidado cuando ejecute scripts aleatorios desde Internet ...)

Después de esto, la versión de Bash debería ser v3.2.57:

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

Por seguridad, y después de las pruebas, le recomiendo que chmod -xuse las versiones anteriores para asegurarse de que no se vuelvan a usar o que las traslade a un sitio de respaldo.

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

Otras respuestas tienen soluciones para quienes usan MacPorts o Homebrew; estos no solucionan el problema, solo instalan versiones adicionales de Bash. Consulte esas respuestas si desea actualizarlas específicamente.

Gracias

Gracias a Chet, que se ocupa de bash, y ha estado haciendo disponibles estos parches. Gracias a todos los que han comentado sobre esto y lo han mejorado con el tiempo.

Ahora Apple ha lanzado la solución real, aunque esto podría ser útil. Debido a que solo lanzaron una solución para Lion y superiores, y el parche oficial proporciona GNU bash, versión 3.2.53 (1) -release (x86_64-apple-darwin13), sin embargo, el error de Game over todavía es algo vulnerable. En este punto, reconstruir su propia versión de Bash contra 3.2.57 es probablemente más seguro que confiar en el parche de Apple, a menos que lo haga mal.

Macports

Esto le ofrece una versión bash 4.3.28 (1) que parcheó tanto las vulnerabilidades (CVE-2014-6271 y CVE-2014-7169) como algunas que se descubrieron posteriormente. Esto es útil si ha cambiado los shells para usar Macports bash para obtener las características de la versión 4.

No resolverá el problema de los scripts estándar del sistema operativo como have #!/bin/sho #!/bin/bashcomo primera línea. Este tipo de problema es la razón por la cual Macports intenta no usar las versiones de programas proporcionadas por Apple, ya que Macports tiende a actualizarse más rápido, por ejemplo, tiene una versión más reciente de bash)

Puede hacer que el terminal use esto como en la respuesta Homebrew

Para instalar macports, siga estas instrucciones que son
1. Instale Xcode y las herramientas de línea de comandos de Xcode
2. Acepte la licencia de Xcode en la Terminal: sudo xcodebuild -license
3. Descargue el paquete MacPorts para su versión de OS X: los enlaces están en la página
4. Ejecuta el paquete

Cuando tienes macports instalados, necesitas las últimas versiones, esto se hace ejecutando

sudo port selfupdate

y recompilar u obtener los últimos binarios por

sudo port upgrade outdated

NOTA sobre la actualización oficial de Apple OS X bash 1.0: Esta actualización de software solo trae la versión oficial de Apple bash a 3.2.53. La revisión del parche 3.2.54 ofrece el siguiente cambio:

Este parche cambia el uso de bash de codificación para las funciones exportadas para evitar conflictos con las variables de shell y evitar depender solo del contenido de una variable de entorno para determinar si se debe interpretar o no como una función de shell.

Para los usuarios que ya han parcheado el sistema con 3.2.54 binarios, puede reemplazar sus binarios compilados con el parche de Apple o puede dejar las cosas como están, pero no es aconsejable. Aunque Apple dejó su versión binaria en 3.2.53, el parche de Apple contiene la solución para la siguiente prueba de explotación:

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

Esto significa que el binario oficial de Apple 3.2.53 contiene seguridad equivalente al binario vainilla GNU 3.2.54. Un desafortunado punto de confusión, pero es lo que es. La solución de Apple no está a medias. Parece ser una solución completa para el problema. Como tal, la hoja de ruta a continuación para compilar vainilla bashy shde la fuente GNU debe considerarse un artefacto histórico y posiblemente consultado como una plantilla sobre cómo hacer parches en el futuro si fuera necesario.

NOTA: Con la fuente GNU de vainilla, shtiene problemas de elevación de privilegios que causan fallas en varios instaladores, por ejemplo, Adobe Flash. Recomiendo seguir con los binarios parcheados por Apple. Considere este esquema de parche como obsoleto y desaconsejado.

Hay un nuevo parche GNU bash 3.2.55 que describe la siguiente solución:

Descripción del error:

Hay dos desbordamientos del búfer local en parse.y que pueden hacer que el shell voltee el núcleo cuando se le dan muchos documentos adjuntos a un solo comando o muchos bucles anidados.

Dejamos en manos del amable lector determinar si debe sentarse con los binarios oficiales parcheados por Apple o rodar los suyos para lidiar con las nuevas posibles hazañas. Personalmente, me quedaré con los binarios de Apple.

Esta publicación detalla cómo compilar e instalar una versión estándar bashy shen OS X. Elegí esta ruta, ya que los siguientes ejemplos que detallan el uso de una fuente específica de Apple no me dejaron con la revisión de parche correcta. YMMV. Sin embargo, esta instalación estándar está destinada a reemplazar los archivos binarios de OS X de modo que cuando Apple finalmente publique una actualización de seguridad, estos reemplazos estándar serán usurpados por sus contrapartes de Apple.

Mi configuración base es:

OS X Lion 10.7.5 y Xcode 4.6.3 con todas las utilidades de línea de comandos instaladas.

Mis pasos para arreglar esto fueron:

Descargue el código fuente de bash base para 3.2.48 desde:

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

Descargue los parches bash3.2.49, .50, .51, .52, .53, .54 y .55 de:

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

Los guardé como $ filename.patch, por ejemplo, bash3.2.50.patch.

CD en su directorio de descarga y ...

Desempaquete la rama fuente principal:

tar xzvf bash-3.2.48.tar.gz

cd bash-3.2.48

Suponiendo que ha cambiado el nombre de los archivos de parche descargados como se describió anteriormente,

cp ../*.patch .

Luego …

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

Esto debería mostrar parches exitosos de varios archivos. Si no, prepárate para hacer un poco de exploración e investigación.

Próximo:

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

Básicamente, eso hizo una copia de seguridad de sus sheh bash y shlls antiguos y vulnerables y eliminó su privilegio ejecutable. Eso le da la capacidad de restaurar los comandos según sea necesario, pero elimina su capacidad de hacer daño mientras tanto.

Próximo:

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

Esto debería configurar, compilar e instalar correctamente el nuevo binario bash en / bin. Una vez hecho esto, salga de la Terminal y vuelva a abrir.

Todas las cosas felices y sonrientes deberían poder bash --versiony ahora ver 3.2.55, por ejemplo:

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.

El resultado exacto en el comando anterior diferirá según su versión de OS X.

También deberías poder probar tu vulnerabilidad bashy descubrir que está bien.

NOTA: Hasta ahora solo hemos arreglado bash, pero el /bin/shejecutable todavía está en su estado vulnerable. Simplemente copiar bashencima shes un estilo Linux de hacer las cosas. Sin embargo, la shimplementación de OS X tiene algunas diferencias bash, por lo que querrá arrastrar el compilador nuevamente. Para más información sobre cómo bashy shdifieren en OS X se puede encontrar aquí:

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

En su directorio de descargas haga:

make clean

En su editor favorito, abra el archivo Makefile.iny desplácese a la línea 99. Vamos a cambiar la línea del Programa para que el binario que generemos sea en shlugar de bashser así:

Program = sh$(EXEEXT)

Guárdalo y luego

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

Ahora habrás construido shcasi exactamente como lo haría Apple.

Una nota final: en algunos sistemas (¿todos?), Apple generalmente parece colocar el bashbugejecutable /usr/bin. Nuestra compilación lo habrá puesto /bin. Entonces, los pasos finales aquí:

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

Para cualquiera que tenga dificultades para compilar desde la fuente, a partir del 29 de septiembre, Apple ha lanzado oficialmente parches para Mac OS X 10.9.5, 10.8.5 y 10.7.5:

• 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

Primero, es probable que parchear bash y sh para esta vulnerabilidad rompa algunos scripts en su Mac. Realmente no necesita hacer esto a menos que esté ofreciendo servicios web a Internet público directamente desde su Mac. Entonces, si realmente no es necesario, espere hasta que haya una actualización de seguridad oficial de Apple.

Una vez advertido, aquí hay algunas instrucciones sobre cómo hacer esta actualización usando Brew en Mavericks 10.9.

Primero confirme que está utilizando un bash desactualizado:

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

El golpe más actual es 4.3.25

Si no tiene instalado Xcode, necesitará las herramientas de línea de comandos de Xcode, que puede instalar

$ xcode-select --install

O desde el portal del desarrollador .

Para instalar Brew ( http://brew.sh ):

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

Entonces hazlo:

$ brew doctor

Siga las instrucciones si hay problemas. Aquí se abordan muchos problemas comunes .

Luego actualice brew a la última lista de paquetes:

$ brew update

Para obtener la última bash 4.3.25:

$ brew install bash

Esto instala bash en /usr/local/Cellar/bash/4.3.25/bin/bash

El antiguo bashy shtodavía existe en /bin, por lo que después de la instalación, cambiará el nombre de los ejecutables antiguos a un nuevo archivo.

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

Si eres muy paranoico, puedes eliminar los permisos de ejecución en bash_old

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

Luego, cree un enlace simbólico al nuevo bash 4.3.25 que se instaló.

$ 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

Reinicia y está completo.

Una advertencia: esto puede romper algunos scripts de shell existentes que pueden basarse en bash 3.2 o las diferencias que shtiene Mac con respecto a Linux sh. Hay una respuesta mucho más sofisticada para reemplazar bash y sh de las fuentes, de una respuesta de @TraneFranks en este mismo hilo.

OS X 10.6.8 - Snow Leopard

La publicación de @AlBlue es muy completa. Sin embargo, en mi servidor OS X 10.6.8 su solución no funcionará. Apple no tiene una solución para 10.6.8 y los pasos explicados por @AlBlue no funcionan con Xcode 3.2.6 (que es la última versión para Snow Leopard). Recibo un error:

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

Por esta razón estoy usando brew.sh . Comente sus pensamientos cuando tenga una mejor solución para OS X 10.6.8 Snow Leopard. Vea también el comentario de @Jerome, tuvo un parche exitoso en OS X 10.6.8 Snow Leopard usando la solución de @ AlBlue. De todas formas:

Primero instale brew con el siguiente oneliner:

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

Actualizar brew

brew update

Ahora solo instale la última versión bashy reemplace la actual:

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

Puede establecer el shell de inicio de sesión predeterminado ' Command (complete path)' para Terminal.app en sus preferencias ( Command,)

nota: en los comentarios, algunos usuarios no creen que este método sea apropiado. Pero para mí este es el único método comprensible para actualizar BASH en OS X 10.6.8 Snow Leopard.

Puede seguir las instrucciones aquí: https://github.com/tjluoma/bash-fix Básicamente, haga lo siguiente en una Terminal:

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