hoch

Unterbinden von Load_file() in Mysql und MariaDB

Ich benötige zum Betreiben von Applikationen keine Dateizugriffe via Mysql. Wenn es weder Dateien vom Server noch vom Client braucht, fühle ich mich wohler, wenn die Funktion komplett deaktiviert ist, weil das ein offenes Scheunentor sein kann.

Um das Laden von Dateien innerhalb SQL zu vermeiden, gibt es in Mysql die Möglichkeit, in der Konfiguration den Dateizugriff zu unterbinden

[mysqld]
local-infile = 0|1 oder ON|OFF
secure_file_priv = [Wert]

Kurz in der Dokumentation die Werte nachlesen, ins Puppet kippen und auf alle Server verteilen.

Als Test, ob ich erfolgreich bin, dient der Aufruf … dieser muss NULL ausgeben und keinen Dateiinhalt.

#  mysql -e "SELECT  load_file('/etc/passwd');"
+--------------------------+
| load_file('/etc/passwd') |
+--------------------------+
| NULL                     |
+--------------------------+

Das war die Idee. Eigentlich klingt es einfach.
Leider verhalten sich aber die Einstellungen von Mysql und MariaDB unterschiedlich.

Der Wert für local-infile muss bei beiden 0 oder OFF sein. local-infile ist aber eine dynamische Variable - das ist aber lediglich der Startwert, der mit einem SQL Befehl in der laufenden Instanz neu gesetzt werden kann.

Heisst: es braucht zwingend den Wert für secure_file_priv, der sich wiederum NICHT zur Laufzeit verändern lässt.

(1)
Variante für Mysql:

[mysqld]
(...)
local-infile = 0
secure_file_priv = NULL
(...)

Danach einmal den Service neu starten systemctl restart mysql … dann habe ich das Verhalten wie in meinem Testaufruf.
Dieses Setup funktioniert nicht auf MariaDB - es wird mit einem Fehler in der Variable secure_file_priv beendet.

Die Dokumentation sagt: wenn secure_file_priv fehlt, würde der Dateizugriff verhindert werden…

Description: LOAD DATA, SELECT … INTO and LOAD FILE() will only work with files in the specified path. If not set, the default, the statements will work with any files that can be accessed.

Aber das ist nicht korrekt! Wenn ich secure_file_priv nicht setze, und es aus der laufenden Datenbank abfrage, ist der Wert leer

# mysql -e "SHOW VARIABLES LIKE 'secure_file_priv';"
+------------------+------------+
| Variable_name    | Value      |
+------------------+------------+
| secure_file_priv |            |
+------------------+------------+

… und ein SELECT load_file(’/etc/passwd’); zeigt mir den Dateiinhalt an!
Wer Percona oder einen anderen Mysql-Abkömmling verwendet, sollte das Verhalten austesten.

MariaDB erwartet einen existierenden Verzeichnisnamen. Ich habe mich entschieden, /dev/null zu nehmen, weil es sowohl existiert als auch ein User hier keine Datei ablegen kann:

(2)
Variante für MariaDB:

[mysqld]
(...)
local-infile = 0
secure_file_priv = /dev/null
(...)

(3)
Bliebe noch die Software-Verteilung… wenn in Puppet die Mysql-Klasse aufgerufen wird, muss diese von irgendwoher wissen, ob das Produkt am Zielsystem MariaDB oder Mysql ist. Die Lazy Variante wäre, auf das OS zu reagieren, weil Defaults in den Repos beispielsweise von Debian oder CentOS sich unterscheiden. Besser und sicherer ist natürlich ein echtes Flag.

weiterführende Links:

  1. Golem: Lange bekannte MySQL-Lücke führt zu Angriffen (27.1.2019)
  2. secure_file_priv - mysql - Docs (en)
  3. secure_file_priv - mariaDB - Docs (en)
Artikel weiterempfehlen: Google + Facebook

SPAM: Das ist meine letzte Warnung!

Hach wie süss, was es nicht alles für niedliche Spams gibt:
Mein anonymer Hacker mit dem Mädchennamen hat eine E-Mail-Adresse aus Gabun.

Der-die-das intensiv recherchiernde HackerIn hat mein Adressbuch und lauter private Details durch den selbstprogramierten, webcameinschaltenden Spitzentrojaner ergattert, aber nennt meinen Namen nicht in der Anrede. Das könnte einem … nun ja, ich sage es wirklich ungern, weil es so ein Humorkiller ist: es könnte einem bereits in Zeile 1 verdächtig vorkommen. Verdammt schade. Aber ich habe weitergelesen - es wurde ja tatsächlich noch lustig!

2019-01-14-bitcoin-gegen-angebliche-webcam-videos-01.png

Wie er-sie-es an meine Facebookfreundesliste kam, scheint mir ein faszinierender Trick, den ich mir unbedingt einmal vorführen lassen muss! Mein FB Account ist bereits seit Langem gelöscht.

“Sobald Sie diese E-Mail öffnen, werde ich wissen, dass Sie sie geöffnet haben.” - ach nein! Noch ein Fail! Der zieht das Ganze wieder arg in die Tiefe. Das gibt definitiv Abzug in der B-Note. Das ging vieleicht vor 10 Jahren. Mittlerweile blockt nahezu jedes E-Mail-Programm Bilder - sichtbare … als auch jenes heimlich eingebaute 1×1 Pixel Bildchen, das nachhause telefonieren will.

Und der Rest des Textes ist Unterhaltung pur: gern genossen mit einem Bier, Chips und Erdnussflips. Und einem Taschentuch, um die Tränen vor Lachen aus dem Auge zu wischen.

Anonym?

Schauen wir mal, wie anonym die Anonyme Barbara ist. Dazu muss man in seinem E-Mailprogramm den E-Mailheader anschauen (oder auch Kopfzeilen).

Die E-Mail wurde versendet … und vom E-Mailserver mx.ee.anonymer-hackers.ga angenommen. Falls jemand die Logs jenes Servers analysieren möchte - die E-Mail an mich hat in dessen Logfiles die ID 43dVh823zcz4mkv und den Zeitstempel Mon, 14 Jan 2019 10:53:44 +0000 (UTC).

Jener Mailserver hat die IP-Adresse 142.93.139.160 - und dies wiederum ist in Amsterdam beim Provider Digital Ocean.

Der Mailserver meines Providers (smtp.rzone.de) hat jene ID und den versendenden ebenfalls im E-Mail-Log drin. Der-die-das HackerIn kann somit seine eigenen Spuren verwischen, indem die eigenen Logfiles getilgt würden. Aber die Spur ist dennoch da: bei meinem Provider.

Und noch ein Funfact: Zuguterletzt taucht da eine Unsubscribe Liste auf. Das ist eher typisch für eine Mailing-Liste - also eine Software, die massenweise E-Mails versendet. Ob ich mich abmelden kann und dann kein Spam mehr erhalte? SCNR

2019-01-14-bitcoin-gegen-angebliche-webcam-videos-02.png

Artikel weiterempfehlen: Google + Facebook