Updatesicher FollowSymlinks deaktivieren
Updatesicher FollowSymlinks deaktivieren
Hi,
Wie kann ich systemweit und updatesicher die Option FollowSymlinks für alle Nutzer deaktivieren?
Vielen Dank!
Ian
Wie kann ich systemweit und updatesicher die Option FollowSymlinks für alle Nutzer deaktivieren?
Vielen Dank!
Ian
Last edited by v3ng on Sat 28. May 2022, 10:46, edited 1 time in total.
Re: Updatesicher FolowSymlinks deaktivieren
Du weißt nicht wirklich, was Du tust, oder?
Was willst Du erreichen?
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Updatesicher FolowSymlinks deaktivieren
Klar,
Setzt mal als Nutzer einen symlink auf beispielsweise /etc/passwd, Apache wird die reguläre System Datei ausliefern und nicht die der jailed Umgebung
Setzt mal als Nutzer einen symlink auf beispielsweise /etc/passwd, Apache wird die reguläre System Datei ausliefern und nicht die der jailed Umgebung
Re: Updatesicher FolowSymlinks deaktivieren
a) Die Berechtigungen des Systems greifen immer:
Code: Select all
% ll /etc/passwd
.rw-r--r-- root root 3 KB Sun Apr 3 17:15:14 2022 passwd
% ll /etc/shadow
.rw-r----- root shadow 2.7 KB Sat May 7 12:10:05 2022 shadow
b) vHosts sind nicht jailed.
c) OpenBaseDir verhindert, dass der User über symlinks auf seinem Bereich ausbrechen kann.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Updatesicher FolowSymlinks deaktivieren
Korrigiere mich bitte wenn ich falsch liege, Aber Symlinks zu statischen Dateien gehen ja nicht durch PHP und werden auch ausgeführt, wenn die Datei einem anderen Nutzer gehört, da Apache ja ohnehin Lesezugriff hat.
Wenn ich jetzt als Nutzer einen Symlink auf /etc/passwd setze und die Datei im Webroot liegt, liefert mir Apache eben die Systemdatei aus, mit einer Liste aller Nutzer auf dem System.
Wenn ich jetzt sehe, dass einer der Nutzer beispielsweise Wordpress betreibt kann ich doch einfach im Webroot eines anderen Users einen Symlink auf seine wp-config setzten und bekomme via Apache seine Datei ausgeliefert?
Sollte man hier nicht zumindest auf SymLinksIfOwnerMatch setzten?
Das ist zwar auch nur bedingt eine Lösung, aber verhindert zumindest die oben genannte Problematik
Wenn ich jetzt als Nutzer einen Symlink auf /etc/passwd setze und die Datei im Webroot liegt, liefert mir Apache eben die Systemdatei aus, mit einer Liste aller Nutzer auf dem System.
Wenn ich jetzt sehe, dass einer der Nutzer beispielsweise Wordpress betreibt kann ich doch einfach im Webroot eines anderen Users einen Symlink auf seine wp-config setzten und bekomme via Apache seine Datei ausgeliefert?
Sollte man hier nicht zumindest auf SymLinksIfOwnerMatch setzten?
Das ist zwar auch nur bedingt eine Lösung, aber verhindert zumindest die oben genannte Problematik
Re: Updatesicher FolowSymlinks deaktivieren
In fremden Ordnern kannst Du nicht mal lesen, geschweige denn einen Symlink setzen
Code: Select all
[0] % ll ../fazerforum/www
cannot access '../fazerforum/www': Permission denied (os error 13)
ln -s ../fazerforum/www/fazerforum.info/config.php .
[0] % cat config.php
cat: config.php: Permission denied
tracer@h2967204 : /home/users/tracer
[1] % ll config.php
cannot access 'config.php': Permission denied (os error 13)
Last edited by 24unix on Sat 28. May 2022, 12:02, edited 1 time in total.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Updatesicher FolowSymlinks deaktivieren
Ich konnte das gerade problemlos reproduzieren, ich muss ja auch garnicht in seinem Ordner lesen können, ich kann den Pfad seiner Konfigurationsdatei sehr einfach erraten und Apache folgt eben diesem Symlink und zeigt mir eine Datei an die ich nicht sehen sollte
Hier nochmal mein vorgehen:
1. Ich setze als User einen Symlink /etc/passwd -> /www/test
2. Ich rufe die Datei mittels Apache auf und finde somit alle Nutzerkonten heraus
3. Wenn bspw ein Nutzer Wordpress nutzt, weiß ich, dass seine config aller Wahrscheinlichkeit nach unter /www/wp-config.php liegt
4. Ich setzte einen Symlink auf die config des anderen Nutzers /www/users/whatever/www/wp-config.php /www/config
5. Ich rufe die Datei im Browser auf und Apache folgt dem Symlink und zeigt mir seine Datei
Hier nochmal mein vorgehen:
1. Ich setze als User einen Symlink /etc/passwd -> /www/test
2. Ich rufe die Datei mittels Apache auf und finde somit alle Nutzerkonten heraus
3. Wenn bspw ein Nutzer Wordpress nutzt, weiß ich, dass seine config aller Wahrscheinlichkeit nach unter /www/wp-config.php liegt
4. Ich setzte einen Symlink auf die config des anderen Nutzers /www/users/whatever/www/wp-config.php /www/config
5. Ich rufe die Datei im Browser auf und Apache folgt dem Symlink und zeigt mir seine Datei
Last edited by v3ng on Sat 28. May 2022, 12:05, edited 1 time in total.
Re: Updatesicher FolowSymlinks deaktivieren
Dann stimmt was mit den Berechtigungen nicht.
Du darfst keine Berechtigungen in fremden Ordnern haben.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Updatesicher FolowSymlinks deaktivieren
Ich hoffe ich stehe gerade einfach absolut auf dem Schlauch.
Aber ich benötige ja keine Berechtigungen in seinem Ordner, den Pfad errate ich und Apache hat ja Zugriff darauf und folgt dem Link auch entsprechend.
Mittels SymLinksIfOwnerMatch im vHost konnte ich die Thematik erfolgreich migrieren, aber halt nicht persistent
Aber ich benötige ja keine Berechtigungen in seinem Ordner, den Pfad errate ich und Apache hat ja Zugriff darauf und folgt dem Link auch entsprechend.
Mittels SymLinksIfOwnerMatch im vHost konnte ich die Thematik erfolgreich migrieren, aber halt nicht persistent
Re: Updatesicher FolowSymlinks deaktivieren
Das kannst Du doch bei den Apache-Direktiven angeben, oder?v3ng wrote: ↑Sat 28. May 2022, 12:16 Ich hoffe ich stehe gerade einfach absolut auf dem Schlauch.
Aber ich benötige ja keine Berechtigungen in seinem Ordner, den Pfad errate ich und Apache hat ja Zugriff darauf und folgt dem Link auch entsprechend.
Mittels SymLinksIfOwnerMatch im vHost konnte ich die Thematik erfolgreich migrieren, aber halt nicht persistent
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Updatesicher FolowSymlinks deaktivieren
Ja, ich würde mir das allerdings global wünschen, entweder pro Template definierbar oder Systemweit.
Wenn ich die Problematik jetzt richtig verstanden habe, wäre die Defaultsetting ja auch Sicherheitstechnisch sehr kritisch.
Kann das irgendjemand reproduzieren oder habe ich da tatsächlich auf dem Testsystem irgendwie Mist gebaut?
Wenn ich die Problematik jetzt richtig verstanden habe, wäre die Defaultsetting ja auch Sicherheitstechnisch sehr kritisch.
Kann das irgendjemand reproduzieren oder habe ich da tatsächlich auf dem Testsystem irgendwie Mist gebaut?
Re: Updatesicher FolowSymlinks deaktivieren
Hi,
ich hab das gerade ebenfalls getestet. Tatsächlich lassen sich als SSH User in einer "Eingeschränkten SSH-Umgebung" Symlinks auf eine Datei anderer Benutzer setzen, wenn man den Pfad kennt.
z.B.
und dann mit https://<domain>.<tld>/geheime_datei.html aufrufen.
Der link wird zwar als defekt angezeigt und als SSH User kann das auch nicht per "nano geheime_datei.html" öffnen, aber der Webserver kann es dann tatächlich und die Datenbankdaten liegen vor.
Hätte ich ohne Jail genauso erwartet und es stehen ja auch genug Warnungen im Keyhelp dran, allerdings mit aktivem Jail nicht. Aber vielleicht überseh ich auch was
Gruß Arne
ich hab das gerade ebenfalls getestet. Tatsächlich lassen sich als SSH User in einer "Eingeschränkten SSH-Umgebung" Symlinks auf eine Datei anderer Benutzer setzen, wenn man den Pfad kennt.
z.B.
Code: Select all
carter@p3x-794: ln -s /home/user/tealc/www/wordpress/wp-config.php /home/user/carter/www/geheime_datei.html
Der link wird zwar als defekt angezeigt und als SSH User kann das auch nicht per "nano geheime_datei.html" öffnen, aber der Webserver kann es dann tatächlich und die Datenbankdaten liegen vor.
Hätte ich ohne Jail genauso erwartet und es stehen ja auch genug Warnungen im Keyhelp dran, allerdings mit aktivem Jail nicht. Aber vielleicht überseh ich auch was
Gruß Arne
Re: Updatesicher FolowSymlinks deaktivieren
Der Apache hat andere Rechte, und ist nicht im Jail.ShortSnow wrote: ↑Sat 28. May 2022, 13:42 Hi,
ich hab das gerade ebenfalls getestet. Tatsächlich lassen sich als SSH User in einer "Eingeschränkten SSH-Umgebung" Symlinks auf eine Datei anderer Benutzer setzen, wenn man den Pfad kennt.
z.B.und dann mit https://<domain>.<tld>/geheime_datei.html aufrufen.Code: Select all
carter@p3x-794: ln -s /home/user/tealc/www/wordpress/wp-config.php /home/user/carter/www/geheime_datei.html
Der link wird zwar als defekt angezeigt und als SSH User kann das auch nicht per "nano geheime_datei.html" öffnen, aber der Webserver kann es dann tatächlich und die Datenbankdaten liegen vor.
Hätte ich ohne Jail genauso erwartet und es stehen ja auch genug Warnungen im Keyhelp dran, allerdings mit aktivem Jail nicht. Aber vielleicht überseh ich auch was
Gruß Arne
Trotzdem irgendwie unschön.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Updatesicher FolowSymlinks deaktivieren
Ich konnte das jetzt auf zwei Systemen mit einer wp-config.php nachstellen und demnach die Datenbank Daten auslesen.
Noch kritischer wird das Ganze wenn der opcache nicht konfiguriert ist die Berechtigungen zu prüfen, was in der default config der Fall ist.
Dann kann ich mir die Pfade der gecacheten scripte meiner Nachbarn ganz einfach rausfinden und symlinks anlegen
Noch kritischer wird das Ganze wenn der opcache nicht konfiguriert ist die Berechtigungen zu prüfen, was in der default config der Fall ist.
Dann kann ich mir die Pfade der gecacheten scripte meiner Nachbarn ganz einfach rausfinden und symlinks anlegen
Re: Updatesicher FolowSymlinks deaktivieren
Das Problem mit den Symlinks ist unabhängig von Keyhelp schon seit langem bekannt. SymLinksIfOwnerMatch hilft, bringt aber auch keine absolute Sicherheit (sofern es so etwas überhaupt gibt). Es gibt da eine Race Condition, die sich mit entsprechender Software ausnutzen liesse. Abhilfe schafft hier ein Patch des Linux Kernels. Ich weiss nicht, ob mittlerweile die Sicherheitsprobleme mit Symlinks im Apache gefixt sind, oder ob es immer noch diesen Patch braucht.
Unter anderem wegen solchen Problemen bin ich mittlerweile davon abgekommen, mehrere Kunden auf einem Server zu hosten, also praktisch shared hosting zu betreiben. Was der einzelne Kunde dann auf seinem Server treibt, mit welchen Usern und welchen Zugriffsrechten, das ist dann sein Bier und seine Verantwortung. Ich weise auf die Problematik hin, der Kunde entscheidet was er macht. Ebenso mit open_basedir. Einerseits bringt es eine gewisse Erhöhung der Sicherheit bei PHP-basierten Programmen, auf die man sich aber nicht verlassen sollte. Für andere Software bringt es natürlich sowieso Null. Andererseits bringt es eine erhebliche Performanceminderung, weil dadurch der Realpath Cache deaktiviert wird und auch bei jedem Dateizugriff die Berechtigung aufwändig zusätzlich geprüft werden muss. Auf Servern, die nur ich nutze, richte ich dann eben nötigenfalls zwei Nutzer ein. Den einen ohne open_basedir und einen zusätzlichen Nutzer mit aktiviertem open_basedir, falls ich doch mal ein Wordpress oder ähnliches installieren will, wo mir das Vertrauen in die Sicherheit fehlt, vor allem bei Plugins. Wordpress-Installationen müssen dann eben mit open_basedir und seinen Konsequenzen bezüglich Performance leben.
Unter anderem wegen solchen Problemen bin ich mittlerweile davon abgekommen, mehrere Kunden auf einem Server zu hosten, also praktisch shared hosting zu betreiben. Was der einzelne Kunde dann auf seinem Server treibt, mit welchen Usern und welchen Zugriffsrechten, das ist dann sein Bier und seine Verantwortung. Ich weise auf die Problematik hin, der Kunde entscheidet was er macht. Ebenso mit open_basedir. Einerseits bringt es eine gewisse Erhöhung der Sicherheit bei PHP-basierten Programmen, auf die man sich aber nicht verlassen sollte. Für andere Software bringt es natürlich sowieso Null. Andererseits bringt es eine erhebliche Performanceminderung, weil dadurch der Realpath Cache deaktiviert wird und auch bei jedem Dateizugriff die Berechtigung aufwändig zusätzlich geprüft werden muss. Auf Servern, die nur ich nutze, richte ich dann eben nötigenfalls zwei Nutzer ein. Den einen ohne open_basedir und einen zusätzlichen Nutzer mit aktiviertem open_basedir, falls ich doch mal ein Wordpress oder ähnliches installieren will, wo mir das Vertrauen in die Sicherheit fehlt, vor allem bei Plugins. Wordpress-Installationen müssen dann eben mit open_basedir und seinen Konsequenzen bezüglich Performance leben.