Groups > de.comm.software.webserver > #1422 > unrolled thread

Scriptsammlung isolierter Vhost

Started by	Tim Ritberg <tim@server.invalid>
First post	2022-06-14 11:17 +0200
Last post	2022-06-22 09:24 +0200
Articles	20 on this page of 53 — 6 participants

Back to article view | Back to de.comm.software.webserver

  Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-14 11:17 +0200
    Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-14 14:07 +0200
      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-14 15:26 +0200
        Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-14 16:57 +0200
          Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-14 19:25 +0200
            Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-15 11:18 +0200
              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-15 12:21 +0200
                Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-15 16:58 +0200
                  Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-15 19:05 +0200
                    Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-15 19:43 +0200
                      Re: Scriptsammlung isolierter Vhost Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-06-15 18:54 +0000
                        Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-15 22:39 +0200
                          Re: Scriptsammlung isolierter Vhost Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-06-16 13:25 +0000
                        Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-15 23:24 +0000
                      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-15 21:01 +0200
                        Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-15 22:28 +0200
                          Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-15 23:08 +0200
                            Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-15 21:32 +0000
                              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-16 00:35 +0200
                                Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-15 23:21 +0000
                                  Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-16 10:50 +0200
                                    Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-16 18:04 +0000
                                      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-17 11:01 +0200
                                        Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-17 09:50 +0000
                            Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-16 23:51 +0200
                              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-17 09:33 +0200
                            Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 02:46 +0200
                              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 09:45 +0200
                        Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 02:43 +0200
                      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-16 20:02 +0200
                        Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-16 23:40 +0200
                Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 02:40 +0200
            Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 02:39 +0200
              Re: Scriptsammlung isolierter Vhost Thomas Hochstein <thh@thh.name> - 2022-06-21 07:46 +0200
                Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 19:42 +0200
                  Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-21 20:01 +0000
                    Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-22 02:25 +0200
                  Re: Scriptsammlung isolierter Vhost Thomas Hochstein <thh@thh.name> - 2022-07-02 14:19 +0200
                    Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-07-02 14:55 +0200
              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 09:49 +0200
                Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 19:49 +0200
                  Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 21:18 +0200
                    Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 21:25 +0200
      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-18 14:49 +0200
      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-18 14:52 +0200
        Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 02:53 +0200
          Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 10:10 +0200
            Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 19:49 +0200
              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 21:05 +0200
                Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 21:19 +0200
                  Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 21:55 +0200
                    Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-22 02:25 +0200
                      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-22 09:24 +0200

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#1441

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-16 10:50 +0200
Message-ID	<t8eqtj$6gll$1@tota-refugium.de>
In reply to	#1439

Am 16.06.22 um 01:21 schrieb Laurenz Trossel:
> Praktisch jeder user-change erfordert einen Weg über Code, der mit
> root-Rechten agiert. Du erwartest etwas von Apache, für das es nicht
> ausgelegt ist.
Ich hatte da Dovecot im Kopf, der macht das so. Vielleicht kommt das ja 
mit Apache 2.6.

> 
> Du kannst jedem vhost einen eigenen httpd-Prozess geben. Das hilft im Falle
> eines Bugs auch nur begrenzt, wenn alle im selben System laufen. Wer Code
> ausführen kann, kann auch uid 0 erreichen.
Wie geht das denn?

Und so oder so kann ein Prozess bei Fehlern root werden.

> Warum willst du lieber mit exotischem Snakeoil hantieren anstatt zu
> containern?
Wieso willst du exotische Container und nicht ein bewährtes Unix-Konzept?

Tim

[toc] | [prev] | [next] | [standalone]

#1444

From	Laurenz Trossel <me@example.invalid>
Date	2022-06-16 18:04 +0000
Message-ID	<t8frar$1rtm$1@gioia.aioe.org>
In reply to	#1441

On 2022-06-16, Tim Ritberg <tim@server.invalid> wrote:
> Am 16.06.22 um 01:21 schrieb Laurenz Trossel:
>> Praktisch jeder user-change erfordert einen Weg über Code, der mit
>> root-Rechten agiert. Du erwartest etwas von Apache, für das es nicht
>> ausgelegt ist.
> Ich hatte da Dovecot im Kopf, der macht das so.

Nur in bestimmten Konfigurationen. Die Dovecot-Installationen in meinem 
Umfeld haben keine Unix-User für die Mailboxen. Dovecot verwaltet die User 
intern, der Prozess selber läuft unter der dovecot uid.

> Vielleicht kommt das ja mit Apache 2.6.

Ich sehe davon noch nichts.
https://httpd.apache.org/docs/trunk/en/new_features_2_6.html

>> Du kannst jedem vhost einen eigenen httpd-Prozess geben. Das hilft im Falle
>> eines Bugs auch nur begrenzt, wenn alle im selben System laufen. Wer Code
>> ausführen kann, kann auch uid 0 erreichen.
> Wie geht das denn?

Local Root Lücken gibt es in jedem System. Das hält einen kompetenten 
Angreifer nicht lange auf.

> Und so oder so kann ein Prozess bei Fehlern root werden.

Darum ist es besser, die Prozesse voneinander zu isolieren und in eigenen 
Namespaces zu kapseln.

>> Warum willst du lieber mit exotischem Snakeoil hantieren anstatt zu
>> containern?
> Wieso willst du exotische Container und nicht ein bewährtes Unix-Konzept?

Das Fehlen dieses Unix-Konzepts im konkreten Anwendungsfall ist genau der 
Punkt deines OP. Offenbar braucht das bisher kaum jemand. 

Multi-Tenant-vhosts laufen entweder im gleichen System und das Risiko 
übergreifender Leserechte wird akzeptiert. Oder sie werden getrennt. Früher 
mit eigenem Eisen pro Kunde/vhost (SunBros ausgenommen), heute mit 
Container.

Container sind zudem nicht exotisch sondern abgehangener Bestandteil des 
Linux-Kernels.

man 7 namespaces

[toc] | [prev] | [next] | [standalone]

#1448

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-17 11:01 +0200
Message-ID	<t8hfsi$7qge$1@tota-refugium.de>
In reply to	#1444

Am 16.06.22 um 20:04 schrieb Laurenz Trossel:

>>> Du kannst jedem vhost einen eigenen httpd-Prozess geben. Das hilft im Falle
>>> eines Bugs auch nur begrenzt, wenn alle im selben System laufen. Wer Code
>>> ausführen kann, kann auch uid 0 erreichen.
>> Wie geht das denn?
> 
> Local Root Lücken gibt es in jedem System. Das hält einen kompetenten
> Angreifer nicht lange auf.
> 

Ich meinte den Teil mit "eigener Prozess".

Tim

[toc] | [prev] | [next] | [standalone]

#1449

From	Laurenz Trossel <me@example.invalid>
Date	2022-06-17 09:50 +0000
Message-ID	<t8hio8$eki$1@gioia.aioe.org>
In reply to	#1448

On 2022-06-17, Tim Ritberg <tim@server.invalid> wrote:

>>>> Du kannst jedem vhost einen eigenen httpd-Prozess geben.
>> Wie geht das denn?
> Ich meinte den Teil mit "eigener Prozess".

Achso. systemd Units, natürlich.
Für jeden vhost startest du einen httpd mit seiner Config und einem Unix-Socket.

Ein Proxy verteilt dann die vhosts auf die Sockets.

[toc] | [prev] | [next] | [standalone]

#1446

From	Karl Pflästerer <k@rl.pflaesterer.de>
Date	2022-06-16 23:51 +0200
Message-ID	<m1edzo8eff.fsf@mbp.pflaesterer.de>
In reply to	#1436

Tim Ritberg <tim@server.invalid> writes:

> Am 15.06.22 um 22:28 schrieb Karl Pflästerer:
>>> Man nennt es "bug".
>>>
>>> https://www.zdnet.com/article/apache-web-server-bug-grants-root-access-on-shared-hosting-environments/
>> Ja und? Du verwendest lieber eine alte nicht mehr gewartete Apache
>> Extension (letzte Version 2016) als Apache mit aktuell betreuten
>> Modulen, bei denen man eher davon ausgehen kann, das Bugs gefunden und
>> behoben werden? Verstehe ich nicht.
> Ich merks. Scheint heut nicht dein Tag zu sein.

?? Was soll das? Ich frage nach deiner Motivation ein altes nicht mehr
betreutes Stück Software einsetzen zu wollen. Dies ist ein reales
security Problem.

>> Geteilte VHosts würde ich immer nur bei VHosts machen, die unter einer
>> gemeinsamen Kontrolle stehen. Bei "feindlichen" Auftritten muss die
>> Trennung strikter sein (mit zB Docker Container kein so großer
>> Overhead). Mit chroot kann auch weit kommen, wenn man Prozesse trenne
>> will.
> Feindlich hin oder her, Security per Design, alles mit www-data laufen zu
> lassen ist dumm.
> Der Ansatz von ITK ist gar nicht schlecht. Ob das Releasedatum eine Rolle
> spielt, weiss ich nicht. Jedenfalls hat Debian einen Maintainer dafür.

Eine Software, an der seit 6 Jahren nicht mehr gearbeitet wurde ist
entweder perfekt (TeX eventuell) oder tot.

[toc] | [prev] | [next] | [standalone]

#1447

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-17 09:33 +0200
Message-ID	<t8hang$7n7p$1@tota-refugium.de>
In reply to	#1446

Am 16.06.22 um 23:51 schrieb Karl Pflästerer:
> 
> ?? Was soll das? Ich frage nach deiner Motivation ein altes nicht mehr
> betreutes Stück Software einsetzen zu wollen. Dies ist ein reales
> security Problem.
Das war eine Analogie!

> 
>>> Geteilte VHosts würde ich immer nur bei VHosts machen, die unter einer
>>> gemeinsamen Kontrolle stehen. Bei "feindlichen" Auftritten muss die
>>> Trennung strikter sein (mit zB Docker Container kein so großer
>>> Overhead). Mit chroot kann auch weit kommen, wenn man Prozesse trenne
>>> will.
>> Feindlich hin oder her, Security per Design, alles mit www-data laufen zu
>> lassen ist dumm.
>> Der Ansatz von ITK ist gar nicht schlecht. Ob das Releasedatum eine Rolle
>> spielt, weiss ich nicht. Jedenfalls hat Debian einen Maintainer dafür.
> 
> Eine Software, an der seit 6 Jahren nicht mehr gearbeitet wurde ist
> entweder perfekt (TeX eventuell) oder tot.
Dann ist sie perfekt. Oder meinst du, der Debian Maintainer irrt sich? ;-)

Tim

[toc] | [prev] | [next] | [standalone]

#1456

From	Arno Welzel <usenet@arnowelzel.de>
Date	2022-06-21 02:46 +0200
Message-ID	<jhcimjFc14vU4@mid.individual.net>
In reply to	#1436

Tim Ritberg:

> Am 15.06.22 um 22:28 schrieb Karl Pflästerer:
[...]
>> Geteilte VHosts würde ich immer nur bei VHosts machen, die unter einer
>> gemeinsamen Kontrolle stehen. Bei "feindlichen" Auftritten muss die
>> Trennung strikter sein (mit zB Docker Container kein so großer
>> Overhead). Mit chroot kann auch weit kommen, wenn man Prozesse trenne
>> will.
> Feindlich hin oder her, Security per Design, alles mit www-data laufen 
> zu lassen ist dumm.

Nein, es ist der Normalfall.

> Der Ansatz von ITK ist gar nicht schlecht. Ob das Releasedatum eine 
> Rolle spielt, weiss ich nicht. Jedenfalls hat Debian einen Maintainer dafür.

Und der Maintainer von Debian kümmert sich auch darum, dass das Ding
auch irgendwann mit 400-500 Zugriffen pro Sekunde läuft statt nur 40-70?
So eine Anforderung ist nämlich hier deutlich wichtiger, als die
Vermeidung theoretischer Lücken.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#1459

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-21 09:45 +0200
Message-ID	<t8rsvk$ebp8$1@tota-refugium.de>
In reply to	#1456

Am 21.06.22 um 02:46 schrieb Arno Welzel:

> Und der Maintainer von Debian kümmert sich auch darum, dass das Ding
> auch irgendwann mit 400-500 Zugriffen pro Sekunde läuft statt nur 40-70?
> So eine Anforderung ist nämlich hier deutlich wichtiger, als die
> Vermeidung theoretischer Lücken.
> 

Für mich in den Fall nicht.

Tim

[toc] | [prev] | [next] | [standalone]

#1455

From	Arno Welzel <usenet@arnowelzel.de>
Date	2022-06-21 02:43 +0200
Message-ID	<jhcihiFc14vU3@mid.individual.net>
In reply to	#1433

Tim Ritberg:

[...]
> Man nennt es "bug".
> 
> https://www.zdnet.com/article/apache-web-server-bug-grants-root-access-on-shared-hosting-environments/

Und wie hätte da MPM-ITK geholfen?

Zitat:

"According to the Apache team, less-privileged Apache child processes
(such as CGI scripts) can execute malicious code with the privileges of
the parent process."

Der Parent-Prozess ist halt Apache selbst - egal, ob das CGI-Script mit
ITK auf irgendeinen Account eingeschränkt wird oder als www-data läuft.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#1443

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-16 20:02 +0200
Message-ID	<t8fr6o$769c$1@tota-refugium.de>
In reply to	#1431

Am 15.06.22 um 19:43 schrieb Karl Pflästerer:
>... 
> 
> Das erstellt VHost dateien für Entwickler. Die Namen sind aus
> Verzeichnisnamen ermittelbar. Je Name werden Platzhalter im Tempalte
> ersetzt. Wenn du mehr Platzhalter benötigst einfach noch ein paar s///,
> Zeilen rein. Platzhalter ist {name} und {NAME} um den gleichen wert
> definiert groß- oder kleingeschrieben auszugeben. Das gleiche gibt es
> auch als Python Variante.
> 
Warum so kompliziert. Da nimmt man vhost_alias.


Tim

[toc] | [prev] | [next] | [standalone]

#1445

From	Karl Pflästerer <k@rl.pflaesterer.de>
Date	2022-06-16 23:40 +0200
Message-ID	<m1ilp08eyp.fsf@mbp.pflaesterer.de>
In reply to	#1443

Tim Ritberg <tim@server.invalid> writes:

> Am 15.06.22 um 19:43 schrieb Karl Pflästerer:
>> ... 
>> Das erstellt VHost dateien für Entwickler. Die Namen sind aus
>> Verzeichnisnamen ermittelbar. Je Name werden Platzhalter im Tempalte
>> ersetzt. Wenn du mehr Platzhalter benötigst einfach noch ein paar s///,
>> Zeilen rein. Platzhalter ist {name} und {NAME} um den gleichen wert
>> definiert groß- oder kleingeschrieben auszugeben. Das gleiche gibt es
>> auch als Python Variante.
>> 
> Warum so kompliziert. Da nimmt man vhost_alias.

Du kennst die genaue Anwendung hier? Nein. Dann gehe einfach mal davon
aus, dass dies für den Anwendungsfall die beste Lösung ist. Es gint
mehrere templates die beim Deployment automatisch expandiert werden. Du
kannst gerne zeigen, wie man mit mod_vhost_alias das Äquivalauent zu

    ProxyFCGISetEnvIf "true" PHP_VALUE "error_log=/path/to/error/log/{NAME}/and/some/more/{substitions}/phperrors"
schreibt. Und es gibt noch mehr nutzerspezifische Settings (env Variablen zB)

[toc] | [prev] | [next] | [standalone]

#1454

From	Arno Welzel <usenet@arnowelzel.de>
Date	2022-06-21 02:40 +0200
Message-ID	<jhcichFc14vU2@mid.individual.net>
In reply to	#1428

Tim Ritberg:

> Am 15.06.22 um 11:18 schrieb Karl Pflästerer:
[...]
>> Also an welche Art von Angriff denkst du?
> Durchhangeln auf andere Vhost. www-data kann ja an alle Installationen.

Ja und? Alle anderen VHosts sind ja ohnehin aufrufbar. Dafür braucht man
keine Lücke mit www-data.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#1453

From	Arno Welzel <usenet@arnowelzel.de>
Date	2022-06-21 02:39 +0200
Message-ID	<jhciadFc14vU1@mid.individual.net>
In reply to	#1426

Tim Ritberg:

> 
> Am 14.06.22 um 16:57 schrieb Arno Welzel:
>>> Ja nee, ja doch!
>>> Also wie sollen sonst jpg und css ausgeliefert werden?
>>
>> Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.
> Nicht gut. Würde bedeuten, www-data kann bei einem Angriff auf alle 
> Vhosts zugreifen kann.

Kannst Du ein konkretes Angriffsszenario beschreiben, wo das relevant wäre?

Fall 1:

Irgendein PHP-Script hat eine Sicherheitslücke - nicht relevant, da
PHP-FPM selbst nicht als www-data läuft und PHP auch nicht als Modul in
Apache verwendet wird.

Fall 2:

Apache hat einen Bug, der dazu führt, dass man über eine bestimmte URL
aus dem DocumentRoot des virtuellen Hosts ausbrechen kann und die Daten
anderer virtueller Hosts über die Domain zu lesen.

Ja - das wäre theoretisch denkbar. Aber da www-data ohnehin auf Websites
zugreifen darf - was genau würde man damit gewinnen, statt einfach über
die vorgesehene Domain zuzugreifen?


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#1458

From	Thomas Hochstein <thh@thh.name>
Date	2022-06-21 07:46 +0200
Message-ID	<dcsw.20220621074646.1016@scatha.ancalagon.de>
In reply to	#1453

Arno Welzel schrieb:

> Aber da www-data ohnehin auf Websites
> zugreifen darf - was genau würde man damit gewinnen, statt einfach über
> die vorgesehene Domain zuzugreifen?

Sehr viele Webseiten enthalten Dateien, die nicht von außen abrufbar sein
sollen oder dürfen. Zum einen können das interne/geschützte Bereiche sein,
zum anderen sind bei Webapplikationen oder CMS regelmäßig Passworte (bspw.
für die dahinterstehende Datenbank) im Quellcode enthalten.

[toc] | [prev] | [next] | [standalone]

#1462

From	Arno Welzel <usenet@arnowelzel.de>
Date	2022-06-21 19:42 +0200
Message-ID	<jhee83FldifU1@mid.individual.net>
In reply to	#1458

Thomas Hochstein:

> Arno Welzel schrieb:
> 
>> Aber da www-data ohnehin auf Websites
>> zugreifen darf - was genau würde man damit gewinnen, statt einfach über
>> die vorgesehene Domain zuzugreifen?
> 
> Sehr viele Webseiten enthalten Dateien, die nicht von außen abrufbar sein
> sollen oder dürfen. Zum einen können das interne/geschützte Bereiche sein,
> zum anderen sind bei Webapplikationen oder CMS regelmäßig Passworte (bspw.
> für die dahinterstehende Datenbank) im Quellcode enthalten.

Nein, nicht im Quellcode, sondern in einer Konfigurationdatei, an die
man von außen per HTTP(S) nicht herankommt. Und "geschützte Bereiche"
werden üblicherweise vom Webserver geschützt.

Ich sehe immer noch kein Szenario, bei dem ein Angreifer bei korrekter
Konfiguration des Webservers an diese Daten herankommen sollte, nur weil
die Dateien für den Webserver via www-data lesbar sind.

Beispiel:

<https://wordpress-demo.arnowelzel.de>

Da gibt es natürlich eine Konfigurationsdatei, die für PHP lesbar im
Webspace liegt. Der Name und Pfad dieser Datei ist bei allen
WordPress-Installationen identisch, da WordPress sie ja lesen können
muss, um die Datenbankverbindung etc. zu kennen. Bitte zeige, wie man an
als Angreifer diese Datei herankommt, weil sie für www-data lesbar ist.

Ach ja - PHP hat nur Zugriff auf die Daten des jeweiligen virtuellen
Hosts und CGI-Scripte oder SSI sind nicht möglich.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#1470

From	Laurenz Trossel <me@example.invalid>
Date	2022-06-21 20:01 +0000
Message-ID	<t8t82m$4la$1@gioia.aioe.org>
In reply to	#1462

On 2022-06-21, Arno Welzel <usenet@arnowelzel.de> wrote:

> Ich sehe immer noch kein Szenario, bei dem ein Angreifer bei korrekter
> Konfiguration des Webservers an diese Daten herankommen sollte, nur weil
> die Dateien für den Webserver via www-data lesbar sind.

Der Kontext war die Ausnutzung eines Bugs u.a. im (PHP-)Code. Dann kann man 
auch die Dateien lesen, die der Webserver normalerweise nicht ausliefert 
oder Code nachladen und sich interaktiv umsehen.

Tim scheint besorgt zu sein, daß ein Angreifer zusäzlich auch Dateien aus 
anderen vhosts sehen könnte.

Da es in meiner Betrachtung keinen nennenswerten Unterschied zwischen "Code 
als www-user42 ausführen" und "Uid 0 erlangen" gibt, sehe ich keine bessere 
Methode als die Mountspaces zu trennen. Die vhosts im selben System mit 
verschiedenen uids zu betreiben, ist eine Sicherheitsillusion. YMMV.

> Ach ja - PHP hat nur Zugriff auf die Daten des jeweiligen virtuellen
> Hosts

Wie trennst du die vhosts? Ausbruchsicheres chroot?

[toc] | [prev] | [next] | [standalone]

#1471

From	Arno Welzel <usenet@arnowelzel.de>
Date	2022-06-22 02:25 +0200
Message-ID	<jhf5r6Fp1ojU1@mid.individual.net>
In reply to	#1470

Laurenz Trossel:

> On 2022-06-21, Arno Welzel <usenet@arnowelzel.de> wrote:
> 
>> Ich sehe immer noch kein Szenario, bei dem ein Angreifer bei korrekter
>> Konfiguration des Webservers an diese Daten herankommen sollte, nur weil
>> die Dateien für den Webserver via www-data lesbar sind.
> 
> Der Kontext war die Ausnutzung eines Bugs u.a. im (PHP-)Code. Dann kann man 
> auch die Dateien lesen, die der Webserver normalerweise nicht ausliefert 
> oder Code nachladen und sich interaktiv umsehen.

PHP läuft aber nicht mit www-data, sondern einem eigenen User.

> Tim scheint besorgt zu sein, daß ein Angreifer zusäzlich auch Dateien aus 
> anderen vhosts sehen könnte.

Ja, der der andere geschilderte Bug in Apache mit ausnutzbarer Path
Traversal kann u.U. noch viel mehr Schaden anrichten, als lediglich
Zugriff auf die Daten anderer virtueller Hosts. Wenn so beliebiger Code
ausführbar ist, spielt es letztlich keien Rolle mehr, ob nun der
virtuelle Host mit www-data läuft oder nicht.

> Da es in meiner Betrachtung keinen nennenswerten Unterschied zwischen "Code 
> als www-user42 ausführen" und "Uid 0 erlangen" gibt, sehe ich keine bessere 
> Methode als die Mountspaces zu trennen. Die vhosts im selben System mit 
> verschiedenen uids zu betreiben, ist eine Sicherheitsillusion. YMMV.

Ja, sehe ich ebenso.

>> Ach ja - PHP hat nur Zugriff auf die Daten des jeweiligen virtuellen
>> Hosts
> 
> Wie trennst du die vhosts? Ausbruchsicheres chroot?

Jeder PHP-FPM läuft mit eigenem User, der nur auf sein Webroot zugreifen
darf und sonst nichts im System machen darf. Mit einem PHP-Script allein
ist es nicht möglich, da rauszukommen.

Nein, gegen beliebige Bugs, der im System auftreten könnten, hilft auch
das nicht. Genauso wie chroot nicht absolut sicher ist und Container
ebenso wenig. Überall können Fehler drin sein. Man muss am Ende immer
abwägen, wie wahrscheinlich es ist, dass solche Fehler existieren. Am
Ende wird man jedem Benutzer seine komplette eigene VM geben, wenn man
ganz sicher sein will - und auch die ist nicht absolut "ausbruchssicher".

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#1474

From	Thomas Hochstein <thh@thh.name>
Date	2022-07-02 14:19 +0200
Message-ID	<dcsw.20220702141910.1038@scatha.ancalagon.de>
In reply to	#1462

Arno Welzel schrieb:

> Thomas Hochstein:
> > Sehr viele Webseiten enthalten Dateien, die nicht von außen abrufbar sein
> > sollen oder dürfen. Zum einen können das interne/geschützte Bereiche sein,
> > zum anderen sind bei Webapplikationen oder CMS regelmäßig Passworte (bspw.
> > für die dahinterstehende Datenbank) im Quellcode enthalten.
> 
> Nein, nicht im Quellcode, sondern in einer Konfigurationdatei, an die
> man von außen per HTTP(S) nicht herankommt. Und "geschützte Bereiche"
> werden üblicherweise vom Webserver geschützt.

Wieso "nein"? Du wiederholst doch mit anderen Worten, was ich schrieb.

> Ich sehe immer noch kein Szenario, bei dem ein Angreifer bei korrekter
> Konfiguration des Webservers an diese Daten herankommen sollte, nur weil
> die Dateien für den Webserver via www-data lesbar sind.

Bei korrekter Konfiguration und Fehlerfreiheit des Webservers, PHP und der
darin geschriebenen Anwendungen hat man sehr viele Probleme nicht, ja.

[toc] | [prev] | [next] | [standalone]

#1475

From	Arno Welzel <usenet@arnowelzel.de>
Date	2022-07-02 14:55 +0200
Message-ID	<jiathlF7lr7U1@mid.individual.net>
In reply to	#1474

Thomas Hochstein:

> Arno Welzel schrieb:
> 
>> Thomas Hochstein:
>>> Sehr viele Webseiten enthalten Dateien, die nicht von außen abrufbar sein
>>> sollen oder dürfen. Zum einen können das interne/geschützte Bereiche sein,
>>> zum anderen sind bei Webapplikationen oder CMS regelmäßig Passworte (bspw.
>>> für die dahinterstehende Datenbank) im Quellcode enthalten.
>>
>> Nein, nicht im Quellcode, sondern in einer Konfigurationdatei, an die
>> man von außen per HTTP(S) nicht herankommt. Und "geschützte Bereiche"
>> werden üblicherweise vom Webserver geschützt.
> 
> Wieso "nein"? Du wiederholst doch mit anderen Worten, was ich schrieb.

Du schreibst, im Quellcode von Dateien wären Passworte vorhanden.

Und ich sagte: nein, genau da sind diese Datene eben *nicht*. Das ist
nicht das selbe. Bei Symfony z.B. liegen die Datenbank-Zugangsdaten in
der Environment-Konfiguration, die *nicht* durch den Webserver
erreichbar ist.

>> Ich sehe immer noch kein Szenario, bei dem ein Angreifer bei korrekter
>> Konfiguration des Webservers an diese Daten herankommen sollte, nur weil
>> die Dateien für den Webserver via www-data lesbar sind.
> 
> Bei korrekter Konfiguration und Fehlerfreiheit des Webservers, PHP und der
> darin geschriebenen Anwendungen hat man sehr viele Probleme nicht, ja.

Eben - darum geht es.

Wenn die Anwendung fehlerhaft ist, ist es komplett egal, ob sie mit
www-data läuft oder nicht! Wenn ein Angreifer dadurch z.B. das
Datenbank-Passwort herausfindet, kann er auf die Datenbank zugreifen,
egal welcher User für die Ausführung des Webservers und PHP genutzt
wird. Ebenso kann ein Angreifer bei Erlangung von Schreibrechten
beliebige Malware auf der Website plazieren, egal mit welchem User das
im Einzelfall erfolgt.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#1460

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-21 09:49 +0200
Message-ID	<t8rt5e$ebp8$2@tota-refugium.de>
In reply to	#1453

Am 21.06.22 um 02:39 schrieb Arno Welzel:
> 
> Apache hat einen Bug, der dazu führt, dass man über eine bestimmte URL
> aus dem DocumentRoot des virtuellen Hosts ausbrechen kann und die Daten
> anderer virtueller Hosts über die Domain zu lesen.
> 
> Ja - das wäre theoretisch denkbar. Aber da www-data ohnehin auf Websites
> zugreifen darf - was genau würde man damit gewinnen, statt einfach über
> die vorgesehene Domain zuzugreifen?
Schon mal mit einem CMS gearbeitet? Was da so alles im DocRoot liegt.
Es ist also kein theoretisches Problem.

Tim

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

Scriptsammlung isolierter Vhost

Contents

#1441

#1444

#1448

#1449

#1446

#1447

#1456

#1459

#1455

#1443

#1445

#1454

#1453

#1458

#1462

#1470

#1471

#1474

#1475

#1460