ubuntuusers.de

Chroot von einem Rettungssystem aus funktioniert aktuell nicht mehr.

Das Verzeichnis /bin/bash ist leer.

Soweit ich erfahren habe, hat es Vulnerabilitätsprobleme gegeben.

Vielen Dank.

Und was ist jetzt dein Problem / deine Fragestellung?

Bitte richtig fragen lesen und beachten.

Hallo,

vielen Dank für die Hinweise.

Hier deshalb die Information über den Zusammenhang:

Zitat https://wiki.ubuntuusers.de/chroot/Livesystem/

Anfang-–––––––––––––––––––

Vor dem Wechsel in das installierte System muss gegebenenfalls diesem der Zugriff auf wichtige Systeminformationen zugesichert werden. Man bindet dazu das Verzeichnis mit den Gerätedateien /dev innerhalb des installierten Systems ein: sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts Ähnlich verfährt man mit dem Schnittstellendateisystem /proc und dem System-Verzeichnis /sys. Diese werden mit sudo mount --bind /sys /mnt/sys sudo mount --bind /proc /mnt/proc eingebunden. Weiterhin muss /run eingebunden werden: sudo mount --bind /run /mnt/run Hinweis: Der folgende Einzeiler hängt diese notwendigen Systemverzeichnisse in einem Aufruf ein: for dir in /dev /dev/pts /proc /sys /run; do sudo mount --bind $dir /mnt$dir; done Gemountete Datenträger können optional eingebunden werden: sudo cp /proc/mounts /mnt/etc/mtab Um die Internetverbindung sicherzustellen, werden u.U. die DNS-Server-Angaben benötigt. Diese kopiert man z.B. mit: sudo mount -o bind /etc/resolv.conf /mnt/etc/resolv.conf Hinweis: Vorstehender Befehl kann Fehlfunktionen verursachen, wenn /etc/resolv.conf symbolischer Link ist. In einem solchen Fall kann man die Zieldatei des symbolischen Links an die entsprechende Stelle der neuen Dateisystemhierarchie kopieren und dann in dieser /etc/resolv.conf als symbolischen Link neu erstellen. Man sollte vermeiden, die Art der Datei /etc/resolv.conf zu verändern, weil einige Programme zur DNS-Namensauflösung ihre Funktionsweise ändern, je nachdem ob dies eine reguläre Datei oder ein symbolischer Link ist. System-Wechsel Es erfolgt der Wechsel in das installierte System: sudo chroot /mnt /bin/bash Nun kann die Reparatur des installierten System vorgenommen werden.

Zitat Ende ––––––––––––––––––––––––––

Was soll das denn? Was sollen wir mir der Wiki-Kopie?

Und dann auch noch so dermaßen übel formatiert.

Nochmal: Bitte >> richtig fragen << lesen und beachten.

ber9999 schrieb:

Chroot von einem Rettungssystem aus funktioniert aktuell nicht mehr.

Doch es funktioniert, wenn man es richtig macht. Du könntest auch andererseits dein installiertes System so kaputt gemacht haben, dass es deshalb nicht funktioniert.

Das Verzeichnis /bin/bash ist leer.

Das war noch nie ein Verzeichnis. Wenn dem so bei dir ist, dann hast du einen Fehler schon gefunden.

Um konkret zu werden. Starte noch mal neu und dann zeigst du uns die kompletten Ein- und Ausgabe des Terminals. Sonst ist das doch nur Lesen im Kaffeesatz (und ich bin in Teetrinker).

Hallo schwarzheit,

vielen Dank. Unten findest Du noch ein Zitat zum Problem. Besser kann ich es auch nicht beschreiben. Ich will nur wissen, ob Ubuntu etwas unternommen hat, um die Vulnerability zu beseitigen und ob diese Maßnahme dazu geführt hat, dass die Anweisung sudo chroot /mnt /bin/bash nicht mehr richtig ausgeführt wird.

Zitat https://www.heise.de/en/news/chwoot-Critical-Linux-vulnerability-makes-users-root-on-most-systems-10466916.html ––––––––- Anfang

There is a critical security flaw in the Linux tool "sudo" and makes unprivileged users "root", the system administrator, in no time at all. The reason for the malaise: a bug in the chroot function of sudo. This function is actually intended to "lock" users in their home directory, but allows them to break out of it and extend their rights. An update is available; admins of multi-user systems should act quickly.

The vulnerability exploits a bug in the chroot implementation. Between two function calls, this calls the "Name Service Switch" (NSS), which in turn loads the file /etc/nsswitch.conf. The attacker can now cause this function to load a file he has prepared with C code (a dynamic .so library) and execute it with root rights.

Critical vulnerability in many versions The vulnerability is hidden in various sudo versions – it is unclear in which ones exactly. The discoverer, Rich Mirch from "Stratascale Cyber Research Unit", was unable to test all versions. However, he is certain that the vulnerability is not present in older versions prior to sudo 1.8.32, as the malicious code only appeared in this version. The bug can be found in the stable versions 1.9.14 to 1.9.17 that he tested. It has the CVE ID CVE-2025-32463 and a CVSS rating of 9.2 (priority: "critical"). The discoverer provides an example exploit.

This makes many, possibly millions of Linux systems vulnerable. Ubuntu in its current version 24.04.1, Fedora 41 and potentially many other distribution versions are at risk. However, updated packages are already available, under Ubuntu for all versions from Jammy to Plucky. They port the bugfix contained in sudo 1.9.17p1 to the sudo version used there. The currently stable Debian version "Bookworm" is not affected – its sudo version is simply too old.

Zitat Ende-––––––––––––––––––––––––––––––

Da du anscheinend nicht mal gewillt bist dein Problem ordentlich zu beschreiben und dein Posts ordentlich zu formatieren bin ich hier raus.

ber9999 schrieb:

[…]

There is a critical security flaw in the Linux tool "sudo" […] However, updated packages are already available, under Ubuntu for all versions from Jammy to Plucky.

Diese Stelle in Deinen Zitat beantwortet wohl Deine nicht formulierte Frage.

Ich frage mich allerdings, was das Problem von sudo mit chroot zu tun hat … … ? …

Alter Kram. Hast du auch auf's Datum geschaut?

Ubuntu in its current version 24.04.1, …

Derzeit ist 24.04.3 seit vier Monate draußen.

Ich hatte gerade eh noch etwas am vollverschlüsselten Notebook zu erledigen. Da habe ich es ausnahmsweise per chroot gemacht. Einwandfrei nach Wiki.