Re: Apache vs PostgreSQL

Am Sonntag 23 März 2008 23:13:23 schrieb Andreas 'ads' Scherbaum:
> 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:
[...]
> > > 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?

Die DB könnte ein oder mehrere Bugs haben...
Der Web-Server könnte ein oder mehrere Bugs haben...
Der PHP-Interpreter könnte ein oder mehrere Bugs haben...
Das PHP-Skript könnte ein oder mehrere Bugs haben...
Das PHP-Lib könnte ein oder mehrere Bugs haben...

...Das ist bedeutend mehr Fläche würde ich sagen.

> Wo siehst du den Vorteil?

Ein ein einziges Programm was zur Not noch automatisch über z.B. apt-get
updatebar ist, so das ich noch nicht mal ein ssh offen lassen müsste.

> Wir sind weiterhin bei der Tatsache, das ein Bug in PG ausreicht, dein
> Konzept über den Haufen zu werfen.

Sicher. Aber die Kette ist so stark wie das schwächst Glied. Mit LAMP hat die
Kette mehr Glieder und mehr potentielle schwache Glieder. Oder?

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

Sehe ich anders. Bei mir Probiert er es bei PostgreSQL und ist drinnen oder
scheitert. Bei LAPP probiert er es zu erst mit diversen Apache Bugs, dann die
gängigen PHP-Dinosaurier-Bugs, dann kommen die PHP-Skript wie phpBB
(*grusel*) selber dran, dann noch ein paar Apache Modole durchprobieren und
gucken ob nicht noch was mit schlecht gewarteten PHP-Libs geht. Aber
vieleicht geht ja noch was mit Perl-CGI, Python, Ruby oder was man noch so
alles schönes findet auf ein Webserver...

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

Gut. Trotzdem regelst du ja (oder des PHP-Skript) irgendwie den Zugriff. Wenn
du das mit Apache selbst machst, wirst du ein bisschen mehr Energie in deine
Apache-Konfiguration stecken müssen als 5 Parameter. Tust du das nicht, macht
es eben das PHP-Skript. Und was und wie das PHP-Skript etwas mach, ist nicht
von Hause aus besser als PostgreSQL. Oder?

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

Kann ich nicht nachvollziehen. PostgreSQL benutzt (zum Teil) das selbe, aber
bei Apache ist es sicherer?

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

Ich glaube das kann man nicht losgelöst vom Anwendungsfall generell sagen.

> Nimmt man die Menge bekannter Angriffe und
> Einschränkungen gegen md5, kann man nicht mehr von einem sicheren Hash
> Verfahren ausgehen.

Muss man auch nicht, im Falle von einer MD5-Authentifizierung, weil der
Angreifer den vom Server gewünschten Hash sowieso nicht vor die Augen
bekommt. Er müsste also etwas generieren, was er nicht kennt.

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

Beim MD5-Verfahren hast du nur _einen_ Versuch. Die Wahrscheinlichkeit von
zwei Blitzen gleichzeitig getroffen zu werden, halte ich für höher.

> Bzw., man muss die Passwörter nicht
> knacken, es genügt, eine Eingabe zu finden, die die gleiche md5sum
> erzeugt (Hash Kollision).

Das ist der Punkt: Als Angreifer weist du ja nicht, was du abzuliefern hast.
Um etwas zu fälschen, müsstet du wissen, wie das Original aussieht. Das
Original verlässt aber nicht den Server und wird nur ein einziges mal
erstellt, verwendet und dann verworfen.

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

Wenn er drinnen ist interessieren ihn keine Passwörter mehr. Zum einen brauch
er sie jetzt sowieso nicht mehr und zum anderen lassen sie sich ändern. Der
erste Schritt nach einem Einbruch ist unauffällig nach Hause zu telefonieren,
Spuren zu verwischen, verwertbare Daten zu Machterweiterung zu finden. Der
Apache kennt das Passwort von PostgreSQL-Server höchstwahrscheinlich....

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

Wenn ich in einer Bank bin, kann ich ganz einfach von innen die Tür auf machen
und kann dann ganz einfach in die Bank kommen, was beweist wie einfaches ist
in eine Bank zu kommen. Das nennen ich einen sauberen Zirkelschluss oder
auch "Henne-Ei-Problem" oder Tautologie. Man müsste schon in der Bank sein,
um in die Bank zu gelangen.

Mit freundlichen Grüßen

Olaf Radicke