ansible-mysql-cve-2016-6662

Playbook Ansible simples para corrigir servidores MySQL contra o CVE-2016-6662.

ATUALIZAÇÃO

• 20160915.2347.CEST: O Kenny me informou sobre a descoberta do Patrick Forsberg de que o patch original não protegia contra abuso de ../. Agora substituí o patch por um mais rigoroso (baseado em uma mistura dos patches da Percona e do MySQL) e também adicionei uma tarefa que remove o patch da Percona se ele já tiver sido aplicado.

Resumo do CVE

Em resumo, ele tentará gravar um .so malicioso no sistema de arquivos e modificar sua configuração para carregá-lo na próxima reinicialização do serviço.

Resumo do patch

Este patch não impede o ataque em si, mas modifica o mysqld_safe para que arquivos .so sejam carregados apenas dos locais padrão do sistema, onde o mysqld não pode gravar. Ele também verificará a existência e as permissões de vários arquivos de configuração padrão que o mysqld pode ler, para impedir que código malicioso os crie ou modifique.

Como usar

• Especifique os alvos do playbook como --extra-vars='targets=host1,host2' para o ansible-playbook
• Se você quiser que o script corrija os arquivos de configuração padrão em vez de apenas reportá-los, passe --extra-vars='fs_fix_permissions=true' para o ansible-playbook

Mais detalhes

O problema completo está disponível em https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6662 ; Kenny Gryp, da Percona, publicou uma explicação breve, porém excelente, em https://www.percona.com/blog/2016/09/12/database-affected-cve-2016-6662/ .

Este playbook tentará aplicar um patch personalizado que é uma mistura do patch da Percona em https://github.com/percona/percona-server/commit/c14be53e029442f576cced1fb8ff96b58e89f2e0#diff-144aa2f11374843c969d96b7b84247eaR261 e do patch do MySQL em https://github.com/mysql/mysql-server/blob/5.7/scripts/mysqld\_safe.sh#L356-L364 .

Ele irá:

• Instalar o pacote padrão patch se não estiver presente
• Localizar o caminho do executável mysql_safe usando which
• Remover o patch da Percona se ele foi aplicado
• Tentar aplicar o patch no mysqld_safe
• Remover o patch novamente se fomos nós que o instalamos
• Verificar e, opcionalmente, proteger a lista de arquivos de configuração padrão que o mysqld tenta ler

Eu verifiquei isto em cerca de cem instalações - principalmente Debian, algumas RedHat e Suse. Esta nova versão foi aplicada em quase 200 hosts, sem problemas óbvios.

Observei o patch falhar em instalações 5.1, pois o script mysql_safe não contém os pontos de ancoragem - mas essa versão (e anteriores) também não é vulnerável, então isso não é um problema.

Observe que um valor changed= de 0 ou 2 significa que nenhum patch foi aplicado (2 se instalou e removeu o patch); 1 ou 3 significa que o patch foi executado. Outros valores são inesperados e devem ser investigados :-) Com a tarefa extra, não é mais tão simples; você precisará ler a saída de verdade.

Agradecimentos a Kenny Gryp, Percona e MySQL pela explicação clara e pela solução alternativa fácil; agradecimento extra a Patrick Forsberg por ter detectado a falha no patch original.

/vegi