ansible-mysql-cve-2016-6662

Ein einfaches Ansible-Playbook, um MySQL-Server gegen CVE-2016-6662 zu patchen.

AKTUALISIERUNG

• 20160915.2347.CEST: Kenny informierte mich über Patrick Forsbergs Entdeckung, dass der ursprüngliche Patch keinen Schutz vor ../-Missbrauch bot. Ich habe den Patch nun durch einen strengeren ersetzt (basierend auf einer Mischung aus den Percona- und MySQL-Patches) und zusätzlich eine Aufgabe hinzugefügt, die den Percona-Patch entfernt, falls er bereits angewendet wurde.

Zusammenfassung der CVE

Kurz gesagt versucht sie, eine schädliche .so-Datei auf das Dateisystem zu schreiben und Ihre Konfiguration so zu ändern, dass sie beim nächsten Dienstneustart geladen wird.

Zusammenfassung des Patches

Dieser Patch verhindert den eigentlichen Angriff nicht, aber er modifiziert mysqld_safe so, dass .so-Dateien nur aus den standardmäßigen Systempfaden geladen werden, in die mysqld nicht schreiben kann. Er prüft außerdem Existenz und Berechtigungen verschiedener Defaults-Dateien, die mysqld möglicherweise übernimmt, um zu verhindern, dass schädlicher Code sie erstellt oder verändert.

Verwendung

• Geben Sie die Ziele für das Playbook als --extra-vars='targets=host1,host2' an ansible-playbook an
• Wenn das Skript die Defaults-Dateien reparieren statt nur melden soll, übergeben Sie --extra-vars='fs_fix_permissions=true' an ansible-playbook

Die Langfassung

Der vollständige Sachverhalt ist unter https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6662 verfügbar; Kenny Gryp von Percona hat eine kurze, aber ausgezeichnete Erklärung unter https://www.percona.com/blog/2016/09/12/database-affected-cve-2016-6662/ veröffentlicht.

Dieses Playbook versucht, einen eigenen Patch anzuwenden, der eine Mischung aus dem Percona-Patch in https://github.com/percona/percona-server/commit/c14be53e029442f576cced1fb8ff96b58e89f2e0#diff-144aa2f11374843c969d96b7b84247eaR261 und dem MySQL-Patch unter https://github.com/mysql/mysql-server/blob/5.7/scripts/mysqld\_safe.sh#L356-L364 ist.

Es wird:

• Das Standardpaket patch installieren, falls es nicht vorhanden ist
• Den Speicherort Ihrer mysql_safe-Datei mit which ermitteln
• Den Percona-Patch entfernen, falls er angewendet wurde
• Versuchen, mysqld_safe zu patchen
• patch wieder entfernen, falls wir es installiert haben
• Die Liste der Defaults-Dateien prüfen, die mysqld zu lesen versucht, und sie optional absichern

Ich habe dies an nahezu hundert Installationen getestet – hauptsächlich Debian, ein paar RedHat- und Suse-Systeme. Die neue Version wurde auf fast 200 Hosts angewendet, ohne offensichtliche Probleme.

Ich habe beobachtet, dass patch bei 5.1-Setups fehlschlägt, da das mysql_safe-Skript die Ankerpunkte nicht enthält – aber diese Version (und niedrigere) ist ebenfalls nicht verwundbar, also ist das kein Problem.

Beachten Sie, dass ein changed=-Wert von 0 oder 2 bedeutet, dass kein Patch durchgeführt wurde (2, wenn patch installiert und wieder entfernt wurde); 1 oder 3 bedeutet, dass der Patch ausgeführt wurde. Andere Werte sind unerwartet und sollten untersucht werden :-) Mit der zusätzlichen Aufgabe ist das nicht mehr so eindeutig; man muss die Ausgabe tatsächlich lesen.

Dank an Kenny Gryp, Percona und MySQL für die klare Erklärung und den einfachen Workaround; besonderer Dank an Patrick Forsberg für das Entdecken des Fehlers im ursprünglichen Patch.

/vegi