it-swarm.com.de

In einem PHP / Apache/Linux Kontext, warum genau ist chmod 777 gefährlich?

Inspiriert von der Diskussion in dieser Frage , eine vielleicht dumme Frage.

Uns allen wurde beigebracht, dass es eine schlechte Sache ist, Verzeichnisse oder Dateien auf einem Linux-basierten Webhosting mit der Berechtigungsstufe 777 zu belassen und immer so wenig Berechtigungen wie nötig festzulegen.

Ich bin jetzt neugierig, wo genau die Gefahr der Ausbeutung liegt, insbesondere in einem PHP/Apache-Kontext.

Schließlich kann eine PHP Skriptdatei von außen (dh durch einen Aufruf des Webservers und anschließend des Interpreters) ausgeführt werden, unabhängig davon, ob sie als "ausführbar" markiert ist oder nicht ? Gleiches gilt für Dateien, die über die Befehlszeile aufgerufen werden. php interpreter, oder?

Wo genau liegt also die Sicherheitslücke bei 777? Ist es die Tatsache, dass andere Benutzer auf demselben Computer auf Dateien zugreifen können, die weltweit beschreibbar sind?

43
Pekka 웃

Hier ist ein Szenario:

  1. Sie haben ein ungeschütztes Verzeichnis, in das Benutzer hochladen können.
  2. Sie laden zwei Dateien hoch: ein Shell-Skript und eine PHP-Datei, die einen system()-Aufruf an das Shell-Skript enthält.
  3. sie greifen auf das gerade hochgeladene PHP-Skript zu, indem sie die URL in ihrem Browser aufrufen, wodurch das Shell-Skript ausgeführt wird.

Wenn dieses Verzeichnis 777 ist, bedeutet dies, dass jeder (einschließlich des Benutzers Apache, unter dem das PHP-Skript ausgeführt wird) es ausführen kann! Wenn das Ausführungsbit in diesem Verzeichnis und vermutlich in den Dateien im Verzeichnis nicht gesetzt ist, würde der obige Schritt 3 nichts bewirken.

editiere aus den Kommentaren: es ist nicht die Berechtigung der PHP Datei wichtig, es ist der system() Aufruf innerhalb der PHP Datei, der als Linux Systemaufruf vom Linux Benutzer Apache (oder ausgeführt wird Was auch immer Sie Apache eingestellt haben, um als) auszuführen, und das ist GENAU, wo das Ausführungsbit wichtig ist.

27
Mike Sherov

Dadurch wird das Anfälligkeitsprofil Ihrer Website für böswillige Aktivitäten erheblich erhöht, da nur ein einziges Konto eingerichtet werden muss.

Jeder, der mit einem Login Zugriff auf Ihr System erhält, kann Ihre Seiten nach Belieben bearbeiten, einschließlich der Änderung in "Diese Website ist wirklich unsicher. Bitte geben Sie mir Ihre Kreditkarteninformationen".

EDIT: (Um zu klären und die Adresse Kommentare)

Viele Server haben mehr als einen Lebenszweck. Sie führen mehrere Dienste aus. Wenn Sie diese Dienste sorgfältig voneinander isolieren, indem Sie jedem einen eindeutigen Benutzer zuweisen und die Dateiberechtigungen entsprechend verwalten, sind Sie zwar immer noch in heißem Wasser, wenn jemand die Anmeldeinformationen für ein Konto in Frage stellt, aber der Schaden, den sie anrichten können, ist auf diesen einen Dienst beschränkt . Wenn Sie nur ein generisches Konto haben und das gesamte Dateisystem auf 777 setzen, gefährdet ein gefährdetes Konto alles auf dem Computer.

Wenn Ihr Server nur Apache/PHP ausführt und keinen anderen Zweck im Leben erfüllt und es nur ein Konto gibt, unter dem Apache/PHP ausgeführt wird, ist die Gefährdung dieses einen Kontos so gut wie die Gefährdung des gesamten Computers durch das Sicht auf Ihre Anwendung (obwohl Sie immer noch Systemdateien haben sollten, die durch das zum Ausführen von PHP verwendete Konto geschützt und nicht beschreibbar sind ... das sollte immer noch nur für ein Administratorkonto/root möglich sein).

Wenn sie eine Datei schreiben können und diese ausführbar ist, können sie sie in etwas ändern, das auf Ihrem Computer ausgeführt wird (ausführbare Datei oder Skript), und dann PHPs Shell_exec verwenden, um diese ausführbare Datei auszuführen. Wenn Sie so konfiguriert sind, dass Shell_exec nicht zulässig ist, können sie auch Ihre Konfiguration ändern

3
Eric J.

Es gibt viele gute allgemeine Gründe, dem Minimalismus zu folgen, wenn es um Berechtigungen geht, aber im Zusammenhang mit einem LAMP-Webhost kommen nur wenige in den Sinn

  • Auf einer gemeinsam genutzten Hosting-Plattform können andere Benutzer, die Ihren Host gemeinsam nutzen, jetzt Ihre Skripte lesen und schreiben.
  • Auf einem dedizierten Host können Rouge-Prozesse Ihre Dateien lesen/schreiben und versehentlich löschen. Nehmen wir an, dass im Hintergrund ein benutzerdefinierter Protokollierungsprozess als Benutzer nobody ausgeführt wird, der einen Fehler aufweist, der dazu führt, dass versucht wird, rm -rf / zu erstellen. Im Allgemeinen ist dies harmlos, da es kaum eine Datei gibt, für die niemand Schreibrechte haben sollte, aber dieser Rouge-Prozess nimmt jetzt Ihre Dateien mit.
  • Um Ihre Website zu verunstalten, muss sich nur jemand als ein Benutzer Zugang verschaffen, selbst wenn Sie sagen, dass niemand oder ein solches Dummy-Konto existiert. Im Allgemeinen müsste der Angreifer einen weiteren Eskalationsangriff auf Benutzerebene ausführen, um an den Ort zu gelangen, an dem er Schaden anrichten kann. Dies ist eine echte Bedrohung. Einige nicht kritische Dienste werden möglicherweise unter Dummy-Konten ausgeführt und weisen möglicherweise eine Sicherheitsanfälligkeit auf.
2
anshul

Angenommen, Sie haben ein Softwarepaket auf Ihrem Server installiert und es besteht eine Zero-Day-Sicherheitsanfälligkeit. Der Angreifer erhält Zugriff auf das Admin-Kontrollfeld mit Upload-Funktionen. Wenn Sie alles auf 777 setzen, ist es für ihn trivial, ein Paket hochzuladen Shell-Skript, wo immer er will. Wenn Sie jedoch die Berechtigungen richtig einstellen, kann er dies nicht tun, da niemand/www-data/etc keine Schreibberechtigungen hat.

0
D.Snap