Vor ein paar Tagen habe ich im Blog von Marius gelesen dass es für eine kritische MySQL Lücke noch keinen Patch für MariaDB im Fedora Repository gibt. Jetzt wollte ich mal analysieren:
Was ist das für eine Lücke?
Was nutzt sie aus?Wie nutzt man sie aus?
Prinzipiell nutzt der Exploit mehrere Sachen aus.
Erstmal kann man beim CREATE TABLE bei MySQL mitgeben in welchem Ordner diese erstellt werden soll:
CREATE TABLE poctab (txt varchar(50)) engine = 'MyISAM' data directory '/tmp/disktable';
Somit kann man Tabellen in einem Ordner erstellen den man selber kontrollieren kann (also z.B. /tmp).
Der nächte Trick ist dann die Funktionsweise des Befehls „REPAIR TABLE“. Dieser Repair-Table erzeugt eine Kopie der Originaltabelle (im gleichen Ordner), kopiert dann die Recht der Originaltabelle auf die Kopie, und arbeitet dann mit der Kopie.
Hier kommt nun der Trick: Wenn wir der Originaltabelle die Rechte 0777 geben, so ist sie für jeden schreibbar. Wenn wir nun zwischen dem Moment wo der Mysql-Prozess (der ja unter dem User ‚mysql‘ läuft) die Rechte der Originaltabelle einliest und dem Moment wo er diese Rechte auf die Kopie anwendet, einfach die Kopie durch einen Symlink zu (z.B.) ‚/var/lib/mysql‘ ersetzen, so hat der Mysql-Server selbst diesen Ordner mit den Rechten 0777 für alle schreib und lesbar gemacht. Nett 🙂
Ds ganze ist quasi ein Wettrennen mit dem Mysql-Server, das Timing ist sehr wichtig denn wir müssen exakt im richtigen Moment die Datei ersetzen. Deshalb heißt das ganze auch in der Fachsprache „Race Condition“.
Der Exploit geht aber noch ein kleines Stückchen weiter – er erzeugt erst einen Ordner in /tmp mit dem GROUP Bit. Somit bekommt jede neu erzeugte Datei in diesem Ordner als Gruppe die Gruppe unseres Users.
Dies ist nötig da Mysql sonst die Tabellenrechte dem User ‚mysql‘ und der Gruppe ‚mysql‘ gibt und wir nichts dran ändern können.
Nach dem setzen des Group-Bit bekommt aber jede Tabellendatei die dort erstellt wird den User ‚mysql‘ und unsere Gruppe und wir haben schonmal read und write Rechte drauf. Praktisch 🙂
Das nächste ist nun eine ‚/bin/bash‘ mit gesetzem setUID-Bit da hineinzukopieren, indem man irgendeine Tabelle die man vorher erzeugt hat ersetzt. Somit haben wir in diesem Ordner eine Bash die dem User ‚mysql‘ und unserer Gruppe gehört und das setUID-Bit gesetzt hat.
(setUID-Bit bedeutet dass beim Starten dieser Bash der Prozessuser nicht der startende User ist, sondern der User der die Datei bestitzt. Dieses Bit ist nötig damit auch ein unpriviligierter Nutzer (mittels dem Programm passwd) sein Passwort ändern und in die Datei ‚/etc/shadow‘ schreiben darf, was eigentlich nur root kann. ‚passwd‘ läuft also unter dem User ‚root‘, egal wer es startet.)
Einziges Problem nun noch zu diesem Zeitpunkt: Die Rechte der Bash erlauben kein Ausführen. Und da wir nicht der Besitzer der Datei sind dürfen wir auch kein chmod machen. Das darf nur der Besitzer der Datei – also der User ‚mysql‘.
Jetzt passen wir von einer anderen Tabelle im gleichen Ordner die Rechte auf 0777 an, lassen mysql diese Tabelle reparieren, und im richtigen Moment ersetzen wir die Temp-Table durch unsere kopierte Bash.
Somit hat der Mysql-Server selbst (der ja die Shell-Datei besitzt) uns die Rechte 0777 darauf gesetzt. Starten wir nun die Datei haben wir eine Bash die unter dem User ‚mysql‘ läuft und dürfen alles tun was der Datenbankserver auch tun kann.
Es gibt unter der Originalen Info zu diesem Exploit einen C-Code der genau das macht. Er braucht ein paar Dutzend bis in etwa 100 Versuche und dann war das Timing richtig und man hat eine Bash als User ‚mysql‘.
Fies 🙂
Hier gehts zum Original-Beitrag zu diesem Exploit: legalhackers.com
Die meisten Distributionen haben diesen Bug natürlich schon längst gefixt. Meine MariaDB 10.1 wurde über die eigenen Repositorys von MariaDB schon am 30.09.2016 gepatcht.
Und wenn man wissen will was der Patch nun groß repariert hat, das findet man hier für MySQL und hier für MariaDB.
Zusammenfassend: Es werden beim Repair Table einfach nicht mehr die Rechte der Originaltabelle auf die Kopie angepasst, denn die Kopie hat eigentlich sowieso schon die richtigen Rechte.
Und für wen das jetzt zu kompliziert war: Lest euch mal durch was bei Dirty Cow (CVE-2016-5195) im Linux Kernel passiert. Das ist auch eine Race Condition, aber eine mit ein paar Threads, ein paar Kernel-Threads und ein bisschen Vodoo (Copy on Write und Dirty Flags…)
Wen interesse besteht bitte melden, vielleicht mach ich mir die Arbeit das zu erklären. Und wenn jemand hier was nicht verstanden hat bitte auch melden. Ich helfe gerne.
Schreibe einen Kommentar