Slackware Linux – Notícias sobre o desenvolvimento. Janeiro, 2015.

Slackware logo

A distribuição segue sendo atualizada, na maioria dos casos sendo contemplada com correções de segurança. O pacote openssl foi atualizado para a versão 1.0.1, seamonkey para a versão 2.32, thunderbird para a versão 31.4.0, firefox para a versão 35.0, freetype para a versão 2.5.5, o samba para a versão 4.1.16, e todos estes receberam patch para reparar falhas de segurança encontradas.

Além destes, outros pacotes e bibliotecas sofreram alterações, muitas vezes devido mesmo às modificações realizadas em pacotes relacionados. Entre eles, verificamos uma das principais, que foi a atualização do kernel Linux para a versão 3.14.29.

Outras modificações foram realizadas nos pacotes gcc, agora na versão 4.8.4, imapd e alpine para a versão 2.20, gdb para a versão 7.8.2, libtool para a versão 2.4.4, além de atualizar o ambiente gráfico fluxbox para a versão 1.3.6.

Anúncios

Shellshock: Como proteger seus servidores Unix, Linux e Mac

System

Este artigo, escrito por Steven J. Vaughan-Nichols para a ZDNet, nos trás informações relevantes a respeito da recente falha de segurança encontrada no interpretador de comandos Bash, incluso na grande maioria das distribuições GNU/Linux mas também podendo afetar os sistemas operacionais Unix e MacOS. Por isso resolvi escrever uma tradução livre dos pontos principais deste artigo, para que administradores de sistemas aqui no Brasil, e em outros países que falem a língua portuguesa, possam tentar contornar este problema, e manter seu parque de servidores o mais seguro possível com relação a esta vulnerabilidade.

O escritor já inicia seu artigo informando que, embora a falha de segurança seja uma séria ameaça aos sistemas operacionais supracitados, nem sempre um servidor que esteja executando o Bash estará vulnerável, a não ser sob determinadas condições. Primeiramente, o atacante precisa encontrar não apenas um sistema que esteja executando a versão deste interpretador de comandos sem as primeiras correções disponíveis, mas que também este sistema permita o acesso remoto a este shell. Portanto, caso você esteja executando um sistema que não contemple o ssh, rlogin, ou outro programa de desktop remoto, você provavelmente está seguro o suficiente.

Steven também nos alerta a respeito de um problema sério, com relação a dispositivos que trazem Linux embutido, como roteadores, switches ou appliances, e recomenda que, caso esteja utilizando equipamentos antigos e sem suporte, o que torna a correção do problema virtualmente impossível, então o melhor será substituí-los o mais brevemente possível.

Ele afirma também que, atualmente, o perigo maior quanto ao Shellshock é relacionado aos servidores pois, de acordo com o National Institute of Standards and Technology, a vulnerabilidade recebe a mais alta pontuação nos quesitos de impacto potencial e nível de explorabilidade. A Red Hat apresentou um relatório com os vetores de ataque mais comuns, que foram os seguintes:

Httpd ( servidor web ): Scripts CGI ( Common Gateway Interface ) são geralmente afetados pela vulnerabilidade. Quando um script CGI é executado pelo servidor web, ele utiliza variáveis de ambiente para passar dados ao script. Essas variáveis de ambiente podem ser controladas pelo atacante. Se o script CGI chamar o Bash, o script poderia executar código arbitrário como se fosse o usuário httpd. Mod_php, mod_perl e mod_python não utilizam varáveis de ambiente, portanto acredita-se que não sejam afetados.

Secure Shell ( ssh ): Não é incomum a restrição de comandos remotos que um usuário pode executar via ssh, como rsync ou git. Nessas instâncias, essa vulnerabilidade pode ser utilizada para executar qualquer comando, não apenas um comando restrito.

Dhclient: O Dynamic Host Configuration Protocol Client é utilizado para obter automaticamente informações de configuração de rede via DHCP. Este cliente utiliza diversas variáveis de ambiente e utiliza o Bash para configurar a interface de rede. Conectar a um servidor DHCP malicioso poderia permitir ao atacante executar código arbitrário na máquina cliente.

CUPS ( servidor de impressão para Linux, Unix e Mac OS ): Acredita-se que o CUPS seja afetado por esta vulnerabilidade. Diversos valores fornecidos pelos usuários são armazenados em variáveis de ambiente quando os filtros do CUPS são executados.

Sudo: Comandos executados com o sudo não são afetados por essa vulnerabilidade. Ele procura especificamente por variáveis de ambiente que também são funções. Ainda seria possível para o comando em execução definir uma variável de ambiente que levaria a um processo filho do Bash a executar código arbitrário.

Firefox: Acredita-se que não seja possível que o Firefox seja forçado a definir variáveis de ambiente de uma forma que poderia permitir que o Bash executasse comandos de código arbitrário. Mesmo assim é recomendável realizar a atualização do Bash já que é comum a instalação de diversos plug-ins e extensões que poderiam permitir esse comportamento.

Postfix ( servidor de e-mail ): Este servidor vai substituir vários caracteres por um ponto de interrogação (?). Mesmo o Postfix executando chamadas ao Bash de diversas formas, acredita-se que não seja possível que ele configure variáveis de ambiente arbitrárias. Entretanto, é possível que um filtro possa configurar variáveis de ambiente.

Destes, o ataque aos servidores web parecem ser os mais comuns até o momento, sendo executados contra sistemas executando tanto Linux quanto Mac OS X. James Blasco, diretor de laboratórios na AlienVault, executou um honeypot a procura de atacantes e verificou diversas máquinas tentando explorar a vulnerabilidade do Bash. A maioria delas somente verificando se os sistemas estavam vulneráveis, mas também encontraram dois worms que estavam ativamente explorando a falha de segurança e instalando partes de malware no sistema. Outros pesquisadores descobriram que os atacantes tentam plantar IRC bots de ataques de negação de serviço, ao mesmo tempo que buscam por logins de usuários e senhas fracas, como ‘root’, ‘admin’, ‘user’ e ‘123456’.

James mostra então como verificar se o seu sistema está vulnerável, e para isso recomenda a execução do seguinte comando através do Bash:

env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

Se como resultado você obtiver:

vulnarable this is a test

Sinto muito, mas isso são más notícias pois seu sistema está vulnerável e você precisa tomar providências quanto a aplicação de correções o mais breve possível.

Se, como resultado, você obtiver:

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ this is a test

Então você está tão seguro quanto é possível estar no momento, pois essa versão provavelmente já tem alguma correção aplicada.

Embora a grande maioria das distribuições tenham liberado correções que impedem a maioria dos ataques, foi descoberto que as correções liberadas para essa vulnerabilidade são incompletas. Um atacante pode prover variáveis de ambiente com comandos arbitrários especialmente construídos e que serão executados em sistemas vulneráveis acessados, sob certas condições.

Enquanto ainda é incerto de que esses ataques possam ser utilizados para hackear o sistema, é bem claro que eles podem ser usados para travá-lo, graças a uma exceção de ponteiro nulo.

Neste meio tempo, recomenda-se que as correções disponíveis sejam aplicadas o mais rápido possível, e que se acompanhe o lançamento das novas correções, que já estão em desenvolvimento para cobrir a vulnerabilidade ainda existente no Bash.

Caso você tenha um servidor web Apache em execução, aqui vão algumas regras para o Mod_Security, compiladas pela Red Hat, que podem interromper tentativas de exploração do seu interpretador de comandos:

SecRule REQUEST_HEADERS “^\(\) {”

“phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

SERVER_PROTOCOL values:
SecRule REQUEST_LINE “\(\) {” “phase:1,deny,id:1000001,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

GET/POST names:
SecRule ARGS_NAMES “^\(\) {” “phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

GET/POST values:
SecRule ARGS “^\(\) {” “phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

File names for uploads:
SecRule FILES_NAMES “^\(\) {” “phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

O escritor ainda lembra ser vital a aplicação das correções já disponíveis, mesmo que estas ainda estejam incompletas, além de se certificar de que dispõe de defesas em torno de seus servidores web, evitando surpresas desagradáveis.

Novo marco, Slackware Linux 14.1 Release Candidate 3! Novembro, 2013.

Slackware logo

O estágio de terceira versão candidata da distribuição Slackware Linux 14.1 foi atingido e, com ele, algumas modificações foram implementadas quanto as versões dos pacotes que a integram. A plataforma de desenvolvimento integrada ao ambiente gráfico KDE, Kdevelop, foi atualizada para a versão 4.5.2, o navegador web Firefox agora é disponibilizado em sua versão 24.1.0 Oesr, além do pacote de aplicativos para escritório Calligra, que também recebeu atualização, tendo a versão corrente como a 2.7.4.

Além destas, algumas mudanças foram realizadas para corrigir pequenos problemas ou inserir melhorias, como a modificação no elilo, onde algumas possíveis mensagens de erro foram adicionadas ao seu arquivo de configuração eliloconfig, mudanças nas imagens usbboot.img e initrd.img fazem com que não sejam exibidas flashes na tela quando do escaneamento de partições com volumes lógicos, correção no pacote netwok-scripts para a remoção de um erro de digitação, entre outras modificações.

Para uma lista completa com as modificações mais atuais aplicadas à arvore current da distribuição Slackware Linux, acesse o changelog na página oficial do projeto.