Updatesicher FollowSymlinks deaktivieren

[v3ng]

Hi,

Wie kann ich systemweit und updatesicher die Option FollowSymlinks für alle Nutzer deaktivieren?


Vielen Dank!
Ian

[24unix]

da so der Nutzer trotz Jailed Umgebung zugriff auf für ihn geheime Dateien hat

Du weißt nicht wirklich, was Du tust, oder?


Was willst Du erreichen?

[v3ng]

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

[24unix]

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

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

Auf die passwd hat der Apache Zugriff (muss er ja auch), auf die shadow nicht.

b) vHosts sind nicht jailed.

c) OpenBaseDir verhindert, dass der User über symlinks auf seinem Bereich ausbrechen kann.

[v3ng]

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

[24unix]

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?

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)

In der Shell wird der symljnk auch als broken dargestellt.

[v3ng]

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

[24unix]

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

Dann stimmt was mit den Berechtigungen nicht.

Du darfst keine Berechtigungen in fremden Ordnern haben.

[v3ng]

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

[24unix]

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

Das kannst Du doch bei den Apache-Direktiven angeben, oder?

[v3ng]

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?

[ShortSnow]

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.

Code: Select all

carter@p3x-794: ln -s /home/user/tealc/www/wordpress/wp-config.php /home/user/carter/www/geheime_datei.html

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

[24unix]

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.

Code: Select all

carter@p3x-794: ln -s /home/user/tealc/www/wordpress/wp-config.php /home/user/carter/www/geheime_datei.html

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

Der Apache hat andere Rechte, und ist nicht im Jail.
Trotzdem irgendwie unschön.

[v3ng]

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

[tab-kh]

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.