Chroot Sicherheit

Apache, Lighttpd, nginx, Cherokee
hasch
Posts: 99
Joined: 2007-03-09 15:23

Chroot Sicherheit

Post by hasch » 2007-05-22 14:24

Ich habe eine chroot Umgebung eingerichtet, in der sich u.A. der Apache, MySQL usw. befinden, nun habe ich gelesen, dass es möglich ist aus einer chroot-Umgebung auszubrechen, sofern Programme mit SUID zur Verfügung stehen und/oder Prozesse/Programme root-Privilegien besitzen. suexec bsw. hat dies ja, ich kann es ja aber nicht aus dem chroot löschen, da der Apache es ja benötigt, gibt es da eine Möglichkeit zur Abhilfe oder ist das so schon "ok"? :)

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Chroot Sicherheit

Post by daemotron » 2007-05-22 15:14

Neben dem SUID-Exploit gibt es noch einige andere Möglichkeiten, den nackten chroot-Syscall auszuhebeln (z. B. chdir als Stichwort). Eine simple Möglichkeit die Sicherheit zu verbessern besteht darin, das Jail auf eine eigene Partition zu packen, die dann mit nosuid gemounted wird - allerdings hast Du dann wieder das suexec-Problem.

Wenn Du ein chroot-Jail ernsthaft sicherer machen möchtest, bleibt Dir eigentlich nichts anderes übrig, als auf einen Kernel-Patch zurückzugreifen, der den Standard-chroot-syscall durch eine sicherere Implementierung ersetzt (z. B. grsecurity).

hasch
Posts: 99
Joined: 2007-03-09 15:23

Re: Chroot Sicherheit

Post by hasch » 2007-05-22 15:33

Danke! Kernelpatch kommt erst einmal nicht in Frage, da es sich um einen V-Server handelt. Wären denn dann Alternativen wie chroot des mod_security oder mod_chroot sicherer???

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Chroot Sicherheit

Post by daemotron » 2007-05-22 15:43

Nein. Auch die greifen auf die Implementierung des chroot-syscalls im Kernel zurück. Und der war ursprünglich nie als Sicherheitsmaßnahme konzipiert, ergo entsprechend schwach gegen Unterwanderungsversuche geschützt.

kase
Posts: 1031
Joined: 2002-10-14 22:56

Re: Chroot Sicherheit

Post by kase » 2007-05-22 16:01

Reicht es denn, irgendein Programm mit SUID Bit im Chroot zu haben, oder muss das Programm, das dieses Bit hat, irgendwie einen bestimmten Bug aufweisen?

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Chroot Sicherheit

Post by daemotron » 2007-05-22 17:19

Nein, das Programm mit dem SUID-Bit muss natürlich den chroot-sycall in bösartiger missbrauchen, um eine Shell in einem Chroot oberhalb der aktuellen chroot-Umgebung zu starten. Wie leicht das geht, ist hier erklärt. Nun ist es einer Chroot-Umgebung aber eigen, dass sie als zweiter oder dritter Verteidigungswall eingesetzt wird - solange ein Angreifer die ersten Hürden (den chrooteten Dienst selbst, z. B. php-fcgi) nicht austricksen konnte, besteht auch keine Gefahr. Wenn aber für den Angreifer (unprivilegierter) Shell-Zugriff innerhalb einer chroot-Umgebung besteht, könnte er ein bestehendes Binary mit SUID-Bit manipulieren, um sich dann doch eine Shell (oder ein beliebiges anderes Programm) außerhalb des chroot-Jails zu starten.

kase
Posts: 1031
Joined: 2002-10-14 22:56

Re: Chroot Sicherheit

Post by kase » 2007-05-22 17:29

Ich fragte deshalb, weil bei RSSH ja ein SUID Programm, nämlich der rssh_chroot_helper in der chrooted Shell liegt.

Dachte schon gerade, dass RSSH nicht sicher ist.

Wobei ich es sowieso etwas merkwürdig finde, ich verstehe nicht ganz, warum überhaupt die mkchroot.sh aus rssh den rssh_chroot_helper mitkopiert.

Eigentlich sollte /usr/bin/rssh den rssh_chroot_helper im "richtigen" Dateisystem aufrufen und damit in das Chroot "switchen".

Da man ohne weiteres den rssh_chroot_helper in den Chroots löschen kann, und man nach dem SFTP Login trotzdem noch "chrooted" ist, denke ich, dass das eher ein Bug ist, oder habe ich da einen Denkfehler drin?

Sorry für OT übrigens :)

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Chroot Sicherheit

Post by daemotron » 2007-05-22 17:40

Ouch, der chroot_helper hat eigentlich nichts innerhalb des chroot-jails zu suchen. Da dieser ja nichts anderes macht als einen chroot-syscall abzusetzen, kann man ihn bestimmt mit entsprechend manipulierten Parametern (bzw. einer manipulierten rssh-Konfiguration innerhalb des chroot-jails) dazu bringen, aus dem Jail auszubrechen (was bei gesetztem SUID-Bit ja kein Problem ist, da der Kernel den Syscall akzeptieren wird).

Gerade gegen solche Flausen ist aber ein Kernel-Patch wie grsecurity ein netter Schutzmechanismus - entsprechende Konfiguration vorausgesetzt, wird einfach der chroot-Syscall von innerhalb eines chroot-Jails abgeklemmt, da kann sich ein Angreifer dumm und dusselig probieren...

ghoster1970
Posts: 71
Joined: 2006-06-21 13:31
Location: Potsdam

Re: Chroot Sicherheit

Post by ghoster1970 » 2007-05-22 18:10

Ohne hardened Kernel macht ein Chroot eh wenig Sinn, es würde für Skript Kiddies ausreichen die noch nicht den Level eines "Bloody Beginners" übersprungen haben.
Ist es IMHO nicht zusätzlich von Nutzen, wenn man ein evtl. vorhandenes /tmp umbenennt? Die Configfiles, ähnlich wie beim Lighty, außerhalb eines chroots lagert und dem User, der das Chroot "besitzt", keine Shell zur Verfügung stellt, ggf. in dessen Profile Beschränkungen vornimmt?

kase
Posts: 1031
Joined: 2002-10-14 22:56

Re: Chroot Sicherheit

Post by kase » 2007-05-22 18:12

Wie gesagt, ich finde es auch äußerst merkwürdig. Es ist aber defintiv ganz bewusst "eingebaut", nach einem Bug, dass er zufällig mitkopiert wurde, sieht mir das eher nicht aus.

Ausschnitt aus mkchroot.sh

Code: Select all

...
# copy SSH files

scp_path="/usr/bin/scp"
sftp_server_path="/usr/lib/openssh/sftp-server"
rssh_path="/usr/bin/rssh"
chroot_helper_path="/usr/lib/rssh/rssh_chroot_helper"

... (Directories anlegen)

cp "$scp_path" "$jail_dir$scp_path" || 
        fail "Error copying $scp_path. Exiting." 5
cp "$sftp_server_path" "$jail_dir$sftp_server_path" || 
        fail "Error copying $sftp_server_path. Exiting." 5
cp "$rssh_path" "$jail_dir$rssh_path" || 
        fail "Error copying $rssh_path. Exiting." 5
cp "$chroot_helper_path" "$jail_dir$chroot_helper_path" || 
        fail "Error copying $chroot_helper_path. Exiting." 5
...
Einfach auszunutzen ist die Sicherheitslücke vermutlich nicht, da man bei rssh ja nur ganz bestimmte Befehle absetzen kann, und dazu gehört sicher nicht der rssh_chroot_helper.

Es funktioniert aber wie gesagt auch ohne Probleme, wenn man den rssh_chroot_helper in den Chroots einfach löscht.

Den Kernel patchen kann ich leider auch nicht, da es sich auch bei mir um einen vServer handelt.

Ich will den Thread jetzt aber nicht noch weiter ins Offtopic treiben und bitte deshlab auch nochmal um Entschuldigung :)

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Chroot Sicherheit

Post by daemotron » 2007-08-20 09:29

Sorry für die Leichenfledderei, aber ich bin noch auf was gestoßen in Zusammenhang mit chroot, rssh und dem rssh_chroot_helper:
rssh security implications wrote:Max Vozeler has reported a problem whereby rssh can allow users who have shell access to systems where rssh is installed (and rssh_chroot_helper is installed SUID) to gain root access to the system, due to the ability to chroot to arbitrary locations. There are a lot of potentially mitigating factors, but to be safe you should upgrade immediately.

The 2.3.0 release of rssh fixes this problem, by forcing the chroot helper to re-parse the config file to decide where to chroot(2) to. Users with shell access to the system can not subvert the chroot location, and may not be able to chroot at all depending on the configuration of rssh, which solves the problem.
Ist allerdings ein Bug, der bereits im Dezember 2005 reported und gefixt wurde. Von daher gehe ich mal davon aus, dass der aktuelle rssh_chroot_helper nicht für solchen Unsinn mißbraucht werden könnte. Aber das Beispiel zeigt einfach zu gut, wie leicht ein scheinbar harmloses Progrämmchen mit gesetztem SUID-Bit bei einer feindlichen Übernahme behilflich sein kann.