Se o seu computador roda o shell Bash e não foi atualizado nos últimos dias, ele está vulnerável ao Shellshock, uma falha grave – e praticamente todos os computadores desktop e servidor com Linux e com OS X, além de aparelhos como roteadores e até eletrodomésticos conectados à Internet rodam esse software.
O bug começou a ser comentado em larga escala há alguns dias, e aparentemente foi descoberto na semana passada. Mas ele está presente nas versões do Bash dos últimos 20 e poucos anos (exceto as atualizações posteriores à descoberta, embora elas ainda estejam sendo auditadas), então é possível que alguém já o conhecesse e fizesse uso dele, silenciosamente, há muito tempo.
Com o bug, é possível injetar comandos para execução pelo computador, mesmo no caso de usuários sem acesso direto à shell: é possível fazer isso alterando os cabeçalhos de uma conexão a um servidor web, por exemplo, ou por meio do protocolo de monitoramento SNMP, ou ainda pela autenticação de sessões SSH, entre outros vetores de ataque já identificados.
Injetando comandos, é possível controlar um computador remotamente, seja movendo para pastas públicas arquivos que deveriam ser privados, alterando configurações, forçando o download de arquivos remotos que contenham malware, e muitas outras atividades. É bem o tipo de vulnerabilidade que se presta à distribuição automática de malware, ou seja, worms, redes zumbis, etc. – e, como este é particularmente fácil de explorar, seria possível criar uma em larga escala, até porque muitos computadores conectados à web não terão seu upgrade do Bash realizado imediatamente.
Fique atento ao site de segurança do seu distribuidor de sistema operacional, e atualize o Bash assim que ele disponibilizar (alguns já disponibilizaram). Depois de atualizar, use as rotinas normais para verificar se o seu sistema chegou a ter a falha explorada e foi comprometido.
Para verificar se o seu Bash está vulnerável, você pode emitir o seguinte comando:
env x='() { :;}; echo vulneravel' bash -c 'false'
Se a palavra “vulneravel” for impressa na tela, você saberá que está.
E para ver com detalhes tudo o que já se sabe sobre o funcionamento e a gravidade da falha, visite o texto detalhado do Troy Hunt.
Mais do que no caso do bug Heartbleed, este parece ser o_caso que justifica os planos da Core Infrastructure Initiative de investir na segurança dos componentes básicos dos sistemas open source.
Fonte: BR-LINUX
Artigos relacionados:
-bash: /bin/rm: Argument list too long
Como definir variáveis de ambiente para apenas um processo no Bash Shell
Shell – Comando file
Solucionando problema Cannot execute /bin/bash: Permission denied no Linux
Bash shell – Explicando variáveis de ambiente – O que são e o básico de sua utilização
Como resolver o problema do limite de exclusão/cópia/movimentação de arquivos no Linux
Como deslogar / sair do Bash Shell sem salvar o histórico da sessão corrente
Verificar via linha de comando todas as opções existentes de servidor ftp disponíveis no repositório Debian
Como determinar o melhor BS para o comando dd