ansible-mysql-cve-2016-6662

Simple playbook ansible pour patcher les serveurs mysql contre la CVE-2016-6662.

MISE À JOUR

• 20160915.2347.CEST: Kenny m'a informé de la découverte de Patrick Forsberg : le correctif original ne protégeait pas contre l'abus de '../'. J'ai maintenant remplacé le correctif par un plus strict (basé sur un mélange de ceux de Percona et MySQL), et j'ai également ajouté une tâche qui supprime le correctif Percona s'il était déjà appliqué.

Résumé de la CVE

En bref, il essaiera d'écrire un .so malveillant dans le système de fichiers et de modifier votre configuration pour le charger au prochain redémarrage du service.

Résumé du correctif

Ce correctif ne prévient pas l'attaque elle-même, mais il modifie mysqld_safe afin que les fichiers .so ne soient chargés que depuis les emplacements système standard, où mysqld ne peut pas écrire. Il vérifiera également l'existence et les permissions de divers fichiers de configuration par défaut que mysqld pourrait prendre en compte, pour empêcher le code malveillant de les créer ou de les modifier.

Comment utiliser

• Spécifiez les cibles du playbook avec --extra-vars='targets=host1,host2' pour ansible-playbook
• Si vous voulez que le script corrige les fichiers de configuration par défaut au lieu de simplement les signaler, passez --extra-vars='fs_fix_permissions=true' à ansible-playbook

La version longue

Le problème complet est disponible sur https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6662 ; Kenny Gryp de Percona a publié une explication brève mais excellente sur https://www.percona.com/blog/2016/09/12/database-affected-cve-2016-6662/ .

Ce playbook essaiera d'appliquer un correctif personnalisé qui est un mélange du correctif Percona dans https://github.com/percona/percona-server/commit/c14be53e029442f576cced1fb8ff96b58e89f2e0#diff-144aa2f11374843c969d96b7b84247eaR261 et du correctif MySQL sur https://github.com/mysql/mysql-server/blob/5.7/scripts/mysqld\_safe.sh#L356-L364 .

Il va :

• Installer le paquet patch standard s'il n'est pas présent
• Trouver l'emplacement de votre exécutable mysql_safe en utilisant which
• Supprimer le correctif Percona s'il a été appliqué
• Tenter de patcher mysqld_safe
• Supprimer à nouveau patch si c'est nous qui l'avons installé
• Vérifier et éventuellement sécuriser la liste des fichiers de configuration par défaut que mysqld essaie de lire

J'ai vérifié cela sur près d'une centaine d'installations - principalement Debian, quelques RedHat et Suse. Cette nouvelle version a été appliquée sur près de 200 hôtes, sans problème apparent.

J'ai observé que patch échoue sur les configurations 5.1, car le script mysql_safe ne contient pas les points d'ancrage - mais cette version (et les inférieures) n'est pas non plus vulnérable, donc ce n'est pas un problème.

Notez qu'une valeur changed= de 0 ou 2 signifie qu'aucun correctif n'a été effectué (2 si installé et supprimé patch); 1 ou 3 signifie que le correctif a été effectué. Les autres valeurs sont inattendues et doivent être étudiées :-) Avec la tâche supplémentaire, ce n'est plus aussi clair ; vous devrez lire la sortie.

Merci à Kenny Gryp, Percona et MySQL pour l'explication claire et la solution de contournement facile ; merci supplémentaire à Patrick Forsberg pour avoir repéré le défaut dans le correctif original.

/vegi