Re: Sicherheitsprobleme bei MySQL !!!!

[Martin Ramsch <m.ramsch_(at)_computer.org>]

Guido Stepken schrieb am Mittwoch, den  1. September 1999:
> >     Aber mache sich jeder nach eigener Lust und Laune unbeliebt.
[...]
> Herrschaften, ich bitte um Toleranz !

Unterschreib ich! :) Nur lasse ich mir selbst auch nicht die Freiheit
nehmen, eine Meinung zu haben und insbesondere freiwillige
Hilfeleistungen nur den Leuten zu geben, wie ich will.


> Mir sind ein paar haarsträubende Sicherheitsprobleme mit MySQL und SUSE
> aufgefallen .....
> 
> Hier meine Analyse .....
> http://www.little-idiot.de/firewall/zusammen-167.html#sql

Zu: 26.2 Angriff auf S.u.S.E. LINUX und MySQL
    <URL: http://www.little-idiot.de/firewall/zusammen-169.html >

Du zeigst schön, daß es möglich sein kann, mit der SQL-Anweisung
   LOAD DATA INFILE ...
auf Dateien des Rechners zuzugreifen, auf dem der MySQL-Server läuft.

Du schreibst aber nicht, daß das auch genau an der Stelle im MySQL-
Handbuch beschrieben ist, wo es hingehört - im Kapitel "7.15 LOAD DATA
INFILE syntax". :)

Du hast leider auch übersehen, daß es kein haarsträubendes
Sicherheitsproblem ist, sondern daß der entsprechende Datenbank-User
das "File"-Privileg besitzen muß, damit LOAD DATA INFILE erlaubt ist!

Somit es es höchstens ein Fehler des Datenbankverwalters, wenn er
vertrauensunwürdigen Leuten dieses Recht gibt.  (Oder ein Fehler der
S.U.S.E.-Distribution, MySQL in einer unnötig offenen Konfiguration
auszuliefern?)  Jedenfalls keine Manko, das MySQL wesenseigen ist!

Randnotiz:
  In dem Zusammenhang ist interessant, daß seit V3.22.6 auch LOAD DATA
  LOCAL INFILE existiert, das weder das File-Privileg braucht noch die
  potentiellen Sicherheitsprobleme besitzt, da man damit nicht auf
  server-seitige Dateien zugreift.


Weiters schreibst Du:
| Das Statement: 
|       insert .....  
|       select * from passwd into outfile "/etc/passwd";
|       Query OK, 32 rows affected (0.03 sec)
| spare ich mir nun, was Sie ebenfalls sich sparen sollten.

... und man sich auch wirklich sparen kann -- weil es nicht
funktioniert.  ;-)
MySQL überschreib mit SELECT .. INTO OUTFILE aus Sicherheitsgründen
niemals bestehende Dateien!


Deine Empfehlung
| Damit ein solcher Einbruch also nicht möglich ist, sollten Sie MySQL
| nur mit User-Rechten starten, und den MySQL Serverdämon in eine
| CHROOT() Umgebung verbannen.
ist natürlich gut, aber aus oben genannten Gründen eigentlich zu scharf.


Zum bemängelten, angeblich lückenhaften Logging:  Deine Aussage, daß
nur Zugriffe zur DB "mysql" mitgeloggt würden, kann ich nicht
nachvollziehen.  Bei mir wird alles notiert - und so ist das auch
normal.  Zusätzlich gäbe es sogar die Möglichkeit, den Server mit
--log-update=... zu starten, was einen noch besseren Einblick in
alle Datenveränderungen gibt.


Hattest Du im MySQL-Handbuch auch das für Deine Analyse ja sehr
wichtige Kapitel "6.14 How to make MySQL secure against crackers"
gelesen?


Kurzum:
  Dein "Analyse" ist unvollständig und deshalb irreführend, auch wenn
  die Absicht, Sicherheitslücken aufzudecken natürlich prima ist!


> Das sollte insbesondere Leute interessieren, die MySQL Server im
> Internet hinter einer Firewall betreiben ....


Hier evtl. erwähnenswert ist, daß sich MySQL sogar ohne jede TCP/IP-
Netzwerkfunktionalität betreiben läßt.  Dann können nur die Clients
auf genau diesem Rechner auf den Datenbestand zugreifen (z.B. CGI-
Skripte).


Regards,
  Martin
-- 
Martin Ramsch <m.ramsch_(at)_computer.org> <URL: http://home.pages.de/~ramsch/ >
PGP KeyID=0xE8EF4F75 FiPr=52 44 5E F3 B0 B1 38 26  E4 EC 80 58 7B 31 3A D7

---
*** Abmelden von dieser Mailingliste funktioniert per E-Mail
*** an mysql-de-request_(at)_lists.4t2.com mit Betreff/Subject: unsubscribe