Os Macs estão vulneráveis ​​ao bug do shellshock do Bash?

58

A Red Hat anunciou recentemente um grande bug relacionado à segurança no shell Bash. Alguns estão chamando de bug do "shellshock". Como o OS X é construído a partir do Unix, ele é vulnerável a ataques que exploram esse bug?

Como usuário final, preciso me preocupar com uma correção imediata? Ou é melhor esperar uma atualização oficial do software da Apple?

hairboat
fonte
11
consulte também apple.stackexchange.com/questions/146849/…
nohillside
Para ver quais ações afetam o OSX, consulte security.stackexchange.com/questions/68123/…
user151019
A questão foi atualizada para que seja menos enganador e mais um pedido de aconselhamento para leigos.
hairboat
11
A Apple lançou uma correção agora: support.apple.com/kb/DL1769
AT

Respostas:

46

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

JakeGould
fonte
7
"ou um servidor Web que execute scripts no lado do servidor" - ou tenha um aplicativo em execução, escutando uma porta aberta que permita que chamadas RPC sejam feitas e que acabem executando comandos do shell. Isso pode ser uma série de coisas, já que existem muitos aplicativos padrão que fazem seu RPC. Eu acho que essa resposta é muito ingênua. É muito fácil "executar um servidor Web" inadvertidamente durante a execução de um aplicativo que faz alguma coisa do tipo cliente-servidor.
Ian C.
3
@IanC. Você pode fornecer um exemplo em que o OS X original seria verdadeiramente vulnerável? Por exemplo, algo como WebEx ou GotoMeeting chegaria perto dos recursos do Bash? O ponto é que não consigo pensar em um cenário simples de instalação do OS X que realmente exponha as coisas. Você pode?
JakeGould
8
A conta de convidado não está disponível para ssh. De fato, nem é possível disponibilizá-lo ao ssh, IIRC. O fato é que, para a grande maioria dos usuários do OS X, a vulnerabilidade do bash não é um problema. Para aqueles de nós em que há um problema, precisamos recompilar o bash assim que uma correção testada estiver disponível, mas não é agora.
precisa saber é o seguinte
3
@IanC. Ok, exemplos justos. Mas você ainda não entendeu: como se pode explorar essa vulnerabilidade em todos os exemplos que você está fornecendo? Em cada caso, um usuário precisaria acessar o sistema para começar e depois? Eu não estou sendo irreverente sobre isso, mas ainda não entendo qual seria o risco realmente? Alguém - por exemplo - teria que seguir o caminho através da API do Plex para fazer o que exatamente no bash para fazer algo fora dos direitos normais do usuário e dos privilégios de acesso?
JakeGould
6
@danielAzuelos “Todo mundo fica vulnerável enquanto a conta de convidado estiver aberta: [!” A conta de convidado não tem nada a ver bash. Então o medo é baseado no que exatamente? Além disso, mesmo se a conta de convidado estiver aberta e, de alguma forma, bashfor utilizável, e daí? Pelo que estou vendo, um palpite usando essa exploração não teria privilégios elevados nem nada parecido com isso. Sério, estou disposto a recuar da minha posição, mas isso parece mais um pânico com base em pouco, enquanto o OpenSSL era um problema real.
precisa saber é o seguinte
37

Sim!

Digite isso no seu shell

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Se diz, vulnerableentão você está vulnerável.

Se diz

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

então você é bom.

Editar: link para a correção

Chris Aitchison
fonte
4
Obrigado. Atualizei a pergunta - se descobrimos que somos vulneráveis, como um usuário de Mac pode corrigi-lo?
hairboat
3
@abbyhairboat Postou minha resposta. A menos que você esteja executando um servidor exposto ao mundo externo, não há riscos práticos. Os administradores de servidor são os que precisam se preocupar com isso.
precisa saber é o seguinte
11
→ abby: consulte esta resposta relacionada: apple.stackexchange.com/a/146851/22003 .
dan
2
Tente isso env X="() { :;} ; echo busted" /bin/sh -c "echo completed"- Mesmo depois de corrigir o meu sistema, este tosse com uma 'falha' na linha de comando. Bah.
Trane Francks
11
@ Mark não, zsh é seguro. você precisa substituir "bash -c" por "zsh -c" para testá-lo.
Ismail 25/09
3

Como usuário final , verifique se:

  • sua conta de convidado está desativada:

    Preferências do sistema> Usuários e grupos> Usuário convidado
    
  • seu sshacesso está desativado:

    Preferências do Sistema> Compartilhamento> Login Remoto
    

Por padrão, ambos estão desativados no Mavericks.

Como usuário final , é mais seguro aguardar uma atualização de segurança oficial da Apple corrigindo essa bashvulnerabilidade.

dan
fonte
11
Estes são irrelevantes. Qualquer um deles, por sua própria natureza, concede aos usuários acesso para executar comandos no sistema; portanto, se você os tiver ativado, é sua intenção permitir que os usuários executem comandos. O bug do Shellshock é um meio para usuários que você não pretendia executar comandos para fazê-lo, por exemplo, um usuário do servidor da web que você executa. Assim, sua resposta deve dizer "Sharing Web Disable" (mas isso é apenas uma coisa a verificar)
Josh
Estou irritado, a Apple não aconselhou desativar essas configurações. Quem os habilitaria? Eu gostaria. Sou usuário de Mac desde 1986, desenvolvedor de aplicativos da Web em período integral (a vida é tão ssh) e pai (portanto, uma conta de convidado para as crianças não é uma má idéia). Conheço muitas pessoas que são como eu nessas maneiras que usam laptops da Apple. Quer nos perder? Deixar essa vulnerabilidade aberta é uma boa maneira.
minopret 27/09/14
2

Todas as máquinas Mac OS X são tecnicamente vulneráveis ​​ao "Shellshock", até que a Apple emita uma atualização de segurança que remenda o bash, mas ..

Sua pergunta deve ser: Posso ser invadido remotamente?

Há tanto software que usa bashdistraidamente que responder a essa pergunta é extremamente difícil. Se você estiver preocupado, sugiro várias alterações System Preferencespara evitar explorações remotas:

  • Desative TODOS os serviços de compartilhamento em Preferências de compartilhamento.
  • Habilite o Firewall em Segurança e Privacidade.

Se você estiver particularmente preocupado, pressione o Firewallbotão de opções para:

  • Desmarque Automatically allow signed software to receive incoming connections.
  • Verifique Block all incoming connections.

Ainda existe uma chance respeitável de você estar vulnerável a um ataque de nível usando DHCP, Bonjour, etc., mas, se precisar de outro serviço, obviamente poderá deixá-lo em execução enquanto espera que não seja explorado. E você precisará deixar o firewall mais aberto também. Provavelmente, tudo ficará bem se sua máquina estiver protegida por outro firewall.

Além disso, existem ataques de escalação de privilégios locais ativados pelo “Shellshock?” Sim, quase com certeza. Não me preocuparia, porque o Mac OS X tem ataques semelhantes suficientes. A Apple não corrige erros de escalação de privilégios locais rapidamente. E a Apple os cria frequentemente com os serviços habilitados para Apple Script. Suponha que todas as máquinas Mac OS X estejam sempre vulneráveis ​​a ataques locais. Se você precisar participar de conferências de hackers como o DEFCON, compre uma caixa do Linux para esse fim.

Atualização: Existem instruções para recompilar seu próprio bash fixo e outras perguntas abordadas também. Eu vou fazer isso sozinho, mas IMHO é um exagero se você não executar nenhum servidor e manter o firewall da Apple ativado de qualquer maneira.

Update: Se você está confortável com o uso de terminal, há um programa chamado execsnoopmencionado aqui que vou deixar você testar se o bash normalmente é chamado por seus processos de servidor. Não é uma bala mágica, já que o processo do servidor pode chamar bash apenas em situações incomuns, mas isso lhe dará uma boa idéia.

Por fim, a Apple não é muito boa em corrigir vulnerabilidades de segurança, mas é boa em relações públicas, então isso será corrigido relativamente rápido. Portanto, é razoável pensar "Não preciso correr mais rápido que o urso, só preciso correr mais rápido que o vasto número de servidores facilmente exploráveis ​​na Internet". :)

Jeff Burdges
fonte
2
Não há chance de os Macs estarem vulneráveis ​​a um ataque usando DHCP, pois não usa o Bash.
11
Como você sabe disso? O aviso inicial era um cliente DHCP vulnerável. E muitos artigos especulam que os clientes DHCP do Mac OS X e / ou iOS podem estar vulneráveis. Todos os servidores devem ser considerados vulneráveis, a menos que se prove o contrário.
precisa saber é o seguinte
11
Não, eles não deveriam ser; isso é absoluto FUD. Você pode examinar o código-fonte aberto da implementação dhcp do OS X e medir o sistema que você mesmo solicita para verificar.
3
@JeffBurdges, o OS X não usa o shell exec com o DHCP desde 10.3, e antes desse bash não era instalado no sistema. O DHCP no OS X simplesmente não é um problema do Shellshock. (Menos uma coisa sobre a qual se preocupar :).)
Trane Francks
11
→ Jeff: considere: strings /usr/libexec/bootpd | egrep '/bin|bash'e nm -a /usr/libexec/bootpd | egrep 'fork|exec'. Ao ler estes comandos de saída em diferentes versões do MacOS X, você pode reconsiderar sua análise de risco devido ao dhcpdMacOS X… mas apenas esta :(.
dan
2

Eu criei essa ferramenta assim que soube dessa vulnerabilidade. Ele fornecerá um link para um artigo para corrigir seu shell se a ferramenta determinar que você está vulnerável.

Requer o Mac OS X 10.6 e superior.

Thomas Jones
fonte
3
Talvez seja só eu ... mas a idéia de executar o código de uma pessoa aleatória para testar uma exploração parece uma péssima idéia quando você pode colar uma string com a mesma facilidade (que claramente está apenas executando o teste e nada mais) em um janela do terminal.
Joe
Concordo, é por isso que a fonte está em code.google.com/p/shellshock-check
Thomas Jones
Às vezes, porém, pode oferecer facilidade de uso para testar vários sistemas.
Thomas Jones
Não vejo o benefício disso. A verificação da vulnerabilidade é muito mais fácil colando uma linha de comando simples na janela do terminal.
Albert Godfrind 29/09/14
Porém, ao testar várias máquinas, especialmente no meu caso, é o que faço, colocar uma unidade flash e abrir o Shellshock Check.app é muito mais fácil do que abrir o Safari, pesquisar o comando bash para verificar e abrir o Terminal, colando esse comando e pressionando Enter. É muito mais rápido conectar uma unidade flash e abrir um aplicativo.
Thomas Jones