PHP disabled_functions

  • App
    WoltLab Suite Core

    Hallo,

    ich würde gerne meinen wbb container etwas absichern und bin darauf auf ein Problem gestoßen.

    Es gibt keinerlei Dokumentation zu dem Klassiker in Sachen PHP Hardening, den disabled_functions.

    Wenn man sich so einliest, dann sind die Kandidaten dafür:

    • ini_set
    • php_uname
    • getmyuid
    • getmypid
    • passthru
    • leak
    • listen
    • diskfreespace
    • tmpfile
    • link
    • ignore_user_abord
    • shell_exec
    • dl
    • set_time_limit
    • exec
    • system
    • highlight_file
    • source
    • show_source
    • fpaththru
    • virtual
    • posix_ctermid
    • posix_getcwd
    • posix_getegid
    • posix_geteuid
    • posix_getgid
    • posix_getgrgid
    • posix_getgrnam
    • posix_getgroups
    • posix_getlogin
    • posix_getpgid
    • posix_getpgrp
    • posix_getpid
    • posix
    • _getppid
    • posix_getpwnam
    • posix_getpwuid
    • posix_getrlimit
    • posix_getsid
    • posix_getuid
    • posix_isatty
    • posix_kill
    • posix_mkfifo
    • posix_setegid
    • posix_seteuid
    • posix_setgid
    • posix_setpgid
    • posix_setsid
    • posix_setuid
    • posix_times
    • posix_ttyname
    • posix_uname
    • proc_open
    • proc_close
    • proc_get_status
    • proc_nice
    • proc_terminate
    • popen
    • curl_exec
    • curl_multi_exec
    • parse_ini_file
    • allow_url_fopen
    • allow_url_include
    • pcntl_exec
    • chgrp
    • chmod
    • chown
    • lchgrp
    • lchown
    • putenv

    Die besonders fiesen sind in fett. Gibt es jemanden der weiß welche dieser PHP Funktionen das wbb nutzt? Für try&error sind das ein paar zu viel und die Doku schweigt sich leider zum Thema Sicherheit oder Hardening vollständig. Schade eigentlich. Da hätte man wirklich mal eine Stunde investieren können.

    Curl wird ja zum Beispiel für die ES Integration genutzt. Es steht nur nirgends wie genau. Einfach alle anzuschalten führt leider zu einem nicht mehr benutzbaren Forum. Beim Upload von Bildern werden auch diverse Funktionen auf der Liste genutzt, nehme ich an.

  • IMHO ist disabled_functions der falsche Weg.

    Ich würde eher schauen, dass Benutzerrechte passen, Programme nicht als root ausgeführt werden etc.

    disabled_functions generieren eher eine trügerische Sicherheit.

    Tendenziell auch mal den Kopf einschalten und nachdenken, ob man wirklich jedes Plugin installieren muss.

  • Danke für deine Antwort. Das hilft mir jedoch leider nicht weiter.

    Es geht beim Hardening nie um ein "entweder oder", sondern um ein "sowohl als auch". Es alleine um die Minimierung der Angriffsfläche. Weniger Funktionen, geringe Angriffsfläche. Einfaches Prinzip.

    Deswegen existiert diese Funktion auch. Sie wird übrigens auch vom PHP Entwickler-Team selbst genutzt. Hatte vor 3 Jahren das Vergnügen mit ein paar der Jungs auf dem Chaos Congress zu reden.

    Falls es dich beruhigt: Ich habe das wbb im Container jail unter nobody laufen. PHP ist ausschließlich in dem Container und mit den minimalsten Anforderungen (dom, json, hash, libxml, mbstring, pcre, pdo, pdo_mysql, zlib) und ausschließlich essenziellen Abhängigkeiten installiert. Dort ist noch nicht einmal bash drin.

    Einmal editiert, zuletzt von ckoepp (20. Dezember 2020 um 21:41)

    • Offizieller Beitrag

    Ignoriere diese überflüssige Einstellung. Du könntest alle oben genannten Funktionen abschalten und ein Angreifer könnte noch immer praktisch unbegrenzt Schabernack treiben. Ein Container mit einer minimalen Umgebung und restriktiver Firewall eliminiert so ziemlich alle möglichen Angriffsvektoren.

    Dann noch die eingesetzte Software aktuell halten und, wie oben bereits angeraten, mit Plugins sparsam umgehen, um auch dort die Angriffsfläche zu minimieren. Im Plugin-Store werden darüber hinaus alle Dateien und -versionen vor der Freischaltung manuell von einem Mitarbeiter geprüft, um insbesondere grobe Fehler bereits vorzeitig zu entdecken. Bei Drittseiten gibt es diese Qualitäts- und Sicherheitsüberprüfung nicht und ist daher mit Vorsicht zu genießen.

    • Offizieller Beitrag

    Zumindest nicht durch WoltLab. Pauschal zu behaupten, andere Anbieter würden keine derartigen Prüfungen durchführen, ist kontraproduktiv und entspricht nicht unbedingt der Wahrheit.

    Es gibt einen Unterschied zwischen diese … nicht und keine. Auf Drittseiten erfolgt keine Gegenprüfung direkt durch den Hersteller der Software, diese gibt es somit bei Drittquellen nicht.

  • Bei Drittseiten gibt es diese Qualitäts- und Sicherheitsüberprüfung nicht und ist daher mit Vorsicht zu genießen.

    Es gibt einen Unterschied zwischen diese … nicht und keine. Auf Drittseiten erfolgt keine Gegenprüfung direkt durch den Hersteller der Software, diese gibt es somit bei Drittquellen nicht.

    Na ja, wenn du auf den feinen Unterschied zwischen "diese..nicht" und "keine" hinweist, ist natürlich auch die Frage erlaubt, was mit "ist daher mit Vorsicht zu genießen" gemeint ist. Mal abgesehen von der Grammatik, lässt das eine Menge Interpretationsspielraum offen und kann auch so verstanden werden, dass man den Drittentwicklern pauschal misstrauen sollte. Ich nehme an, dass du es nicht so gemeint hast, aber die Formulierung ist unglücklich und die Reaktion von SoftCreatR -für mich- verständlich.

    Abgesehen davon finde ich die Überprüfung sinnvoll, als (bezahlten) Service für Entwickler und Kunden. Du schreibst "auf Drittseiten erfolgt keine Gegenprüfung...". Allerdings wird ein Großteil der Plugins, die Entwickler im eigenen Shop anbieten, auch im Woltlab-Shop angeboten - wenn man als Kunde ein paar Tage zuwarten kann, hat man auch beim Entwickler die Sicherheit eines Woltlab-"zertifizierten" Plugins. Einige Entwickler warten sogar das Ergebnis der Überprüfung ab, bevor sie ein Plugin im eigenen Shop anbieten.

    lg,

    Chris

  • Ignoriere diese überflüssige Einstellung. Du könntest alle oben genannten Funktionen abschalten und ein Angreifer könnte noch immer praktisch unbegrenzt Schabernack treiben. Ein Container mit einer minimalen Umgebung und restriktiver Firewall eliminiert so ziemlich alle möglichen Angriffsvektoren.

    Dann noch die eingesetzte Software aktuell halten und, wie oben bereits angeraten, mit Plugins sparsam umgehen, um auch dort die Angriffsfläche zu minimieren. Im Plugin-Store werden darüber hinaus alle Dateien und -versionen vor der Freischaltung manuell von einem Mitarbeiter geprüft, um insbesondere grobe Fehler bereits vorzeitig zu entdecken. Bei Drittseiten gibt es diese Qualitäts- und Sicherheitsüberprüfung nicht und ist daher mit Vorsicht zu genießen.

    Ich würde dir da in so ziemlich allen Punkten widersprechen. Abgesehen davon ist ein minimaler Container exakt das, was ich versuche zu erreichen.

    Darum noch einmal die Frage, welche dieser oben genannten Funktionen benutzt ihr denn?

    • Offizieller Beitrag

    Ich würde dir da in so ziemlich allen Punkten widersprechen.

    Ich bin immer offen für einen sachlichen Diskurs. Wenn du eine andere Auffassung vertrittst, dann immer her damit ;)

    Beispielsweise würde mich interessieren, inwiefern ini_set, chmod und tmpfile ein Sicherheitsproblem darstellen? Auch das Verbot der ganzen posix_- und proc_-Funktionen würde mich interessieren, denn gegen was soll hier geschützt werden und zwar nicht in der Theorie, sondern im Umfeld eines restriktiven Containers?

    Wie genau sollen ausgehende HTTPS-Verbindungen aufgebaut werden können, wenn sowohl curl_exec als auch allow_url_fopen (notwendig für fsockopen als Alternative zu cURL) abgeschaltet werden?

    Wenn du PHP nicht gerade auf der blanken Maschine als root ausführst, fallen die Möglichkeiten von PHP zum Anrichten von Unfug doch sehr überschaubar aus. PHP als Apache-Modul ist auch noch so ein Kandidat, aber wenn wir von Container reden, gehe ich mal konkret von FPM aus.

  • Warum kannst du denn nicht bitte auf meine Frage antworten? Wir können gerne sachlich debattieren - aber dann in einem anderen Thread.

    Ich möchte in diesem hier in erster Linie meine Frage beantwortet bekommen: Welche der Funktionen braucht das wbb um zu funktionieren?

    • Offizieller Beitrag

    Eine pauschale Liste der genutzten PHP-Funktionen können wir nicht zur Verfügung stellen. Das scheitert in der Praxis schon daran, dass sich die genutzten Funktionen je nach installierten Paketen unterscheiden können. Darüber hinaus nutzen wir auch einige 3rd Party Libraries, wodurch sich bei Updates schnell auch mal Veränderungen ergeben können.

    Wenn man unbedingt PHP-Funktionen abschalten möchte, wäre meine Empfehlung, mittels Dateisuche in der Installation danach zu suchen. Findet man nichts, kann man die Funktion in der Regel deaktivieren.

  • Alexander Ebert 9. Februar 2021 um 14:03

    Hat das Label Nicht geplant hinzugefügt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!