Re: Apache vs PostgreSQL

Am Freitag 21 März 2008 02:11:03 schrieb Andreas 'ads' Scherbaum:
> On Fri, 21 Mar 2008 01:15:14 +0100 Olaf Radicke wrote:
> > Am Donnerstag 20 März 2008 23:34:35 schrieb Andreas 'ads' Scherbaum:
> > > On Thu, 20 Mar 2008 20:53:37 +0100 Olaf Radicke wrote:
[...]

Vielleich war der Betrefs verwirrent und hätte lauten sollen:

LAPP vs. PostgreSQL & Fat-Client

[...]

> > > Wenn dir jemand über PostgreSQL direkt in den dahinterstehenden Unix
> > > User einbricht, hat der auch Kontrolle über die gesamten Daten. Dann
> > > sind all die ACLs, Nutzer, Gruppen und Zugriffsbeschränkungen aus
> > > pg_hba.conf nur Makulatur.
> >
> > Okay. Mal abgesehen von richtigen Bugs in der DB.
>
> Nicht "mal abgesehen". Wenn ich irgendwo einbrechen will, suche ich mir
> die Bugs dort, wo sie nicht erwartet werden, wo die Breitenwirkung aber
> effektiver ist als bei einer simplen SQL-Injection.

SQL-Injection sind ein Klassisches LAMP/LAPP Problem. Da die Datenbank Hinter
dem Apache und dem Skript quasie blind ist, muss sich die DB auf Apache und
das Skript verlassen. Die DB /kann/ in diesen Fall garkeine
Plausibilitätsprüfung machen. Eine SQL-Injection ist somit kein Fehler einer
DB.

> > > Das gilt nur so lange, wie du innerhalb der Datenbank Software bleibst.
> > > Wenn es jemand schafft, daraus auszubrechen - hat er alles.
> >
> > Sicher. Aber wie realistisch ist das?
>
> Bis zum nächsten Bug. Und ja, es gibt auch Bugs, über die man direkt in
> Datenbanken einbrechen kann, ohne vorher SQL nutzen zu müssen.

Wenn ich eine PostgreSQL als Server benutze, habe ich eine potenzielle
Angriffsfläche. Wenn ich ein LAMP/LAPP benutze habe ich drei.

> > Finde ich nicht. Die Möglichkeiten sind sehr begrenzt.
> > # TYPE DATABASE USER CIDR-ADDRESS METHOD
> > Fünf Parameter. Das ist nichts im vergleich zu einer
> > Apache-Konfiguration.
>
> Und warum gibt es dann so viele Fragen rund um diese 5 Parameter?
> Warum kommen so viele User auf die Idee, da einfach mal mit "trust"
> alle Probleme zu überwinden? In einer Default Apache Config ändere ich
> ungefähr den Hostnamen und den Pfad für document_root, das sind zwei
> Parameter, nicht fünf.

Fielleicht automatisiert das deine PHP-Applikation durch ein Wizart, so das du
nicht selber Hand anlegen musst. Wenn du z.B. ein CRM hast, brauchst du eine
Zugangsverwaltung. Das kann man mit Apache ein bisschen hinbasteln, aber
meistens bringen die Skripte ihrer eigene Zugangsverwaltung mit. Viele
Programme haben dann auch noch unterschiedliche Vorstellungen darüber wie sie
das machen wollen. Einige benutzen z.B. LDAP.

War Breughel der das Bild malte mit der Reihe Blinder, die sich gegenseitig
führt? So kommt mir LAMP/LAPP ach vor:

Postgres vertraut Apache. Apache vertraut einem PHP-Skript, Das PHP-Skript
vertraut sich selbst oder einem LDAP. Der LDAP...

> > > > - Man kann erzwingen, das der Client sich nur mit ssl und md5
> > > > anmeldet und jeder weitere Kommunikation abgeschirmt ist.
> > >
> > > Es gab in der Vergangenheit Schwachstellen in diversen SSL
> > > Implementierungen
> >
> > Auch in der aktuellen 8.1 und 8.2 ?
>
> Aktuell ist PostgreSQL 8.3, der Rest sind nur Versionen, die noch einige
> Jahre Support genießen.
>
> Wie dir jedoch aufgefallen ist, ist SSL keine PostgreSQL
> Entwicklung sondern dafür wird eine darunterliegende Bibliothek
> genutzt. Die kann durchaus für 8.1, 8.2 und 8.3 die gleiche
> Versionsnummer - und ggf. die gleichen Fehler - beinhalten.
>
> Es gab auch erst Ende 2007 einen Haufen Probleme mit einer Regexp
> Library, die nicht nur von PG sondern von einer Menge Applikationen
> mehr genutzt wird. Und Schwups hat man ein Sicherheitsproblem in der
> Hälfte der Services, ohne etwas dafür zu können.

Also hätte es dann auch einem LAMP/LAPP den Arsch weg gerissen?

> > > und MD5 ist schon seit einiger Zeit nichts, was man
> > > für Sicherheit einsetzen möchte.
> >
> > So? Wenn das Passwort nicht gerade aus vier zahlen besteht, wüste ich
> > nicht, wie ich das so schnell ausheben soll. Wollen wir ein Test machen?
> > Ich gebe dir eine Phrase und die md5. Wenn du das Passwort nach 48h
> > geknackt hast, hast du gewonnen. Hier ist sie:
> > Frase: rübezahl
> > md5sum: 544489dee215eeb6ba1cda68de7ac8e9
>
> Schau, ich habe keine Lust, dir deine Sicherheitsbedenken zu bestätigen
> oder zu widerlegen. Das MD5 an sich mittlerweile nicht mehr als sicher
> gilt, ist bekannt. Ansonsten darfst du dir das hier durchlesen:
>
> http://eprint.iacr.org/2004/199.pdf
> (speziell am Ende der ersten Seite)
> http://www.mscs.dal.ca/~selinger/md5collision/

Wenn ich den Text richtig verstanden habe, war die Ausgangsfrage: "Kann ich
ein Programm korrumpieren, ohne deren md5sum zu verändern?"

Die Beantwortung dieser Frage, ist aber bedeutungslos für die Verwendung von
Authentifizierung mit md5sum. Im genannten Beispiel ist das Ergebnis bekannt.
Bei einer md5-Authentifizierung weiß der Angreifer aber nicht was erwartet
wird. Da die Phrase ständig wechselt, kann er auch nicht stur durchprobieren.

> So, und jetzt lass uns das Thema beenden. Passwörter sind nur solange
> sicher, wie sie niemand zu Gesicht bekommt. Bricht dir jemand in den
> Unix Account ein, wird er auch Zugriff auf die md5 Passwörter erhalten.

Das ist ein Zirkelschluss.

Mit Freundlichen Grüßen

Olaf