Estado

Apple ha publicado correcciones de seguridad de Bash para Shellshock y vulnerabilidades relacionadas como " OS X bash Update 1.0 ". Se pueden instalar a través de 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 - León de montaña (10.8.5)
• http://support.apple.com/kb/DL1767 - Servidor León y León (10.7.5)

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

El parche de Apple se encarga 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 a bash y se siguen 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 es posible que desee (intentar) mantenerse al día con las vulnerabilidades y los parches a medida que aparecen compilando bash usted mismo. De lo contrario, no te preocupes por eso.

Busque Apple para lanzar otra actualización para atacar en el futuro cuando el polvo se asiente en la búsqueda de 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 25, 26 y 27 de Bash 4.3) que corrigen CVE-2014-6271 y CVE-2014-7169, así como el 'Juego terminado' que se muestra a continuación. Esto ha sido probado por mí ( @alblue ) y la publicación se actualizó en consecuencia (y luego se realizaron actualizaciones adicionales: consulte la revisión 41 para 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 con el estado de estos errores individuales, porque ya no deberían representar un riesgo para la seguridad:"

• CVE-2014-6271: RCE original encontrado por Stephane. Corregido 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: Florian y Todd encontraron un accidente de 10+ here-doc probablemente sin riesgos de seguridad. Solucionado por bash43-028 & co (1 de octubre).

• CVE-2014-7187: un fallo de uno que no choca y probablemente no tiene riesgo de seguridad encontrado por Florian. Solucionado por bash43-028 & co (1 de octubre).

• CVE-2014-6277: problema de memoria no inicializada, RCE casi seguro encontrado por Michal Zalewski. Aún no hay un parche específico.

• CVE-2014-6278: inyección de comando RCE encontrada por Michal Zalewski. Aún no hay un parche específico.

Se vuelve bastante confuso. Afortunadamente, Chet Ramey, el mantenedor oficial de bash, publicó un CVE para parchear el mapeo . Su publicación se refiere a parches para bash 4.3, yo (@OldPro) los traduje a parches para bash 3.2, que es lo que se aplica a OS X. Además, desde esta publicación, lanzó el parche 57, así que lo agregué 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

Consulte la publicación de David A. Wheeler para obtener una cronología y más detalles.

@alblue publicó instrucciones de compilación hasta el 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 versión no vulnerable bash. Si ve la palabra vulnerableen la salida de ese comando bash, es 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 versión vulnerable bash. Si ve una fecha en la salida de ese comando bash, es vulnerable.

Deshabilitar las funciones importadas automáticamente para evitar "Game Over"

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

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

El código anterior en un sistema afectado se mostraría Game Overen lugar de la lista de directorios que esperaría de 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 deshabilitaron las funciones bash de importación automática de forma predeterminada, en parte para evitar "Game Over", pero principalmente para contener más errores en el analizador (como CVE-2014-7169 ) como estaban. continúa siendo descubierto, y agregó un nuevo indicador 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 quieren adoptar este comportamiento también y lo he incluido a continuación. De forma predeterminada, este parche no está habilitado en el script de compilación a continuación. Yo (@OldPro) creo que este parche ya no es necesario ni una buena idea, porque rompe la compatibilidad con versiones anteriores y las vulnerabilidades contra las 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 forma predeterminada, ya que es un parche no oficial).

a0c5c4d66742fddd0a35001cb91798a5fbf8a2f5 import_functions.patch

El parche se puede habilitar ejecutándolo 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 una vulnerabilidad de Game Over, algo así

Como señaló @ake_____ en Twitter , el parche oficial de Apple sigue siendo vulnerable a la destrucción del entorno de los ejecutables:

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

Los usuarios deben decidir por sí mismos qué tan importante es esto. Yo (@OldPro) creo que no hay nada de qué preocuparse porque no existe un exploit conocido para este comportamiento (ni siquiera se le dio un identificador CVE) porque, en general, los atacantes remotos sin privilegios 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, 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 mediante la creación de una variable de entorno con el mismo nombre que la función con su valor establecido en la definición de la función. Asi que

$ 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 de "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 de variable correcto, podría secuestrar un comando. Apple intentó arreglar 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, lo que coloca de manera efectiva las definiciones de funciones exportadas en un espacio de nombres reservado diferente.

Si nada de lo anterior tiene sentido para ti, no te preocupes. 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 Xcode instalado (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 ejecutando pbpaste | cut -c 2- | sh. Sin embargo, siempre tenga cuidado al ejecutar scripts aleatorios de 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 la prueba, le recomiendo que chmod -xuse las versiones anteriores para asegurarse de que no se reutilicen o las mueva a un sitio de respaldo.

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

Otras respuestas tienen soluciones para aquellos que 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 puesto a disposición estos parches. Gracias a todos los demás que han comentado sobre esto y lo han mejorado con el tiempo.

Ahora Apple ha lanzado la solución real, aunque aún podría ser útil. Debido a que solo lanzaron una solución para Lion y versiones posteriores, 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 sigue siendo 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 proporciona una versión 4.3.28(1) de bash que parcheó ambas vulnerabilidades (CVE-2014-6271 y CVE-2014-7169), así como algunas descubiertas posteriormente. Esto es útil si ha cambiado de shell para usar Macports bash para obtener las funciones de la versión 4.

No resolverá el problema de las secuencias de comandos estándar del sistema operativo como have #!/bin/sho #!/bin/bashcomo primera línea. Este tipo de problema es la razón por la que 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 nueva de bash)

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

Para instalar macports, siga estas instrucciones :
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 de MacPorts para su versión de OS X: los enlaces se encuentran en la página
4. Ejecutar el paquete

Cuando tiene macports instalado, necesita 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 1.0 oficial de Apple OS X bash: 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 los usos de codificación de bash 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 interpreta o no como una función de shell.

Para los usuarios que ya parchearon el sistema con binarios 3.2.54, 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 SÍ 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 GNU 3.2.54 de vainilla. Un lamentable punto de confusión, pero es lo que hay. La solución de Apple no está a medias. Parece ser una solución completa para el problema. Como tal, la siguiente hoja de ruta para compilar vanilla bashy shdesde la fuente GNU debe considerarse un artefacto histórico y posiblemente consultarse como una plantilla sobre cómo hacer parches en el futuro en caso de que sean necesarios.

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

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

Descripción del error:

Hay dos desbordamientos de búfer locales en parse.y que pueden hacer que el shell descargue el núcleo cuando se le dan muchos documentos aquí adjuntos a un solo comando o muchos bucles anidados.

Dejamos que el amable lector determine si se sienta con los archivos binarios parcheados oficiales de Apple o crea los suyos propios para lidiar con las nuevas posibles vulnerabilidades. Personalmente, me quedaré con los binarios de Apple.

Esta publicación detalla cómo compilar e instalar Vanilla bashy shen OS X. Elegí esta ruta porque los siguientes ejemplos que detallan el uso de fuentes específicas de Apple no me dejaron con la revisión de parche correcta. YMMV. Sin embargo, esta instalación estándar tiene como objetivo reemplazar los archivos binarios de OS X, de modo que cuando Apple finalmente publique una actualización de seguridad, estos reemplazos básicos 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 desde:

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 descargas y...

Descomprima la rama fuente principal:

tar xzvf bash-3.2.48.tar.gz

cd bash-3.2.48

Suponiendo que haya cambiado el nombre de los archivos de parche descargados como se describe anteriormente,

cp ../*.patch .

Después …

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

Esto debería mostrar parches exitosos de varios archivos. Si no es así, prepárate para explorar e investigar un poco.

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

Eso básicamente hizo una copia de seguridad de sus shells bash y sh antiguos y vulnerables y eliminó su privilegio de ejecución. Eso le da la capacidad de restaurar los comandos según sea necesario, pero elimina su capacidad de causar 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.

Deberías, todas las cosas felices y sonrientes, 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ía poder probar su vulnerabilidad bashy encontrar que está bien.

NOTA: Hasta ahora solo hemos reparado bash, pero el /bin/shejecutable aún se encuentra en su estado vulnerable. Simplemente copiar bashencima shes un estilo Linux de hacer las cosas. Sin embargo, la implementación de OS X shtiene algunas diferencias con respecto a bash, por lo que querrá arrastrar el compilador nuevamente. Puede encontrar más información sobre cómo bashy cómo shdifieren en OS X aquí:

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

En tu directorio de descarga haz:

make clean

En su editor favorito, abra el archivo Makefile.iny desplácese hasta la línea 99. Vamos a cambiar la línea del programa para que el binario que generamos sea shasí bash:

Program = sh$(EXEEXT)

Guárdalo y luego

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

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

Una nota final: en algunos (¿todos?) sistemas, Apple generalmente parece colocar el bashbugejecutable en /usr/bin. Nuestra compilación lo habrá puesto en /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 problemas 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 Actualización 1.0 – OS X Mavericks
• OS X bash Actualización 1.0 – OS X Mountain Lion
• OS X bash Actualización 1.0 - OS X León

En primer lugar, 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 la Internet pública directamente desde su Mac. Entonces, si realmente no es necesario, espere hasta que haya una actualización de seguridad oficial de Apple.

Con una advertencia, 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 bash 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 de desarrolladores .

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. Muchos problemas comunes se abordan aquí .

Luego actualice brew a la última lista de paquetes:

$ brew update

Para obtener el último 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 archivo nuevo.

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

Si es muy paranoico, puede eliminar los permisos de ejecución en elbash_old

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

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

$ 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

Reinicie y está completo.

Una advertencia: esto puede romper algunos scripts de shell existentes que pueden depender de bash 3.2 o las diferencias que shtiene Mac sobre 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 - Leopardo de las nieves

Muy completo el post de @AlBlue. Sin embargo, en mi servidor OS X 10.6.8, su solución no funcionará. Apple no tiene 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 todos modos:

Primero instale brew con el siguiente oneliner:

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

Actualizarbrew

brew update

Ahora simplemente 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 configurar 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