Re: Apache vs PostgreSQL

On Sun, 23 Mar 2008 21:36:48 +0100 Olaf Radicke wrote:

> 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:
>
> > 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.

Lies meinen Satz noch mal durch, verstehe ihn, dann weisst du auch, das
ich etwas anderes als SQL-Injection gemeint habe. Dies stand da nur als
billiger Aufhänger, wie ein einfacher Fehler aussehen kann.

> > 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.

Und? Wo siehst du den Vorteil?
Wir sind weiterhin bei der Tatsache, das ein Bug in PG ausreicht, dein
Konzept über den Haufen zu werfen. Bei deinem Szenario müsste ich
zuerst in das LAMP/LAPP Setup einbrechen, ehe ich die Datenbank
angreifen kann. Das erfordert zwei Fehler in Reihe - bei deinem
Vorschlag reicht ein Fehler. Was ist nun besser?

> > 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.

Wir sprechen weiterhin über pg_hba.conf. Das ist eine Datei, die vom
zuständigen Admin im Filesystem geändert werden muss. Das klappt nicht
über den Wizard in der Applikation. Und LDAP hier einzuwerfen lenkt nur
vom Thema ab.

> > 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?

Nur, wenn diese auch die betroffenen Libraries verwenden. Aber auch
dieses Beispiel widerlegt deine Behauptung nicht sondern sorgt immer
noch dafür, das man die DB nicht offen am Netz haben möchte, wenn dies
nicht zwingend notwendig ist.

> > 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?"

Der Text zeigt (unter anderem), das md5 Passwörter nicht mehr state of
the art sind. Nimmt man die Menge bekannter Angriffe und
Einschränkungen gegen md5, kann man nicht mehr von einem sicheren Hash
Verfahren ausgehen. Nimmt man die Menge bereits existierender Rainbow
Tabellen hinzu (deren Größe sich durch die bekannten Angriffe nur noch
weiter reduziert), dürften diverse Passwörter bereits in verschwindend
geringer Zeit knackbar sein. Bzw., man muss die Passwörter nicht
knacken, es genügt, eine Eingabe zu finden, die die gleiche md5sum
erzeugt (Hash Kollision).

Um auf das Problem zurückzukommen: wir waren ursprünglich bei einem
Einbruch in den Server selbst, vorbei an "SQL", ausgelöst z.B. durch
Fehler im Programmcode. Durch diesen Einbruch erlangt jemand a) Zugriff
auf alle Daten, ohne Umwege und b) Zugriff auf die verschlüsselten
Passwörter.

> > 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.

Warum? Die Datenbank muss die verschlüsselten Passwörter lesen können,
also kann dies auch jeder, der in den Unix Account der Datenbank
einbricht.

Mein Schluss:
Ich habe immer noch kein vernünftiges Argument von dir gehört, warum
eine Datenbank am Netz etwas gutes sein sollte. Aber ein paar andere,
schwergewichtige Argumente dagegen haben sich angefunden.

Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors