Como o Bash 3.2 (a versão fornecida pelo OS X) é vulnerável à exploração de execução remota conhecida como "Shell Shock" ( CVE-2014-6271 e CVE-2014-7169 ), como faço para reconstruir o Bash e proteger meu sistema antes de um patch oficial da Apple?

ATUALIZAÇÃO: Observe que a Apple lançou o patch oficial. Veja abaixo para detalhes.

Status

A Apple lançou as correções de segurança Bash para Shellshock e vulnerabilidades relacionadas como " OS X bash Update 1.0 ". Eles podem ser instalados por meio da atualização normal do sistema para pessoas que usam o OS X Mountain Lion v10.8.5 ou OS X Mavericks v10.9.5 (eles estão incluídos na Atualização de segurança 2014-005 ) e também podem ser instalados manualmente. As correções oficiais da Apple também estão disponíveis para OS X Lion v10.7.5 e OS X Lion Server v10.7.5, mas estão disponíveis apenas por download manual. As correções de segurança estão disponíveis através de URLs diferentes, com base na versão do sistema operacional:

• http://support.apple.com/kb/DL1769 - Mavericks (10.9.5 e superior)
• http://support.apple.com/kb/DL1768 - Leão da montanha (10.8.5)
• http://support.apple.com/kb/DL1767 - Lion & Lion Server (10.7.5)

(Se novos patches forem lançados, coloque-os aqui, mas guarde-os para referência.)

O patch da Apple cuida do Shellshock e de várias outras vulnerabilidades e é bom para a maioria das pessoas. As pessoas podem parar de ler aqui.

No entanto, a atenção que o bug do Shellshock chamou a atenção do bash fez com que muitos pesquisadores analisassem com atenção o bash e mais e mais vulnerabilidades (difíceis de explorar) continuam sendo encontradas. Se você está altamente preocupado com a segurança (porque talvez esteja executando o OS X Server para hospedar um site disponível publicamente), convém (tente) acompanhar as vulnerabilidades e os patches à medida que eles continuam entrando, compilando você mesmo. Caso contrário, não se preocupe.

Procure a Apple para lançar outra atualização para aproveitar algum tempo no futuro, quando a poeira baixar para encontrar mais vulnerabilidades.

Está disponível um conjunto oficial de patches do bash para o bash 3.2, patches 52, 53 e 54 (que correspondem aos patches Bash 4.3 25, 26 e 27), que corrigem CVE-2014-6271 e CVE-2014-7169, bem como o 'Game over' exibido abaixo. Isso foi testado por mim ( @alblue ) e a postagem foi atualizada de acordo (e foram feitas atualizações adicionais: veja a revisão 41 da postagem que para no patch 54).

Muitas vulnerabilidades adicionais foram relatadas contra o bash. De acordo com o post de Michal Zalewski, se você possui o patch 54 (e presumivelmente o patch oficial da Apple) "não faz sentido ficar obcecado com o status desses erros individuais, porque eles não devem mais representar um risco à segurança:"

• CVE-2014-6271 - RCE original encontrado por Stephane. Corrigido por bash43-025 e entradas correspondentes em 24 de setembro para outras versões.

• CVE-2014-7169 - erro de criação de arquivo / consumo de token encontrado por Tavis. Corrigido por bash43-026 & co (26 de setembro)

• CVE-2014-7186 - uma falha de 10 ou mais documentos, provavelmente sem risco, encontrada por Florian e Todd. Corrigido por bash43-028 & co (1º de outubro).

• CVE-2014-7187 - um risco não fatal, provavelmente sem risco de segundo encontrado por Florian. Corrigido por bash43-028 & co (1º de outubro).

• CVE-2014-6277 - problema de memória não inicializada, quase certamente o RCE encontrado por Michal Zalewski. Nenhum patch específico ainda.

• CVE-2014-6278 - RCE de injeção de comando encontrado por Michal Zalewski. Nenhum patch específico ainda.

Fica bem confuso. Felizmente, Chet Ramey, o mantenedor oficial do bash, postou um CVE no mapeamento de patches . Seu post se refere a patches para o bash 4.3, eu (@OldPro) os traduzimos para patches para o bash 3.2, que é aplicável ao OS X. Além disso, desde que ele postou o patch 57, então eu adicionei o seguinte:

 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

Veja a publicação de David A. Wheeler para uma linha do tempo e mais detalhes.

A @alblue publicou instruções de construção no patch 55. Eu (@OldPro) adicionei o patch 56 e 57 às instruções, mas não o testei.

Testando a vulnerabilidade original

Você pode determinar se você está vulnerável ao problema original no CVE-2014-6271 executando este teste:

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

A saída acima é um exemplo de uma bashversão não vulnerável . Se você vir a palavra vulnerablena saída desse comando, você bashestará vulnerável e deverá atualizar. Abaixo está uma versão vulnerável do OS X 10.8.5:

Testando a nova vulnerabilidade

Houve uma atualização para a postagem original e o Bash 3.2.52 (1) ainda está vulnerável a uma variação da vulnerabilidade, definida em 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

A saída acima é um exemplo de uma bashversão vulnerável . Se você vir uma data na saída desse comando, bashestará vulnerável.

Desativando funções importadas automaticamente para evitar "Game Over"

Os pesquisadores observaram, sem classificá-lo como uma vulnerabilidade, que um script poderia seqüestrar uma função em um subshell usando funções importadas automaticamente:

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

O código acima em um sistema afetado seria exibido em Game Overvez da lista de diretórios que você esperaria ls. Obviamente, echo 'Game Over'pode ser substituído por qualquer código nefasto que você desejar. Isso se tornou conhecido como o bug "Game Over".

Antes da disponibilidade do patch 54, o NetBSD e o FreeBSD desabilitavam as funções bash de importação automática por padrão, em parte para impedir "Game Over", mas principalmente para conter outros erros no analisador (como CVE-2014-7169 ), como estavam continua a ser descoberto e adicionou um novo sinalizador de linha de comando--import-functionsreativar o antigo comportamento padrão. Eu (@alblue) preparei um patch (contra 3.2.53) para outras pessoas usarem se quiserem adotar esse comportamento também e o incluímos abaixo. Por padrão, este patch não está ativado no script de construção abaixo. Eu (@OldPro) acredito que esse patch não é mais necessário ou é uma boa idéia, porque quebra a compatibilidade com versões anteriores e as vulnerabilidades contra as quais ele protege são muito bem tratadas pelo patch 54 e pelos patches anteriores, e habilitar esse patch não oficial impede a aplicação de patches futuros .

(Observação para os editores de perguntas; por favor, não ative isso por padrão, pois é um patch não oficial.)

a0c5c4d66742fddd0a35001cb91798a5fbf8a2f5 import_functions.patch

O patch pode ser ativado executando export ADD_IMPORT_FUNCTIONS_PATCH=YESantes de executar a compilação. Observe que a ativação desse patch desabilitará o patch 54 e quaisquer patches futuros, porque não é possível garantir que patches futuros sejam compatíveis com o patch não oficial.

O Apple Patch tem vulnerabilidade de Game Over, mais ou menos

Como apontado por @ake_____ no twitter, o patch oficial da Apple ainda é vulnerável ao ambiente de executáveis:

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

Os usuários devem decidir por si mesmos o quanto isso é importante. Eu (@OldPro) acho que não há nada com que se preocupar, porque não há exploração conhecida por esse comportamento (nem sequer foi fornecido um identificador CVE) porque, em geral, atacantes remotos sem privilégios não podem definir o nome de uma variável de ambiente e atacantes com privilégios não podem use isso para obter privilégios que eles ainda não possuem (pelo menos não sem explorar uma vulnerabilidade adicional).

Para fornecer um pouco de experiência, o bash permite definir funções e, além disso, permite exportar essas funções para subshells através do export -fcomando Isso costumava ser implementado criando uma variável de ambiente com o mesmo nome que a função com seu valor definido para a definição da função. assim

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

Isso aconteceu porque export -f lscriou uma variável de ambiente chamada ls. A vulnerabilidade "Game Over" era que era possível criar diretamente essa variável de ambiente sem precisar primeiro definir a função, o que significava que, se você pudesse injetar o nome correto da variável, poderia sequestrar um comando. A Apple tentou corrigir isso, dificultando a criação de uma variável com o nome correto. O patch oficial do bash 54 na verdade torna impossível criar uma variável com o nome correto, usando nomes de variáveis ​​que incluem %qual é um caractere não permitido em um nome de variável, colocando efetivamente as definições de função exportadas em um espaço de nome reservado diferente.

Se nenhuma das opções acima fizer sentido para você, não se preocupe. Você está bem com o patch da Apple por enquanto.

Binários do sistema

O OS X 10.9.5 (a última versão estável no momento) é fornecida com o 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.

Você pode obter e recompilar o Bash da seguinte forma , desde que você tenha o Xcode instalado (e tenha executado xcodebuildpelo menos uma vez antes para aceitar a licença):

$ # 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: você pode executar isso copiando e colando o bloco de código acima, acessando o Terminal e executando pbpaste | cut -c 2- | sh. Sempre tome cuidado ao executar scripts aleatórios da Internet ...)

Depois disso, a versão do Bash deve ser a v3.2.57:

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

Por segurança e após o teste, recomendo que você chmod -xversões antigas para garantir que não sejam reutilizadas ou mova-as para um site de backup.

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

Outras respostas têm soluções para quem usa MacPorts ou Homebrew; eles não solucionam o problema, eles apenas instalam versões adicionais do Bash. Por favor, veja essas respostas se você deseja atualizá-las especificamente.

obrigado

Agradecemos a Chet, que cuida do bash, e tem disponibilizado esses patches. Obrigado a todos os que comentaram e melhoraram com o tempo.

Agora, a Apple lançou a correção real, embora isso ainda possa ser útil. Como eles lançaram apenas uma correção para Lion e versões posteriores, e o patch oficial fornece o GNU bash, versão 3.2.53 (1) -release (x86_64-apple-darwin13), no entanto, o bug Game over ainda é um pouco vulnerável. Neste ponto, a reconstrução da sua própria versão do Bash contra a versão 3.2.57 provavelmente é mais segura do que depender do patch da Apple, a menos que você faça isso errado.

Macports

Isso fornece a você a versão 4.3.28 (1) do bash, que corrigiu as vulnerabilidades (CVE-2014-6271 e CVE-2014-7169), além de algumas descobertas posteriormente. Isso é útil se você tiver alterado os shells para usar o Macports bash para obter os recursos da versão 4.

Ele não resolverá o problema dos scripts padrão do sistema operacional como os têm #!/bin/shou #!/bin/bashcomo a primeira linha. Esse tipo de problema é o motivo pelo qual o Macports tenta não usar as versões de programas fornecidas pela Apple, pois o Macports tende a ser atualizado mais rapidamente (por exemplo, possui uma versão mais recente do bash)

Você pode usar o terminal como na resposta Homebrew

Para instalar os macports, siga estas instruções :
1. Instale o Xcode e as Ferramentas de linha de comando do Xcode
2. Concorde com a licença do Xcode no Terminal: sudo xcodebuild -license
3. Faça o download do MacPorts pkg para sua versão do OS X: os links estão na página
4. Execute o pkg

Quando você tem macports instalado, precisa das versões mais recentes, isso é feito executando

sudo port selfupdate

recompilar ou obter os binários mais recentes

sudo port upgrade outdated

NOTA sobre a atualização oficial do Apple OS X bash 1.0: Esta atualização de software apenas traz a versão oficial do Apple bash para 3.2.53. A revisão do patch 3.2.54 oferece a seguinte alteração:

Esse patch altera o uso do bash de codificação para funções exportadas para evitar conflitos com variáveis ​​de shell e para depender apenas do conteúdo de uma variável de ambiente para determinar se deve ser interpretado ou não como uma função de shell.

Para usuários que já corrigiram o sistema com binários 3.2.54, você pode substituir os binários compilados pelo patch da Apple ou pode deixar as coisas como estão, mas é desaconselhável. Embora a Apple tenha deixado a versão binária em 3.2.53, o patch da Apple contém a correção para o teste de exploração abaixo:

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

Isso significa que o binário oficial da Apple 3.2.53 contém segurança equivalente ao binário da baunilha GNU 3.2.54. Um ponto infeliz de confusão, mas é o que é. A correção da Apple não está pela metade. Parece ser uma correção completa para o problema. Como tal, o roteiro abaixo para compilar baunilha bashe shda fonte GNU deve ser considerado um artefato histórico e, possivelmente, consultado como um modelo de como fazer correções no futuro, se necessário.

NOTA: Com a fonte GNU de baunilha, shhá problemas de elevação de privilégio que causam falhas em vários instaladores, por exemplo, Adobe Flash. Eu recomendo ficar com os binários corrigidos pela Apple. Considere esse esquema de correção como obsoleto e desaconselhável.

Há um novo patch do GNU bash 3.2.55 que descreve a seguinte correção:

Descrição do bug:

Existem dois estouros de buffer local em parse.y que podem fazer com que o shell despeje o núcleo quando houver muitos documentos aqui anexados a um único comando ou muitos loops aninhados.

Deixamos ao leitor gentil determinar se deve sentar-se com os binários oficiais corrigidos pela Apple ou fazer o seu próprio para lidar com as novas possíveis explorações. Pessoalmente, eu vou ficar com os binários da Apple.

Esta postagem detalha como compilar e instalar uma baunilha bashe shno OS X. Eu escolhi essa rota, pois os seguintes exemplos de detalhes usando a fonte específica da Apple não me deixaram com a revisão correta do patch. YMMV. No entanto, esta instalação de baunilha visa substituir os binários do OS X, de modo que, quando a Apple finalmente lançar uma atualização de segurança, essas substituições de baunilha serão usurpadas por seus correspondentes da Apple.

Minha configuração básica é:

OS X Lion 10.7.5 e Xcode 4.6.3 com todos os utilitários de linha de comando instalados.

Minhas etapas para corrigir isso foram:

Faça o download do código-fonte do bash base para 3.2.48 em:

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

Faça o download dos patches bash3.2.49, .50, .51, .52, .53, .54 e .55 em:

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

Salvei-os como $ filename.patch, por exemplo, bash3.2.50.patch.

CD no diretório de download e…

Descompacte o ramo de origem principal:

tar xzvf bash-3.2.48.tar.gz

cd bash-3.2.48

Supondo que você renomeou os arquivos de patch baixados conforme descrito anteriormente,

cp ../*.patch .

Então …

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

Isso deve mostrar patches bem-sucedidos de vários arquivos. Caso contrário, esteja preparado para fazer alguma exploração e investigação.

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

Isso basicamente fez backup de seus antigos e vulneráveis ​​shells e shells e removeu seu privilégio executável. Isso lhe dá a capacidade de restaurar os comandos conforme necessário, mas remove a capacidade deles de causar danos nesse meio tempo.

Próximo:

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

Isso deve configurar, compilar e instalar corretamente o novo binário do bash no / bin. Após terminar, saia do Terminal e reabra.

Todas as coisas felizes e sorridentes devem ser capazes bash --versione agora ver 3.2.55, por exemplo:

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.

A saída exata no comando acima será diferente, dependendo da sua versão do OS X.

Você também deve poder testar sua vulnerabilidade bashe descobrir que está correta.

NOTA: Corrigimos apenas o bash até agora, mas o /bin/shexecutável ainda está em seu estado vulnerável. Simplesmente copiar bashno topo shé um estilo Linux de fazer as coisas. A shimplementação do OS X tem algumas diferenças bash, no entanto, você precisará arrastar o compilador novamente. Mais informações sobre como bashe as shdiferenças no OS X podem ser encontradas aqui:

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

No diretório de download, faça:

make clean

No seu editor favorito, abra o arquivo Makefile.ine role para a linha 99. Vamos mudar a linha do programa para que o binário que produzimos seja em shvez de bash:

Program = sh$(EXEEXT)

Salve e depois

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

Agora você terá construído shquase exatamente como a Apple faria.

Uma observação final: em alguns sistemas (todos?), A Apple geralmente parece colocar o bashbugexecutável /usr/bin. Nossa compilação terá colocado isso /bin. Então, as etapas finais aqui:

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

Para quem luta com a compilação a partir do código-fonte, em 29 de setembro, a Apple lançou oficialmente os patches para o Mac OS X 10.9.5, 10.8.5 e 10.7.5:

• Atualização 1.0 do OS X bash - OS X Mavericks
• Atualização 1.0 do OS X bash - OS X Mountain Lion
• Atualização 1.0 do OS X bash - OS X Lion

Primeiro, o patch bash e sh dessa vulnerabilidade provavelmente quebrará alguns scripts no seu Mac. Você realmente não precisa fazer isso, a menos que esteja oferecendo serviços da Web à Internet pública diretamente do seu Mac. Portanto, se realmente não for necessário, aguarde até que haja uma atualização de segurança oficial da Apple.

Sendo avisado, aqui estão algumas instruções sobre como fazer essa atualização usando o Brew no Mavericks 10.9.

Primeiro confirme que você está usando um bash desatualizado:

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

O bash mais atual é 4.3.25

Se você não tiver o Xcode instalado, precisará das ferramentas de linha de comando do Xcode, que podem ser instaladas por

$ xcode-select --install

Ou no portal do desenvolvedor .

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

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

Então faça:

$ brew doctor

Siga todas as instruções se houver problemas. Muitos problemas comuns são abordados aqui .

Atualize o brew para a lista mais recente de pacotes:

$ brew update

Para obter o bash mais recente 4.3.25:

$ brew install bash

Isso instala o bash no /usr/local/Cellar/bash/4.3.25/bin/bash

O antigo bashe shainda existe em /bin, portanto, após a instalação, você renomeará os executáveis ​​antigos para um novo arquivo.

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

Se você é muito paranóico, pode remover permissões de execução no bash_old

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

Em seguida, crie um link simbólico para o novo bash 4.3.25 que o brew instalou.

$ 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 e está completo.

Um aviso - isso pode quebrar alguns scripts de shell existentes que podem depender do bash 3.2 ou das diferenças que o Mac shpossui sobre o linux sh. Existe uma resposta muito mais sofisticada para substituir bash e sh de fontes, de uma resposta de @TraneFranks neste mesmo segmento.

OS X 10.6.8 - Snow Leopard

O post do @AlBlue está muito completo. No entanto, no meu servidor OS X 10.6.8, sua correção não funcionará. A Apple não corrigiu a versão 10.6.8 e as etapas explicadas pelo @AlBlue não funcionam com o Xcode 3.2.6 (que é a versão mais recente do Snow Leopard). Eu recebo um erro:

** 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ão eu estou usando brew.sh . Por favor, comente sua opinião quando tiver uma solução melhor para o OS X 10.6.8 Snow Leopard. Veja também o comentário do @ Jerome, ele teve um patch bem-sucedido no OS X 10.6.8 Snow Leopard usando a solução do @ AlBlue. De qualquer forma:

Primeiro instale o brew com o seguinte oneliner:

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

Atualizar brew

brew update

Agora, basta instalar a versão mais recente bashe substituir a atual:

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

Você pode definir o shell de login padrão ' Command (complete path)' para o Terminal.app em suas preferências ( Command,)

Nota: Nos comentários, alguns usuários não consideram esse método apropriado. Mas, para mim, este é o único método compreensível para atualizar o BASH no OS X 10.6.8 Snow Leopard.

Você pode seguir as instruções aqui: https://github.com/tjluoma/bash-fix Basicamente, faça o seguinte em um terminal:

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