ansible-mysql-cve-2016-6662

Playbook simple de Ansible para parchear servidores MySQL contra CVE-2016-6662.

ACTUALIZACIÓN

• 20160915.2347.CEST: Kenny me informó del hallazgo de Patrick Forsberg de que el parche original no protegía contra el abuso de ../. Ahora he sustituido el parche por uno más estricto (basado en una combinación de los de Percona y MySQL), y también he añadido una tarea que elimina el parche de Percona si ya se había aplicado.

Resumen de CVE

En resumen, intentará escribir un .so malicioso en el sistema de archivos y modificar tu configuración para cargarlo en el siguiente reinicio del servicio.

Resumen del parche

Este parche no evitará el ataque en sí, pero modifica mysqld_safe para que los archivos .so solo se carguen desde las ubicaciones estándar del sistema, donde mysqld no puede escribir. También comprobará la existencia y los permisos de varios archivos defaults que mysqld podría leer, para evitar que código malicioso los cree o modifique.

Cómo usar

• Especifica los objetivos del playbook como --extra-vars='targets=host1,host2' a ansible-playbook
• Si quieres que el script corrija los archivos defaults en lugar de solo informar sobre ellos, pasa --extra-vars='fs_fix_permissions=true' a ansible-playbook

Más detalles

El problema completo está disponible en https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6662 ; Kenny Gryp de Percona ha publicado una explicación breve pero excelente en https://www.percona.com/blog/2016/09/12/database-affected-cve-2016-6662/ .

Este playbook intentará aplicar un parche personalizado que es una mezcla del parche de Percona en https://github.com/percona/percona-server/commit/c14be53e029442f576cced1fb8ff96b58e89f2e0#diff-144aa2f11374843c969d96b7b84247eaR261 y del parche de MySQL en https://github.com/mysql/mysql-server/blob/5.7/scripts/mysqld\_safe.sh#L356-L364 .

Hará lo siguiente:

• Instalar el paquete estándar patch si no está presente
• Localizar la ubicación de tu ejecutable mysql_safe usando which
• Eliminar el parche de Percona si se aplicó
• Intentar parchear mysqld_safe
• Eliminar patch de nuevo si fuimos nosotros quienes lo instalamos
• Comprobar y, opcionalmente, asegurar la lista de archivos defaults que mysqld intenta leer

He verificado esto en cerca de un centenar de instalaciones, sobre todo Debian, un par de RedHat y Suse. Esta nueva versión se ha aplicado en casi 200 hosts, sin problemas evidentes.

He observado que patch falla en entornos 5.1, ya que el script mysql_safe no contiene los puntos de anclaje, pero esa versión (y las anteriores) tampoco es vulnerable, así que no es un problema.

Ten en cuenta que un valor de changed= de 0 o 2 significa que no se realizó ningún parche (2 si se instaló y eliminó patch); 1 o 3 significa que el parche se llevó a cabo. Otros valores son inesperados y deben investigarse :-) Con la tarea adicional, ya no es tan evidente; tendrás que leer realmente la salida.

Gracias a Kenny Gryp, Percona y MySQL por la explicación clara y la solución sencilla; agradecimiento especial a Patrick Forsberg por detectar el fallo en el parche original.

/vegi