Sim, você é tecnicamente vulnerável. Portanto, se você sentir vontade de entrar em pânico ou faturar um cliente em pânico por algumas horas de trabalho em pânico, vá em frente!
Mas a realidade é que, a menos que você permita o acesso SSH a partir de conexões remotas ou um servidor Web que execute scripts no lado do servidor, você não estará em risco. Você estará verdadeiramente vulnerável se alguém que você não conhece puder acessar remotamente sua máquina e fazê-lo de uma maneira em que um comando Bash possa ser executado.
Significa que o Mac da área de trabalho - que realmente não executa aplicativos de servidor de nenhum tipo - não corre nenhum risco sério. Estou disposto a comer uma “torta humilde” proverbial aqui, mas não acho que a maioria dos usuários de Mac esteja em risco no final do dia.
Portanto, esse problema preocupa principalmente os administradores de sistema nos servidores Mac OS X e Unix / Linux expostos ao mundo, não os usuários de desktop que não ativam o compartilhamento SSH.
Talvez exista um risco extremo de um malware ou vírus do Mac ser criado para explorar esse risco, mas duvido.
EDIT: E apenas para elaborar como esse problema - na minha humilde opinião - não é realmente um problema para a maioria dos usuários comuns, sim, eu posso executar o seguinte comando bashno Mac OS X 10.9.5:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
E eu vejo isso:
vulnerable
hello
Adivinha? Isso é aterrorizante se você não pensar racionalmente nisso. Eu já tinha que estar logado no meu Mac para abrir o Terminal. E para negar o que eu disse sobre o SSH acima, para chegar ao ponto em que posso executar este teste, mesmo se o SSH estiver ativado, eu ainda precisaria estar logado para começar. E então - digamos que eu recebo acesso via SSH - o comando não me permite fazer nada além dos meus direitos normais de usuário, como este:
env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'
Ou seja, se você realmente está vulnerável a ser explorado por esse hack, sua segurança principal no sistema precisa ser tão comprometida que o fato de bashter uma falha é realmente o menor dos seus problemas.
Essa é uma preocupação de uma questão geral de controle e direitos, pois tem o potencial de permitir acesso não intencional, uma vez que o comportamento se estende para além das normas esperadas. Mas, na minha humilde opinião, não é um risco a par do OpenSSL ou a variedade do jardim "deixe-me deixar minha senha em uma nota colada na minha tela" corre o risco.
No final do dia, ainda estou corrigindo todos os meus servidores Linux / Unix que corro como procedimento padrão. E felizmente corrigirá os Macs que eu gerenciar assim que uma correção for lançada. Mas, para o uso prático do dia-a-dia, não me preocupo com isso, pois não entendo como uma falha que não permite privilégios elevados de usuário contribui para tudo.
UPDATE: Palavra oficial da Apple postada aqui ; ênfase minha:
“A grande maioria dos usuários do OS X não corre o risco de apresentar vulnerabilidades do bash relatadas recentemente”, disse um porta-voz da Apple ao iMore. controle de sistemas vulneráveis. Com o OS X, os sistemas são seguros por padrão e não são expostos a explorações remotas do bash, a menos que os usuários configurem serviços UNIX avançados.
Estamos trabalhando para fornecer rapidamente uma atualização de software para nossos usuários avançados do UNIX. ”
Tradução: O que eu disse acima sobre o problema do servidor e não o do cliente? Exatamente.
UM UDPATE FINAL: Para qualquer pessoa que esteja lutando 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:
AINDA OUTRA ATUALIZAÇÃO FINAL: E agora, a Apple acaba de lançar hoje uma atualização de segurança combinada que também inclui a bashatualização !
Nota: A atualização de segurança 2014-005 inclui o conteúdo de segurança da atualização 1.0 do OS X bash