Tag Archives: mariadb

Noch keine Patches für MariabDB Root Exploits vorhanden

Posted on by

Für die u.a. bei The Hacker News gemeldeten Root-Exploits für MariaDB gibt es noch keine Patche im Fedora Repository, auch nicht im Unstable Bereich. Da hilft nur, den möglichen Exploit durch Verschleierung zuvermeiden.

Der bereits verfügbare Testexploit, legt Dateien im /tmp/ Ordner an. Das kann man schon mal verhindern, indem beim Start mit Systemd ein privates Temp-Verzeichnis benutzt wird. Das verhindert den Hack nicht, aber die kleinen Scriptkids werden an der Hürde scheitern 😉

Wenn man sein mariadb.service File nicht geändert hat, kommt es in Fedora bereits mit der richtigen Einstellung:

[Unit]
Description=MariaDB 10.0 database server
…
# Place temp files in a secure directory, not /tmp
PrivateTmp=true
…

In der my.cnf sollte man sowieso immer das Benutzen von Symbolischen Links abschalten, eine Serverdatenbank braucht das i.d.R. nicht:

symbolic-links=0

Damit kann man auch ohne Patch CVE-2016-6662 nicht ausnutzen um seine Rechte zu eskalieren. Wer bislang „mariadb-10.0.27-1“ noch nicht eingespielt hat, sollte das trotzdem dringend nachholen.

Gegen die Lücken CVE-2016-6663 und CVE-2016-6664 sind die Patche bei Fedora noch in Arbeit. Leider ist auch im Koji noch keine Testversion ersichtlich. Die letzten Builds stammen vom Anfang des Monats, welche zudem die CVE Patche nicht enthalten. Dies kann natürlich daher rühren, daß diese Versionen nicht anfällig waren, da es sich um den 10.1.17/18 er Zweig von Mariadb handelt.

2038 ist schneller da als man denkt

Posted on by

In 23 Jahren, wenn die Unixwelt Y2K erlebt, wird die Welt zusammenbrechen.

Wir haben ja jetzt 2015 und die gängigste Datenbank MySQL legt Timestampfelder immer noch als 32-Bit Feld an. Es sollte ja eigentlich kein Problem sein dort intern 64-Bit zu benutzen, aber wie das so ist, die Tücke liegt im Detail.

MySQL speichert die Daten in einer großen Datei im Binärformat. In dem Augenblick wo dieser Feldtype auf 64-Bit umgestellt wird, muß zwangsweise mysql_upgrade laufen, sonst gibt es nur Probleme. Und wie das Leben so spielt,  mysql_upgrade wird bei normalen Updates eigentlich nie ausgeführt. Da muß man als Admin selbst machen.

„Wenn das noch 23 Jahre sind, warum nervst Du jetzt schon rum?“

Ich kenne Euch halt 🙂 Dabei wollte ich auf etwas anderes hinaus:

Führt öfter mal mysql_upgrade durch. Erst dieser Befehl schreibt die Strukturen im Mysql um z.b. wenn neue Felder in der „mysql“ Datenbank hinzugekommen sind. Mit den Updates von Fedora 20 auf 21 z.b. mußte so ein mysql_upgrade auch zwangsweise laufen, wenn man die neuen „Features“ benutzen wollte.

Zurück zum Jahr 2038. Es werden dann mehr als 40 Jahre zwischen den Leuten liegen, die Y2K mitgeplant haben und denen, die dann für die Systeme verantwortlich sind. Da darf man annehmen, daß die meisten das auf die gleiche leichte Schulter nehmen werden, wie Ihre Vorfahren.

Deswegen wünsche ich heute schon einen schönen Weltuntergang 😉

Tip: Update der Inhalte eines SQL Views

Posted on by

In einer Datenbank wie MySQL kann man sich Selects als Pseudotabellen anlegen und dann selbst wieder über den diese Tabelle einen Select bauen. So etwas nennt man einen View.

Beispiel:

SELECT a.vorname,a.name,b.beruf as beruf FROM Personen as a,Berufe as b WHERE a.berufsid=b.id;

Wenn man diesen Select als View anlegt, hat man drei Felder : Vorname,Name,Beruf

Nennen wir den View mal Test, wäre dieser Select möglich :

SELECT vorname,name FROM Test WHERE beruf = „Bäcker“;

Wenn man nun versucht den VIEW mit UPDATE zu ändern, geht das eigentlich nicht, weil es eine nicht eindeutige Beziehung der Datensätze untereinander ist.

Für mein aktuelles Pandora Projekt habe ich nun einen View gebaut, bei dem das Update tatsächlich möglich ist:

select `pa`.`id` AS `id`,`pa`.`vorname` AS `vorname`,`pa`.`nachname` AS `nachname`,`pa`.`server` AS `server`,`pc`.`value` AS `friendmode` from (`pandora`.`pandora_config` `pc` join `pandora`.`pandora_account` `pa`) where ((`pa`.`id` = `pc`.`uid`) and (`pc`.`name` = ‚michsuchen‘))

Das funktioniert aufgrund dieser Beziehung „((`pa`.`id` = `pc`.`uid`)“ , denn in beiden Tabellen gibt es exakt einen eindeutigen Datensatz. d.b. :

Für jede Person gibt es exakt einen Config Eintrag in der anderen Tabelle. Damit kann der Datenbankserver jetzt die logische Verbindung der Datensätze „rückwärts“ auflösen und in der richtigen Tabelle den richtigen Eintrag ändern:

UPDATE `pandora_userliste` SET friendmode = ‚erlauben‘ WHERE vorname =’meinvorname‘;

Damit ist der View Read/Writeable geworden was es man mit Hilfe des ORDB Frameworks ausnutzen kann, denn Views werden ein Java Datenobjekte erzeugt. Über Views lassen sich schlanke Strukturen und Datenbankobjekte erzeugen, die dazu noch updatefähig sein können (aber nicht müssen). Als Folge davon erhält man übersichtliche Datenbankstrukturen, die von einem Menschen leicht gelesen und verstanden werden können, aber trotzdem Datenbanktechnisch höchst performant gestaltet sein können.