Mailinglist Archive: opensuse-de (1985 mails)

< Previous Next >
Re: register_globals
  • From: Christian Boltz <suse@xxxxxxxxx>
  • Date: Fri, 10 Feb 2006 23:49:00 +0100
  • Message-id: <200602102349.03924@xxxxxxxxxxxxxxx>
Hallo Steffen, hallo Leute,

Am Freitag, 3. Februar 2006 10:16 schrieb Steffen Dettmer:
> * Christian Boltz wrote on Thu, Feb 02, 2006 at 22:12 +0100:
[...]
> > > Na ja, falls man keinen Webmaster oder Entwickler hat ;) Sonst
> > > hat man vermutlich einen wwwadm oder so, der die Configs
> > > schreiben darf, aber ich weiss, Haarspalterei :)
> >
> > Dieser jemand braucht dann aber auch Rechte für ein rcapache reload
> > (und kann natürlich mit einer kaputten Configdatei den Apache auch
> > abschießen).
>
> Einen Entwickler, der nicht in der Lage ist, einen Apache
> abzuschiessen, auf dem er entwickelt, kann ich mir kaum vorstellen ;)
> Ob nu mit oder ohne rcapache :)

Den ganzen Apache abschießen ohne root-Rechte wird (hoffentlich ;-))
schwierig.

> > So, genug Haare gespalten.
>
> Ein hab ich noch :-) rcapache reload ginge auch via sudo. So, aber
> jetzt fertig.

Wenn Du schon mit sudo kommst:
Apache-Neustart nur per sudo erlauben und in folgendes kleine Script
packen:
rcapache2 configtest && rcapache2 reload
;-)

> > > > AllowOverride AuthConfig Indexes Limit halte ich für OK,
> > > > FileInfo ist ein Grenzfall und Options will man auf keinen Fall
> > > > freigeben.
> >
> > [...]
> >
> > > > (Gründe auf Anfrage - *gähn* ;-)
> > >
> > > ANFRAG! :) Paar Stichpunkte (PM?) wären nett - falls die
> > > Allgemein gelten (ich kann mir natürlich genügend Spezialfälle
> > > denken, wo man Options nicht erlauben möchte, klar).
> >
> > Ich bin gerade etwas wacher ;-)
> >
> > Fangen wir mit FileInfo an:
> > Allow use of the directives controlling document types
> > (DefaultType, ErrorDocument, ForceType, LanguagePriority,
> > SetHandler, SetInputFilter, SetOutputFilter, and mod_mime Add* and
> > Remove* directives, etc.).
> >
> >
> > - SetHandler: kann dazu führen, dass interne Infos über den Apache
> > (z. B. server-status) nach außen kommen. Sowas macht es im
> > Zweifelsfall einem Angreifer leichter, weil er gezielter handeln
> > kann.
>
> Und mit PHP und CGI soll das nicht nachzubauen gehen?

Doch, aber man muss es erst nachbauen ;-)
Dagegen ist das Freigeben von server-status deutlich schneller gemacht.

Nenne es von mir aus "security by laziness" (Sicherheit durch
Bequemlichkeit / Faulheit) ;-)

> > - Set*Filter will ich nicht unbedingt jedem erlauben - laut
> > Apache-Doku kann man (mit mod_ext_filter) auch externe Programme
> > als Filter einbinden - die können dann mit wwwrun(?)-Rechten alles
> > mögliche anstellen.
>
> Da reicht ein AllowOverride, um externe Programme einzubinden? Wie
> bekommt ein Angreifer sein Programm in das wwwrun-exec-Verzeichnis um
> das zu überschreiben?

Gute Frage - mangels Erfahrungen mit diesem noch recht neuen Feature
halte ich mich vornehm zurück ;-)

> CGI kann ja auch externe Programme starten
> (wenn auch bei suexec nicht unbedingt als wwwrun).

Eben - dann kann er nur seine eigenen Dateien kaputtmachen, was mich
etwas weniger stört ;-)
Ja, so Nettigkeiten wie /tmp volllaufen lassen kann er natürlich auch,
das ist dann aber zumindest über den Usernamen identifizierbar bzw. per
Quota verhinderbar.

> Na, und gerade für'n Entwickler, mmm....

Habe ich gesagt, dass ich über "Serverkonfiguration für Entwickler"
schreibe? Das wäre dann "jeder darf alles", damit man sich nicht selbst
im Weg steht ;-)) (Sowas mach ich auf meinem Laptop auch manchmal,
aber für einen Produktivserver kann und will ich das nicht empfehlen.)

> > Beispielsweise sämtliche Dateien verunstalten, die per
> > PHP-Uploadformular hochgeladen wurden - beim Einsatz eines
> > Content Management Systems sind das einige.
>
> Dann lädt man die halt nochmal hoch. Falls man wirklich so viel auf'm
> Entwicklersystem hat...

Siehe oben - ich rede nicht (nur) von Entwicklersystemen.

> > Außerdem können sie gemütlich eine Runde MySQL-Passwörter aus
> > PHP-Scripten einsammeln (Apache hat da ja Leserecht) und mit den
> > Datenbanken spielen ;-)
>
> MySQL-Passwörter kriegt man doch nicht raus? Die sind doch sicherlich
> nirgendwo im Klartext gespeichert und den Hash darf man nur
> vergleichen, nicht lesen...

Doch, die MySQL-Passwörter findet man zuhauf - guck Dir ein beliebiges
PHP-Script an, das auf MySQL zugreift und Du wirst fündig.

> > Zugegeben, mit PHP (ohne open_basedir-Beschränkung) und CGIs
> > (ohne suExec) geht das auch, aber PHP kann man ja entsprechend
> > einschränken und CGIs muss man nicht jedem erlauben ;-) - Habe ich
> > etwas vergessen? Egal, die beiden genannten reichen schon ;-)
>
> Na, weiss ja nicht, ob ich dem PHP da trauen würde... Ich mein, so
> ziemlich die wurstigste der verbreiteten Sprachen, linkt gegen
> /usr/lib/lib*a, in der Vergangenheits Bugs ohne Ende, oben
> aufgeklatschtes "Sicherheitssystem", etc. aber anderes Thema.

Ich traue PHP jedenfalls mehr als manchen CGIs, die jemand irgendwo[tm]
gefunden und für lustig befunden hat ;-)

> Ja, und eure Entwickler drüfen kein CGI? Ist schon komisch. Na ja.

Auf dem Server, den ich betreue, laufen hauptsächlich Webseiten auf
Typo3-Basis - somit wird vor allem PHP benötigt. Aus naheliegenden
Gründen sind dann auch Erweiterungen, die innerhalb dieser Seiten
erscheinen sollen, in PHP programmiert - CGIs in einem <iframe> sind
nicht wirklich schön ;-)

Falls jemand unbedingt CGIs braucht, darf er die natürlich verwenden.

> Also klar, wenn man jetzt ein Produktionssystem hätte, dann nimmt man
> natürlich am besten gar kein PHP und suExec-CGIs, klar.

*LoL*

Die beste Methode zur Absicherung des Systems ist ja bekanntlich der
Befehl "init 0" *g* - man wird also immer einen Kompromiss zwischen
Sicherheit und Funktionalität finden müssen.

> > Kommen wir zu AllowOverride Options:
> > Allow use of the directives controlling specific directory
> > features (Options and XBitHack).
> >
> > XBitHack on oder full "fördert" die Serverlast, da alle
> > HTML-Dateien geparst werden.
>
> lol, das ist ja ne schöne Beschreibung. Durch das Verwenden von PHP
> wird die Serverlast aber bestimmt noch mehr erhöht hihi

Das bestreite ich nicht ;-)

> Ich verwende viel SHTML, das ist IMHO auch richtig, kann heut bloss
> kaum noch einer, aber das Internet muss ja auch so schlecht wie alle
> Software sein, klar. Da macht man dann Menüs mit Java oder so, aber
> ist ja auch egal.

Wenn SHTML wirklich verwendet wird (also die Dateien entsprechende
Befehle beinhalten), ist das OK.

Mir ging es um die _unnötige_ Serverlast durch das Parsen aller
HTML-Dateien...

> > ExecCGI
> > Execution of CGI scripts using mod_cgi is permitted.
> >
> > CGIs will ich zentral halten und nicht quer in allen Verzeichnissen
> > verteilt - deshalb ist diese Option nicht schön.
>
> iihhh, /cgi-bin/? Find ich sowas von hässlich... Da hab ich dann
> Dienst X mit /xdata und /cgi-bin/xexec/ etc, furchtbar... Nee, ich
> möchte /vendor/package-version/ haben, und da ist alles drin.

Ist wohl Ansichtssache - ich bevorzuge jedenfalls /cgi-bin ;-)

> Manchmal tauscht man ja auch Bilder gegen JPEGs, und welcher Package
> gehört /cgi-bin/show.jpg?

Da in /cgi-bin/ nur Programme/Scripte existieren, sollte das irgendwo im
Programmcode zu erkennen sein ;-))

> > IncludesNOEXEC
> > Server-side includes are permitted, but the #exec cmd and #exec
> > cgi are disabled. [...]
> >
> > Vergleichsweise harmlos (und deutlich sicherer als Includes).
>
> ja OK, aber wie soll denn ein Entwickler entwickeln, wenn er keinen
> Code benutzen darf?

Habe ich das gesagt? Siehe CGIs - wenn er es braucht, wird er es
bekommen. Bis dahin verzichte ich lieber darauf.

> Dann kann man ihm ja gleich ein Frontpage oder so'n GUI Mist
> hinschmeissen. Dann darf man sich natürlich nicht wundern, dass die
> Webseiten genauso schlecht sind wie die, die man durchschnittlich so
> im Internet findet... Die sind dann redundant, verwenden vielleicht
> Javascript und sind Browserabhängig, obwohl man alles Serverseitig
> hätte machen können.

Welche Punkte willst Du serverseitig machen? Die Dinge, die sonst
JavaScript macht, beispielsweise Menüs bauen (sinnvoll), oder eine
Browserweiche (serverseitig keine gute Idee IMHO)?

> Meiner Meinung nach der falsche Weg (aber ich
> weiss, dass 99% der Internetnutzer anderer Meinung sind).

Ich zähle mich frecherweise zum verbleibenden Prozent ;-)

Man kann Seiten bauen, die auch ohne JavaScript funktionieren.
Das heißt nicht, dass JavaScript unnütz ist - man kann es durchaus
sinnvoll einsetzen (beliebtes Beispiel: Curser automatisch ins erste
Eingabefeld platzieren). Die Seite sollte allerdings auch ohne
JavaScript funktionieren - Menüs per JS bauen ist demzufolge dämlich.

Auch Browser-Unabhängigkeit ist machbar - man kann problemlos Seiten
erstellen, die auf allen Browsern gut aussehen. "Exakt gleich aussehen"
ist ein anderes Thema, aber "sehr ähnlich" ist ja auch OK.
BTW: Exakt gleich ist sowieso unmöglich, da man nie weiß, welche
Schriftarten der User installiert hat, ob er eine Mindestschriftgröße
eingestellt hat usw. - es sei denn, man liefert die Seite als eine
große Grafik aus.

> > FollowSymLinks
> > The server will follow symbolic links in this directory.
> >
> > Symlink zu /etc/passwd gefällig? ;-)
> > Mehr muss ich dazu wohl nicht sagen, oder?
>
> Doch: wo ist das Problem? Dass der Entwickler die Useracountnamen
> rauskriegt? Er kann dazu auch "cat" verwenden.

Vorausgesetzt, er darf überhaupt irgendwas ausführen ;-)

> Hier ist meine passwd, jedenfalls der Anfang:
[...]
> Oder hast Du das einzige Linux-System, das ich kenn, das kein shadow
> verwendet?

Nein, ich mag LDAP nicht ;-)

> > SymLinksIfOwnerMatch
> > The server will only follow symbolic links for which the target
> > file or directory is owned by the same user id as the link.
>
> Geht aber halt auch nur, wenn der Owner matcht. Wenn man ein RPM
> installiert, und die Files dadrin root gehören (z.B. damit wwwrun die
> nicht ändern darf), funktioniert das schon nicht mehr.

Klar.

> > Die sicherere Variante von FollowSymLinks - und
> > Mindestvoraussetzung für den Einsatz von mod_rewrite. Dadurch ist
> > diese Option für mich quasi lebensnotwendig ;-)
> >
> > - oder glaubt hier jemand ernsthaft, dass ich auf
> > www.Landjugend-Insheim.de für jedes Bild in der Galerie eine
> > HTML-Datei geschrieben habe? ;-) [2]#
>
> (URL geht bei mir nicht)

Der Server war kurzzeitig weg (jemand -nicht ich- hatte in Plesk an der
Netzwerkkonfiguration gespielt :-/ - ich durfte es dann wieder
zurechtflicken.)

> mod_rewrite verbraucht bestimmt Serverlast :)

CPU schon. Dafür habe ich dann weniger Festplattenzugriffe, weil alle
Einzelansichten aus derselben PHP-Datei, die dann im RAM gecacht ist,
liegt.

> In meiner Galarie hab ich für jedes Bild eine HTML-Datei. Natürlich
> nicht selbst geschrieben, sondern "make" und "wml".

Auch eine Methode ;-)

> > Fazit: Insbesondere AllowOverride Options erlaubt mehr als man
> > möchte.
>
> Mehr als /Du/ in bestimmten Fällen möchtest, ja. Ich hoffe, ich
> konnte zu jedem Punkt mindestens ein überzeugendes Gegenbeispiel
> finden :)

Konntest Du ;-)

> > PHP sollte man mit open_basedir pro vHost "einsperren" und
> > möglichst auch den safe_mode einschalten - wobei letzterer leider
> > oft zu restriktiv ist (Stichwort Dateiupload und dadurch "falscher"
> > Dateieigentümer).
>
> (oder deinstallieren, ist noch sicherer und spart Serverlast SCNR.)

Es steigert aber den Load desjenigen, der das Menü in 100 HTML-Dateien
aktualisieren muss *SCNR2*

> > Ach ja: Wer einen wirklich sicheren Webserver betreiben will,
> > erlaubt nur statische Dateien (also kein PHP, keine CGIs, kein SSI,
> > ...) und beschränkt natürlich AllowOverride passend.
>
> Oder er erlaubt CGIs und SSI und erlaubt AllowOverride halt.
>
> Wie soll denn ein Angreifer, der nur HTTP sprechen kann, das CGI
> missbrauchen, nur allein weil es da ist?

Kommt auf das CGI an - ich hatte schon etliche Zugriffsversuche auf
formmail.cgi (aber: not found ;-)

> Banken verwenden bei Online-Banking-Frontends CGI, weil statisches
> HTML für Kontostände bissel schwer ist.
>
> ( Gut, Banken sind nicht unbedingt Biespiele für "wirklich sichere
> Webserver", aber im Durchschnitt schon nicht schlecht. SCNR. )

*LoL*

Naja, zumindendest meistens -
http://www.heise.de/security/news/meldung/67698

> Ich halte das nach wie vor für situationsabhängig, gilt also alles
> nicht allgemein, sondern nur in verschiedenen, speziellen Fällen.

Stimmt - ich hätte wohl meine ganze mail in
<security mode="paranoid"> packen sollen ;-)

Erfahrungsgemäß wird aber oft zu viel erlaubt, gerade durch
AllowOverride All - deshalb wollte ich auf die möglichen Risiken
hinweisen. Dass man das ein oder andere erlauben muss, ist mir schon
klar - nur sollte man es möglichst selektiv machen.

Bist Du mit dieser Zusammenfassung als Schlusswort einverstanden?
Wenn ja, schlage ich EOT vor - die Argumente sind ja inzwischen bekannt.
Wenn nicht, darfst Du natürlich gern wieder mailen ;-)


Gruß

Christian Boltz
--
> > Danke an alle, die mir bei der Geburt geholfen haben, das Baby
> > brennt ;)
> Hat das weh getan, ein brennendes Baby zu gebären? *scnr* ;)))
Qualmt es der Mama neben dem Schenkel,
weiss der Opa, es gibt 'nen heißen Enkel!
[> Michael Raab und Thorsten von Plotho-Kettner in suse-linux]

< Previous Next >