Aus dem Jail "ausbrechen"

K

Korsakov

Member
Hallo,

ich habe ein merkwürdiges Verhalten beobachtet, was einem erlaubt, von einem Jail aus, beliebige Dateien auf dem Hostsystem auszulesen. - Um keine Panik auszulösen sage ich gleich, dass sich dieser Fehler nicht ausnutzen lässt, wenn man nicht die Möglichkeit hat als "root"-Benutzer im Hostsystem Verzeichnisse zu verschieben. Selbst dann, tritt dieser Fehler nur unter besonderen Randbedingungen auf.
Ich habe mal eine kurze Anleitung dazu gemacht:

http://hoppel.homeunix.net/dateien/jail/

Weiß jemand, ob dieser Fehler bekannt ist und hat ggf. dazu weitere Informationen?
 
Hmm.
Ich hab mir das eben angeschaut.
Nur um es richtig zu verstehen:
1. Du erstellst in der Jail Verzeichnisse
2. Auf dem Hostsystem verschiebst Du dann diese erstellten Verzeichnisse in ein anderes Verzeichnis auf dem Hostsysstem

--> Was soll das? Eine Jail ist ein System, das Hostsystem ein anderes systems. Du verschiebst Verzeichnisse in der Jail auf das Hostsystem, wo ist da der Sinn? Wer sollte sowas machen? Oder versteh ich da was falsch?

3. Dann gehst Du wieder in die Jail, und versucht aus dem verzeichnis zu wechseln welches nicht mehr da ist, da verschoben.

--> Ich frage mich nach dem Sinn dieser Aktion, und würde statt von einem Bug von einem Bedienfehler sprechen, wenn ich es richtig verstehe.
Eine Jail muss man so behandeln wie ein eigenes System. Nur weil es aus der Sicht des Hostsystems wie ein Verzeichnis aussieht, kann es aber nich so behandelt werden, sondern muss wie ein weiteres System behandelt werden. Also einloggen mit ssh, oder nutzen von "jexec" über das Hostsystem.

Ich habe das Szenario noch nicht nachgespielt, da ich nicht auf die Idee kommen würde ein verzeichnis in einer Jail zu erstellen, als User in dieses verzeichnis zu wechseln, auf dem Hostsystem dieses verzeichnis dann zu verschieben....

Aber wie gesagt, evtl. habe ich da auch was falsch verstanden...
 
Ich habe es eben mal ausprobiert. Auch unter FreeBSD 5.1-RELEASE, ohne Erfolg. Sprich, es hat nicht funktioniert.
 
Original geschrieben von asg
--> Ich frage mich nach dem Sinn dieser Aktion, und würde statt von einem Bug von einem Bedienfehler sprechen, wenn ich es richtig verstehe.
Zum Vergrößern anklicken....
Der praktische Zweck ist hier konkret unwichtig. Ich schrieb ja, dass es sehr unwahrscheinlich ist, das in diesem Fall irgendwie auszunutzen, da man auf Mithilfe vom Hostsystem angewiesen ist.

Es geht allein um die Tatsache, dass es theoretisch möglich ist, vom Jail Zugriff auf's Hostsystem zu erlangen.
Dieses kleine Beispiel zeigt, dass offensichtlich keine Überprüfung gemacht wird, ob wir uns noch im Jail oder schon auf dem Hostsystem bewegen. - Es sollte unmöglich sein, in jedem noch so undenkbaren und konstruierten Fall irgendwie ausbrechen oder anderweitig Zugriff erlangen zu können.

Eine Jail muss man so behandeln wie ein eigenes System. Nur weil es aus der Sicht des Hostsystems wie ein Verzeichnis aussieht, kann es aber nich so behandelt werden, sondern muss wie ein weiteres System behandelt werden.
Zum Vergrößern anklicken....
Erkläre einem potentiellen Angreifer, dass seine verwendete Methode unkonventionell ist und daher unfair ist.
 
Original geschrieben von Korsakov
Der praktische Zweck ist hier konkret unwichtig. Ich schrieb ja, dass es sehr unwahrscheinlich ist, das in diesem Fall irgendwie auszunutzen, da man auf Mithilfe vom Hostsystem angewiesen ist.
Zum Vergrößern anklicken....

Der praktische Zweck ist alles was zählt. Wenn es keinen praktischen Zweck gibt, dann ist es auch gegenstandlos.

Es geht allein um die Tatsache, dass es theoretisch möglich ist, vom Jail Zugriff auf's Hostsystem zu erlangen.
Dieses kleine Beispiel zeigt, dass offensichtlich keine Überprüfung gemacht wird, ob wir uns noch im Jail oder schon auf dem Hostsystem bewegen. - Es sollte unmöglich sein, in jedem noch so undenkbaren und konstruierten Fall irgendwie ausbrechen oder anderweitig Zugriff erlangen zu können.
Zum Vergrößern anklicken....

In der Theorie ist vieles möglich, ob es sich dann paraktisch, und darauf kommt es an, auch sinnig umsetzen lässt, ist aber eine andere Sache, und darauf kommt es ja an.

Was heisst Überprüfung? Du verschiebst vom Hostsystem einfach ein Verzeichnis in ein anderes Verzeichnis. Wer kommt bitte auf die Idee, ein verzeichnis in einer Jail, in ein Verzeichnis auf dem Hosystem zu verschieben? Wo steckt der Nutzen?
Denn...

Erkläre einem potentiellen Angreifer, dass seine verwendete Methode unkonventionell ist und daher unfair ist.
Zum Vergrößern anklicken....

...wenn ein Angreifer erstmal Zugriff auf das Hostsystem hat, dann muss er nicht mehr ein Verzeichnis einer jail auf das des Hostsystems kopieren. Denn er hätte ja so oder so Zugriff darauf, wo also liegt hier der praktische Nutzen für einen Angreifer?

IMHO, ist es immer noch ein bedienfehler, und da kann eine Jail nun nichts für. Das Szenario das ein Angreifer der auf dem Hostsystem schon drauf ist, damit was anfangen kann istn unlogisch, da er einfach in die Jail wechseln kann...

Wenn jemand BSD fährt und alle ports aufmacht, telnet nutzt,..., ist dann das system unsicher, oder liegt es eher am Benutzer?

Wie dem auch sei, schreib einen PR oder ein mail (Poul Hennig-Kamp) wenn es Dir wichtig erscheint, ich sehe gerade wirklich kein problem, oder ist mir immer noch was entgangen....
 
Vielleicht wird es deutlich, wenn ich es wiederhole: Es gibt konkret keinen Nutzen.

Es geht um das Konzept. Das Konzept lässt es offensichtlich zu, Dateien im Hostsystem mit root-Privilegien vom Jail aus zu lesen und zu schreiben.
Von diesem Umstand sind wir in dem geschilderten Fall nur einen einzigen Befehl, nämlich "mv", im Hostsystem entfernt. Es sollte aber auf gar keinen Fall passieren!

zu deinem "Bedienfehler" zitiere ich aus einem Buch zu Linux-Programmierung:

"Die UNIX-Philosophie [...]
Sie werden niemals genau einschätzen können, wie einfallsreich Anwender Ihr Programm nutzen werden. [...] Gehen Sie niemals davon aus, dass Sie wissen, was Ihre Anwender zu tun gedenken."

Kurz: So triviale Bedienfehler mit solch kritischen Folgen, sollten ausgeschlossen werden können.
 
Wie gesagt, schreibe an Paul oder einen PR.

Dieser Bedienfehler ist gleichzusetzen mit der IPFW rule "ipfw add allow ip from any to any" und dies als erste rule, nachdem die anderen kommen. Dies sollte auch nicht möglich sein, ist sogar noch leichter zu machen als das angesprochene "Problem" mit der Jail, und wäre ein Fehler des Users der die Rules anlegt.
Ein User der also aus einer Jail ein Verzeichnis einfach verschiebt, als würde es sich um ein x-beliebiges Verzeichnis handeln, handelt, ebenso wie bei der FW Regel, fahrlässig und hat die Jail an sich nicht verstanden, imho.

Ich wüsste nun auch nich wie man dies reglemetieren sollte. Die jail müsste also überwachen in welchem verzeichnis ein user ist, und ob dieses mittels "mv" vom Hostsystem verschoben wird. Das ist, wieder imho, zu vernachlässigen, da es sich um einen bedienfehler handelt. Wo soll auch der Sinn stecken? Ok, Du sagst es gibt keinen Nutzen, warum sollte es dann jemand machen? Und, wenn er es macht, ist er dann nicht selbst daran schuld, denn er hat augenscheinlich etwas nicht begriffen, ebenso wieder der Vergleich zu den IPFW Rules.

Wie gesagt, frage einfach mal bei Paul nach, oder auf der mailingliste der Jail.
Mich würde interessieren wie es er/die dort sehen.
Kannst dann ja die Antwort hier posten.

Ich sehe darin kein Problem, zumal ich es bei mir nicht nachvollziehen kann...
 
Ich konnte das beschriebene Szenario auf 5.1-CURRENT nachvollziehen. Allerdings würde ich wie grunix das aktive 'mv'-en eines Verzeichnisses aus dem jail-Tree in den nicht-jail-Tree als eklatanten Bedienfehler bezeichnen.

Und es ist ja gute alte UNIX-Tradition, insbesondere root sich gerne mal in den eigenen Fuss schiessen zu lassen.

Und zu deinem Quote:
Gehen Sie niemals davon aus, dass Sie wissen, was Ihre Anwender zu tun gedenken.
Zum Vergrößern anklicken....
Bist Du sicher, dass das aus einem Unix-Buch stammt? Hört sich für mich eher nach Windows an ("Sind Sie sicher ...?"). Der Author von 'rm' hat bestimmt nicht so gedacht (ausser als er die "-i" Option eingebaut hat).
 
Hm,

ich finde es gut das man die Möglichkeit hat solche Bedienfehler zu machen. Man kann ja auch kein Root Passwort vergeben wenn man nicht will.

Reglementierungen von Seiten eienes Betriebssystems sind immer schlecht -> siehe Windows.

Sinnvoller wäre an dieser Stelle vielleicht eine Warnung an root das das Vorgehen ein Sicherheitsrisiko darstellen _koennte_. (Ähnlich wie bei OpenBSD bei nem rootlogin "dont use root use su" steht)
 
Wäre es auch ein Bedienungsfehler, ein Jail unterhalb eines Jails zu erstellen?

Meinetwegen das erste
/usr/home/jails/192.168.1.4

und das zweite
/usr/home/jails/192.168.1.4/usr/home/knast

Wenn ja, warum?

Funktionieren tut's reibungslos und ohne Komplikationen.

Jemand, der auf beide Jails root-Zugang hätte, könnte dann auf Grund des geschilderten Umstands Zugriff auf's Hostsystem erlangen.
 
Zuletzt bearbeitet:
Original geschrieben von Korsakov
Wäre es auch ein Bedienungsfehler, ein Jail unterhalb eines Jails zu erstellen?
Zum Vergrößern anklicken....

Frage Dich doch einfach mal nach Sinn oder Unsinn einer solchen Konfiguration. Wo liegt der Sinn versteckt so etwas zu tun? Weiterhin, warum und für was gibt es Jails?

Meinetwegen das erste
/usr/home/jails/192.168.1.4
und das zweite
/usr/home/jails/192.168.1.4/usr/home/knast
Wenn ja, warum?
Zum Vergrößern anklicken....

Weil mir, imho, einfach der Sinn einer solchen Konfiguration nicht griffig ist, kann aber auch daran liegen das ich keine Sekunde darüber nachgedacht habe.
Was sollte die obige Konstallation denn bringen?

Zumal ich eine Jail auch nicht nach /usr/home legen würden, eher auf eine eigene Partition (dann hat man kein Problem damit das einem das eigentlich System vollgeschrieben wird) oder unter /usr/blablub.

Funktionieren tut's reibungslos und ohne Komplikationen.
Zum Vergrößern anklicken....

Warum sollte es nicht funktionieren? Ich habe es, mangels Nutzen, oder fehlender kreativität, noch nicht ausprobiert, aber da vom Hostsystem alles wie ein Verzeichnis aussieht, und dies keinen Unterschied zwischen einem Verzeichnis macht in der eine Jail ist, und einem x-beliebigen, ist es logisch das es funktioniert. Nochmals, wo steckt der Sinn? Was hat dies mit einer Jail zu tun wie man diese nutzt?
 
Nun gut. Pragmatismus hin oder her. Es ist auch möglich ohne Mithilfe des Systemadministrators seinen absoluten Jailpfad zu erfahren. Es wird offensichtlich eine Information preisgegeben, die für ein autarkes Jailsystem unsichtbar sein sollte.

Fazit: Das System weiß nicht zu jedem Zeitpunkt, ob eine Funktion für's Jail ausgeführt wird oder nicht.

Nebenbei bemerkt ist es in der Informatik eher unüblich einen Fehler, der nicht zur Kompromittierung des Systems führt, Benutzerfehler zu nennen.
 
Bevor wir uns jetzt gegenseitig mit Aussagen über Bedienerfehler, übliche Vorgehensweisen usw. zu-flamen würde ich es doch für sinnvoll halten, mal mit phk@phk.freebsd.dk in Kontakt zu treten und von ihm seine Meinung einzuholen. Wer macht das?
 
Original geschrieben von Korsakov
Nun gut. Pragmatismus hin oder her. Es ist auch möglich ohne Mithilfe des Systemadministrators seinen absoluten Jailpfad zu erfahren. Es wird offensichtlich eine Information preisgegeben, die für ein autarkes Jailsystem unsichtbar sein sollte.
Zum Vergrößern anklicken....

Wie meinst Du dies?

Fazit: Das System weiß nicht zu jedem Zeitpunkt, ob eine Funktion für's Jail ausgeführt wird oder nicht.
Zum Vergrößern anklicken....

Das muss das Hostsystem auch nicht, zumal ein "mv", vom Hostsystem ausgeführt, und dieses auf ein Verzeichnis in einer Jail gerichtet ist (und in die Struktur des Hostsystems geschoben wird) keine Funktion wo das Hostsystem unterscheiden muss, sondern der User. Denn für das Hostsystem ist ein verzeichnis ein Verzeichnis.

Der Jail system call setzt eine Jail und locked alles Prozesse die in dieser laufen in diese Jail. Wenn also einmal ein Prozess in einer Jail aufgerufen wurde, so kann dieser nicht aus der Jail entkommen.
Nochmals: Es geht darum das kein Prozess von einer Jail in das Hostsystem entkommen kann. Der Eingriff mit "mv" vom Hostsystem aus ist also ein Fehler des Bedieners und nicht Aufgabe der Jail. Und ja, ich wundere mich zwar auch, aber sehe es nicht als Sicherheitsrisiko an, aus den schon genannten Gründen.

In dem Verzeichnis in dem die Jail liegt, ändert man auch nichts vom Hostsystem aus, dazu loggt man sich wie auf ein fremdes System mit ssh ein, nur weil es die Mööglichkeit gibt, da es sich um ein Verzeichnis handelt, ist diese herangehensweise trotzdem falsch, nicht so gedacht.
Desweiteren gibt es unter 5.x für Jails den Befehl "jexec" mit dem es möglich ist Befehle vom Hostsystem in der Jail auszuführen.
Für die Unwissenheit der User wie man mit einer Jail umgeht und was diese ist, kann das Konzept nichts. Denn dieses arbeitet ohne Probleme so wie es vorgesehen ist (Vergleich mit den FW Rules hatte ich schon gegegeben).

Nebenbei bemerkt ist es in der Informatik eher unüblich einen Fehler, der nicht zur Kompromittierung des Systems führt, Benutzerfehler zu nennen.
Zum Vergrößern anklicken....

Du behandelst mit Deiner Vorgehensweise die Jail einfach falsch, das ist das problem, und das ist der Bedienerfehler, imho.
Wenn ich Tür und Tor im System offen lasse, root kein Passwort gebe, ssh root login erlaube,..., dann ist das auch ein eklatantet Bedienerfehler, und nicht ein Problem des Systems.
Zumal eine Jail als ein eigenes System ist gesehen werden MUSS, allein das verbietet es schon mit "mv" vom Hostsystem aus in der Jail rumzufummeln wie wenn es sich nur um ein einfaches Verzeichnis handeln würde.
 
Ohne den Thread bis zum Ende gelesen zu haben und leider auch ohne das Beispiel als "code" gesehen zu haben (der link ist weg, ich hab's mir so zusammengereimt) ist das ein extremer Bug! (IMHO)
_Niemals_ darf es möglich sein aus einem Jail raus _irgendwas_ am Hostsystem zu machen, geschweige denn Files zu lesen. Auch wenn ein (so zusammengereimt) unsinniges "mv" abgesetzt wurde.

Waren die Platten im devfs geschützt?
Hat noch jemand das Beispiel?
Das wäre ja der Hammer!

Grüsse,

-Kaeptn
 
@Kaeptn
Wenn ich mich recht entsinne:
- verschiebt vom Hostsystem einen Ordner der in der Jail liegt auf einen anderen Punkt im Hostsystem (sinnfrei imho, also Bedienungsfehler/ den Befehl "rm" verbietet auch niemand, die rule "ipfw add allo ip from any to any" auch nicht)

Bei mir hat das im übrigen nicht funktioniert.
Wer eine Jail als normales Verzeichnis ansieht, ist selbst schuld wenn er es so behandelt und sich dann evtl. über die Auswirkungen wundert.
Man arbeitet IN einer Jail, oder nutzt den Befehl "jexec" vom Hostsystem. Man kopiert auch nicht einfache, sondern macht das mit ftp, scp, whatever, da eine Jail ein extra system ist. Wer das nicht sieht, nur weil es ein verzeichnis auf dem Hostsystem darstellt, ist selbst schuld.
 
Original geschrieben von asg Bei mir hat das im übrigen nicht funktioniert.
Zum Vergrößern anklicken....

Funktioniert bei mir nachwievor unter 4.9 und 5.2.

Wer eine Jail als normales Verzeichnis ansieht, [...]
Zum Vergrößern anklicken....
Ein Jail ist auch kein besonderes Verzeichnis. Ein Jail ist gar kein Verzeichnis. Das Einsprerren funktioniert durch eine triviale Kennzeichnung eines Prozesses, dessen Rechte zur Systemmanupulation und Mittel zur Kommunikation über beispielsweise Sockets und IPC anhand dieser Kennzeichnung stark bis vollständig eingeschränkt werden. Werden mehrere Prozesse mit der gleichen Kennzeichnung versehen, dann sind jene gruppiert und die Einschränkungen innerhalb der Gruppe sind teilweise aufgehoben. - Das ist das wesentliche Funktionsprinzip von Jails.
Um den Wirkungsbereich dieser gruppierten bzw. eingesperrten Prozesse zu beschränken, wird ein einfaches chroot() verwendet. - Und genau dort liegt der Haken. Das von mir beschriebene Verhalten ist nicht jailspezifisch, sondern funktioniert auch beim simplen chroot; es hat nichts direkt mit Jails zu tun, sondern mit chroot().

Ich mach noch einmal eine kurze Anleitung für Kaeptn:
(funktioniert übrigens nicht mit sh, aber mit bash und csh)

bei bash und 5.2 tut man beispielsweise folgendes:
(abweichungen können auftreten, ggf. improvisieren)

mkdir -p /_jailtest/blub && \
cd /_jailtest/blub && \
mkdir -p usr/local/bin libexec lib && \
cp /usr/local/bin/bash usr/local/bin/ && \
cp /libexec/ld-elf.so.1 libexec/ && \
cp /lib/libm.so.2 lib/ && \
cp /lib/libncurses.so.5 lib/ && \
cp /lib/libc.so.5 lib/ && \
mkdir test && \
chroot .

... und schließlich ins Verzeichnis 'test' im chroot wechseln:

cd test

Außerhalb des chroots in einer anderen Konsole:

mv /_jailtest/blub/test /_jailtest/

Nun wieder im chroot:

cd ../..

und schon ist man draußen und kann beispielsweise folgendes ausführen

bin/cat root/.bash_history
bin/cat etc/passwd

Die Einschränkungen bezüglich Zugriff auf Systemvariablen, Sockets und ähnlichem bleiben bei einem Jail erhalten (bei chroot gibt es keine Beschränkungen). Doch zumindest hat man so Lese- und Schreibzugriff auf (fast) jede Datei.

Aber belassen wir es bei einem Bedienungsfehler. "This is a kind of don't do that issue."

Gruß
 
Naja, wenn Du das chroot-Verzeichnis verschiebst, verschiebst Du natürlich /.
Das ist wirklich etwas ungewöhnlihc, würde bei meinem Jails eh nicht funktionieren, da sie Mountpoints sind, dennoch ein Fehler.
Ich hab's jetzt zwar nicht nachgespielt aber wenn der Jail im Falle eines verschobenen (nicht mehr korrekten) root Verzeichnisses nicht sofort terminiert sehe ich das als mittelprächtig gravierenden Bug an.
Auch wenn man dafür Host-Zugang braucht, FreeBSD will uns mit GEOM verbieten MBR und labels zu schreiben, also sollte sowas erst recht nicht möglich sein.

Grüsse,

-Kaeptn
 
Ohne den ganzen thread ebenfalls gelesen zu haben,
es ist Unix Philosophie, dass im Zweifelsfall immer root recht hat, und nicht der Kernel.
Das bedeutet auch, dass root die dümmsten Fehler machen darf, wenn er das will.

rm -rf .* ;)
 
Original geschrieben von Kaeptn
Naja, wenn Du das chroot-Verzeichnis verschiebst, verschiebst Du natürlich /.
Zum Vergrößern anklicken....
Das chroot-Verzeichnis wird nicht verschoben, sondern das Verzeichnis in dem man sich befindet. Die Wurzel des chroots bleibt unangetastet und ist weiterhin gültig.

Gruß
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben