{"id":104360,"date":"2022-06-12T09:36:50","date_gmt":"2022-06-12T07:36:50","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme"},"modified":"2022-06-12T09:36:50","modified_gmt":"2022-06-12T07:36:50","slug":"uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme","title":{"rendered":"Eine Schwachstelle in firejail erm\u00f6glicht den Zugriff auf das Root-Verzeichnis des Systems.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im Tool zur isolierten Ausf\u00fchrung von Anwendungen Firejail wurde eine Schwachstelle (CVE-2022-31214) entdeckt, die es einem lokalen Benutzer erm\u00f6glicht, Root-Rechte im Hauptsystem zu erlangen. Ein funktionierender Exploit ist \u00f6ffentlich verf\u00fcgbar und wurde in aktuellen Versionen von openSUSE, Debian, Arch, Gentoo und Fedora mit installiertem Firejail getestet. Das Problem wurde in der Version firejail 0.9.70 behoben. Als vor\u00fcbergehende Schutzma\u00dfnahme k\u00f6nnen in den Einstellungen (\/etc\/firejail\/firejail.config) die Parameter «join no» und «force-nonewprivs yes» gesetzt werden. <\/p>\n
Firejail verwendet zur Isolation den Namespace-Mechanismus, AppArmor und die Systemaufruffilterung (seccomp-bpf) in Linux. F\u00fcr die Einrichtung eines isolierten Starts sind jedoch erh\u00f6hte Berechtigungen erforderlich, die durch die Bindung an das SUID-Root-Flag oder den Start mit sudo erhalten werden. Die Verwundbarkeit wird durch einen Fehler in der Logik der Option \u201e--join=\u201c verursacht, die zum Herstellen einer Verbindung zu einer bereits laufenden isolierten Umgebung dient (verglichen mit dem Login-Befehl f\u00fcr eine Sandbox-Umgebung) und die Umgebung anhand der darin laufenden Prozess-ID definiert. Vor dem Zur\u00fccksetzen der Berechtigungen bestimmt firejail die Berechtigungen des angegebenen Prozesses und wendet sie auf den neuen Prozess an, der mit der Option \u201e--join\u201c an die Umgebung angeschlossen wird. <\/p>\n
Vor der Verbindung wird gepr\u00fcft, ob der angegebene Prozess in der Firejail-Umgebung ausgef\u00fchrt wird. Diese \u00dcberpr\u00fcfung bewertet das Vorhandensein der Datei \/run\/firejail\/mnt\/join. Um die Schwachstelle auszunutzen, kann der Angreifer eine gef\u00e4lschte, nicht isolierte Firejail-Umgebung simulieren, indem er den Mount-Namespace nutzt, und sich anschlie\u00dfend mit der Option \u201e\u2014join\u201c verbinden. Wenn in den Einstellungen der Modus zum Verbot des Erwerbs zus\u00e4tzlicher Berechtigungen in neuen Prozessen (prctl NO_NEW_PRIVS) nicht aktiviert ist, wird Firejail den Benutzer mit der gef\u00e4lschten Umgebung verbinden und versuchen, die Einstellungen des Benutzer-Namespaces des Init-Prozesses (PID 1) anzuwenden. <\/p>\n
Letztendlich wird der \u00fcber \u201efirejail \u2014join\u201c verbundene Prozess im urspr\u00fcnglichen Namensraum des Benutzers mit unver\u00e4nderten Berechtigungen laufen, allerdings in einem anderen, vom Angreifer vollst\u00e4ndig kontrollierten Mount-Punkt. Der Angreifer kann so setuid-root Programme in seinem eigenen Mount-Punkt ausf\u00fchren, was es ihm beispielsweise erlaubt, die Einstellungen in \/etc\/sudoers oder die PAM-Parameter in seiner Dateihierarchie zu \u00e4ndern und die M\u00f6glichkeit zu erhalten, Befehle als root mit den Hilfsprogrammen sudo oder su auszuf\u00fchren. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"