gutocarvalho.net

Tecnologia, cotidiano e vida geek.

Entenda o bug shellshock

| Comments

1. ShellShock ou Bash Bug?

Eu estava PuppetConf’2014 quando esse bug foi noticiado no dia 24 de Setembro, havia um grande número de especialistas no evento e teve muita gente preocupada, lendo e acessando seus servidores para tentar entender, checar e mitigar o problema.

O shellshock, bashdoor ou bashbug é um bug gravíssimo que foi encontrado no shell bash pelo especialista Stephane Schazelas, o bug está presente em diversos sistemas operacionais Linux e Unix.

2. Shell?

O shell é um interpretador de comandos que permite que nós usuários e também que programas acessem serviços e recursos do sistema operacional Unix/Linux.

O bash é apenas um dos diversos tipos de shell (interpretadores de comandos) existentes, porém, ele é o mais comum e está presente em praticamente todo sistema operacional Unix e Linux.

3. Impacto

O bug foi encontrado desde a versão 1.14 até a versão 4.3, em resumo todas as releases dos últimos 22 anos são afetadas já que a versão 1.14 foi lançada em 1992.

O alcance desse bug está na casa dos milhões de servidores (NIX) no planeta, incluindo ai nessa lista, computadores pessoais MACS (OSX) e até os seguros sistemas BSD.

Ok, mas onde o bash é utilizado em meu sistema operacional? em que momento ele é carregado?

4. Entendendo o problema

Sempre que criamos um usuário no UNIX ou LINUX normalmente o shell bash é associado a essa conta, com isto, é possível se conectar ao sistema operacional utilizando ssh e telnet, por exemplo.

Quando instalamos algum sistema ou serviço, este também pode utilizar o bash para executar algo ou para definir alguma variável de ambiente necessária para seu funcionamento.

É possível inclusive rodar comandos remotamente no bash utilizando ssh.

5. Como exploram a falha?

A vulnerabilidade permite que atacantes executem código arbitrário em determinadas situações e condições, normalmente via rede.

Utilizando algumas strings e variáveis de ambiente eles conseguem escalar privilégios de um usuário normal e acessar recursos protegidos.

5.1 Exploits

Alguns posts sobre exploits criados para explorar o shellshock

  • https://www.alienvault.com/open-threat-exchange/blog/attackers-exploiting-shell-shock-cve-2014-6721-in-the-wild

  • https://isc.sans.edu/diary/Shellshock%3A+A+Collection+of+Exploits+seen+in+the+wild/18725

  • http://www.fireeye.com/blog/uncategorized/2014/09/shellshock-in-the-wild.html

Já existe inclusive um malware/botnet chamado WOPBOT explorando sites vulneráveis.

  • http://www.itnews.com.au/News/396197,first-shellshock-botnet-attacks-akamai-us-dod-networks.aspx

6. Quais os principais serviços afetados?

  • Apache HTTP que utiliza CGI Scripts (mod_cgi e mod_cgid).
  • Servidores OpenSSH com ForceCommand
  • Dhclient
  • CUPS

Por hora são esses, mas qualquer serviço que dependa do bash está potencialmente afetado.

7. Bugs conhecidos

O primeiro bug relatado foi o CVE-2014-6271, este teve um fix publicado que não foi completo e mais problemas foram detectados, com isso, foram registradas novas falhas, são elas: CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186 e CVE-2014-7187.

O CVE é uma das maiores e mais respeitadas base de dados de segurança que contém dados do tipo vulnerability (erros de implementação em softwares) e exposure (falhas de configuração ou de uso de software), quando um bug é encontrado normalmente é registrado no CVE primeiro.

7.1 CVE-2014-6271

Este foi o primeiro bug encontrado, para verificar se seu bash está exposto a este bug, rode o comando abaixo em uma sessão sem privilégios

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

Se aparecer a mensagem “vulnerable” você precisa atualizar seu bash.

  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

7.2 CVE-2014-7169

Esse bug permite que o atacante crie ou modifique arquivos além de ler arquivos que ele não teria privilégios, e também pode acessar partes protegidas do sistema, esse bug existe por correções incompletas no CVE-2014-(6271, 6277 e 6278).

Para testar se seu bash está vulnerável a este bug rode o comando abaixo em um sessão comum:

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

Se a data e hora - saída do comando date - retornar após a execução, seu sistema está vulnerável.

  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

7.3 Outros relacionados

Já corrigidos

  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6277
  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6278

Ainda sem correções até o momento (2014-10-01)

  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7186
  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7187

8. Testando meu servidor

8.1 HTTP Check

Você pode acessar essa URL e testar se seu site está vulnerável, ele usa alguns exploits HTTP para fazer a verificação

  • http://shellshock.brandonpotter.com

O gutocarvalho.net está limpo ;)

8.2 RedHat HTTP Check

Se você tem conta na RHN pode fazer o teste pela ferramenta da fabricante

  • https://access.redhat.com/labs/shellshock/

9. Informações de fornecedores

Alguns links para sites de fornecedores e organizações.

9.1 Redhat

Artigos

  • https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

  • https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/

Alertas

  • https://access.redhat.com/announcements/1210053
  • https://access.redhat.com/articles/1200223

Sobre malwares que exploram o shellshock

  • https://access.redhat.com/articles/1213683

9.2 Debian

  • https://www.debian.org/security/2014/dsa-3032
  • https://www.debian.org/security/2014/dsa-3035

9.3 Ubuntu

  • http://www.ubuntu.com/usn/usn-2362-1/
  • http://www.ubuntu.com/usn/usn-2363-1/
  • http://www.ubuntu.com/usn/usn-2364-1/

9.4 Suse

  • https://www.suse.com/support/shellshock/
  • https://www.suse.com/support/update/announcement/2014/suse-su-20141260-1.html
  • https://www.suse.com/support/update/announcement/2014/suse-su-20141259-1.html

9.5 Apple

  • http://support.apple.com/kb/DL1769?viewlocale=en_US&locale=en_US
  • http://support.apple.com/kb/HT1222

Leia e se informe, se tiver suporte comercial (RHEL/SLES) abra um ticket e peça apoio na verificação de seu parque.

Se preocupe principalmente com os seus servidores na DMZ.

10. Atualizando seu servidor manualmente

Aqui vão as dicas para você atualizar o bash no braço!

10.1 Redhat/Centos

yum install bash

10.2 Debian

aptitude install bash

10.3 Suse 12

zypper in -t patch SUSE-SLE-SERVER-12-2014-59

10.4 Apple MAC OSX

Aceite a atualização, apenas isto.

11. Atualizando o bash com ferramentas inteligentes

11.1 Puppet + Mcollective

Caso você tenha puppet em seu ambiente, você pode colocar o código abaixo em uma classe comum a todos os nodes

package { 'bash': ensure => latest }

Depois disto aguarde o agente pegar o novo catálogo e aplicar as mudanças.

Caso você tenha o mcollective em seu parque, após o ajuste na classe, acione o puppet em todos os nodes via plugin para não ter que esperar pelos agentes.

mco puppet agent runonce

11.2 Mcollective

Se você tem Mcollective mas não tem puppet, tudo bem, dá para rodar o seguinte comando

mco package update bash

Esse comando vai forçar a atualização do pacote bash em todos os nodes com o mcollective.

Mesmo que você tenha especificado e declarado no puppet que o bash deve ser estar sempre na última versão, esse comando é valido como uma outra garantia para que o pacote seja atualizado.

12. Recomendações

12.1 Devo reiniciar meus servidores afetados?

Olha se você tem janela e condições para isto, e principalmente se seu problema for relacionado a seu servidor de aplicações web, reiniciar vai descarregar completamente da memória as versões antigas do bash :)

Caso você não tenha janela, após atualizar, mate as sessões remotas para forçar os usuários a recarregarem o screen/tmux/afins e reinicie os serviços que dependem do bash, já vai resolver.

12.2 O SELINUX ajuda a diminuir o problema?

Um dos especialistas em SELINUX testou um exploit HTTP contra o SELINUX e fez um post explicando como o SELINUX se comportou e como diminui o estrago que o exploit poderia ter causado ao sistema que recebeu o teste.

12.3 Posso definir outro shell como padrão?

Pode, mas cada sistema operacional oferece uma forma diferente de fazer isto, recomendo por exemplo o ZSH, ele é um excelente shell, você definir o ZSH como shell padrão dos usuários até resolverem essa questão do bash.

Na parte de serviços é necessário fazer testes para ver se o serviço consegue utilizar um shell diferente do BASH, recomendo subir uma VM e testar antes de qualquer mudança.

Vale mencionar que no Debian o shell padrão é o dash, logo o problema para usuários debian é um pouco menor, mas o bash vem instalado no sistema, então é bom atualizar.

13. Amarrando as pontas

Há alguns meses abordamos aqui o terrível bug Heartbleed, mas tenho que dizer que dizer que o shellshock não fica atrás em importância e impacto, tem muita gente na web inclusive considerando o shellshock maior que o heartbleed devido a presença do bash em praticamente qualquer sistema operacional *NIX.

Eu ainda vou esperar, é muito cedo para comparar, nenhum estrago grande foi detectado ou divulgado até o momento.

Contudo, não perca tempo, pesquise e defina a melhor estratégia para atualizar o seu parque o quanto antes, mas não se afobe, faça com calma para fazer direito.

E não pare de estudar pois nem todos os bugs foram corrigidos até o final deste post (2014-10-01), continue acompanhando, lendo e checando o seu ambiente.

Converse com suas equipes de segurança para que eles verifiquem junto a fornecedores de appliances se tem novas ACLs ou RULES para bloquear as botnets e exploits HTTP e considere ativá-los como mais uma camada de segurança.

14. Referências

CVE

  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6277
  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6278
  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7186
  • http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7187

MISC

  • http://www.theverge.com/2014/9/24/6840697/worse-than-heartbleed-todays-bash-bug-could-be-breaking-security-for

  • http://www.theverge.com/2014/9/25/6843669/bash-shellshock-network-worm-could-cause-internet-meltdown

  • http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it/

  • http://arstechnica.com/apple/2014/09/apple-patches-shellshock-bash-bug-in-os-x-10-9-10-8-and-10-7/

  • http://arstechnica.com/apple/2014/09/apple-patches-shellshock-bash-bug-in-os-x-10-9-10-8-and-10-7/

  • https://www.digitalocean.com/community/tutorials/how-to-protect-your-server-against-the-shellshock-bash-vulnerability

  • http://www.techradar.com/news/internet/bash-vulnerability-could-be-worst-ever-1266830

  • http://www.techradar.com/us/news/computing/apple/apple-majority-of-os-x-users-are-safe-from-bash-bug-1267048

  • http://www.techradar.com/news/computing/apple/apple-releases-bash-bug-patch-for-os-x-1267228

  • http://blog.cloudflare.com/inside-shellshock/

MYSQL TMPDIR em TMPFS com SELINUX ativado

| Comments

Eu sou daqueles caras teimosos que insiste em usar o SELINUX ao invés de desligar ele após a instalação do servidor :)

Eis que estava montando um servidor MYSQL para o Zabbix no CentOS 6.5 e resolvi criar um diretório temporário para o MYSQL em um TMPFS para obter uma melhor performance do Zabbix.

Basicamente fiz o seguinte

service mysqld stop

Criei o diretório

mkdir /mytmp

No my.cnf coloquei o seguinte

tmpdir=/mytmp

No fstab coloquei o seguinte

tmpfs           /mytmp          tmpfs  rw,uid=mysql,gid=mysql,size=1g,nr_inodes=10k,mode=0775 0 0

Montei o tmpfs

mount /mytmp

Iniciei o mysql

service mysqld start

Porém, quando eu iniciava o MYSQL, os seguintes erros apareciam no LOG

/usr/libexec/mysqld: Can't create/write to file '/tmpfs/ibbBLVnW' (Errcode: 13)
140829 12:23:42  InnoDB: Error: unable to create temporary file; errno: 13
140829 12:23:42 [ERROR] Plugin 'InnoDB' init function returned error.
140829 12:23:42 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

O sintoma do lado da aplicação era um access denied na conexão com o banco, os desavisados podem perder muito tempo tentando acertar permissões mas não é esse o problema, isto ocorria pois o MySQL não conseguia escrever no ponto de montagem TMPFS, veja o erro no detalhe

/usr/libexec/mysqld: Can't create/write to file '/tmpfs/ibbBLVnW' (Errcode: 13)

Sabendo que o SELINUX estava ligado fui olhar no /var/log/audit/audit.log

cat /var/log/audit/*.log |grep mysql|grep -v zabbix|grep tmpfs

Encontrei então a seguinte informação

type=AVC msg=audit(1408993827.194:10192): avc:  denied  { write } for  pid=28603 comm="mysqld" name="/" dev=tmpfs ino=708243 scontext=unconfined_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir

No log acima é possível ver que o MYSQL tentou escrever em um diretorio da raiz que montava um TMPFS e não conseguiu devido ao contexto do diretório, tive então que checar o contexto do diretório, para isto eu rodei o comando abaixo

ls -Z /|grep mytmp

A saída recebida foi esta

drwxr-xr-x. root  root  unconfined_u:object_r:default_t:s0 mytmp

Veja que o conexto acima está com o tipo default_t, e neste caso, quando o SELINUX está ativo, o mysql não consegue escrever no diretório.

Para resolver a questão foi necessário ajustar o contexto do diretório para mysqld_db_t, só assim o mysql terá condições de escrever dentro dele.

Usei o semanage para definir o contexto default do diretório

semanage fcontext -a -t mysqld_db_t "/mytmp(/.*)?"

E depois rodei um restorecon para corrigir o contexto do diretório

restorecon -Rv /mytmp/

Acompanhe a saída do restorecon

restorecon reset /mytmp context unconfined_u:object_r:tmp_t:s0->unconfined_u:object_r:mysqld_db_t:s0

Feito isto, iniciei o MYSQL sem erros no log.

Os erros na aplicação também foram solucionados.

O processo é o mesmo se deseja colocar o diretório DATA do MYSQL em outro local em um servidor com SELINUX ativado.

[s]
Guto