{"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\/news\/uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme","title":{"rendered":"Sicherheitsanf\u00e4lligkeit in Firejail, die Root-Zugriff auf das System erm\u00f6glicht","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In der Anwendung zur isolierten Ausf\u00fchrung von Programmen Firejail wurde eine Sicherheitsanf\u00e4lligkeit (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-Utility 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 Optionen \u201ejoin no\u201c und \u201eforce-nonewprivs yes\u201c festgelegt werden. <\/p>\n
Firejail verwendet zur Isolation die Mechanismen von Namespaces, AppArmor und Systemaufruffilterung (seccomp-bpf) in Linux, erfordert jedoch zur Konfiguration des isolierten Starts erh\u00f6hte Berechtigungen, die durch Verkn\u00fcpfung mit der SUID-Root-Utility oder durch Ausf\u00fchrung mit sudo erlangt werden. Die Sicherheitsanf\u00e4lligkeit wird durch einen Fehler in der Logik der Option \u201e--join=\u201c verursacht, die f\u00fcr die Verbindung zu einer bereits laufenden isolierten Umgebung gedacht ist (analog zum login-Befehl f\u00fcr die Sandbox-Umgebung) und die Umgebung anhand des in ihr arbeitenden Prozess-IDs bestimmt. In der Phase vor dem Entzug der Berechtigungen bestimmt Firejail die Berechtigungen des angegebenen Prozesses und \u00fcbertr\u00e4gt diese auf den neuen Prozess, der mit der Option \u201e--join\u201c mit der Umgebung verbunden wird. <\/p>\n
Vor der Verbindung wird \u00fcberpr\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 Sicherheitsanf\u00e4lligkeit auszunutzen, kann der Angreifer eine fiktive, nicht isolierte Firejail-Umgebung simulieren, indem er den Mount-Namespace verwendet, und sich dann mit der Option \u201e--join\u201c damit verbinden. Wenn in den Einstellungen der Modus zum Verhindern des Erlangens zus\u00e4tzlicher Berechtigungen in neuen Prozessen (prctl NO_NEW_PRIVS) nicht aktiviert ist, wird Firejail den Benutzer mit der fiktiven Umgebung verbinden und versuchen, die Einstellungen des User-Namespace des Init-Prozesses (PID 1) anzuwenden. <\/p>\n
In der Folge wird der \u00fcber «firejail —join» angeschlossene Prozess im urspr\u00fcnglichen Namensraum der Benutzer-IDs des Nutzers mit unver\u00e4nderten Rechten erscheinen, jedoch in einem anderen, vom Angreifer vollst\u00e4ndig kontrollierten Mount-Punkt. Der Angreifer kann unter anderem setuid-root-Programme in diesem von ihm geschaffenen Mount-Punkt ausf\u00fchren, was es ihm beispielsweise erm\u00f6glicht, die Einstellungen der Datei \/etc\/sudoers oder die PAM-Parameter in seiner eigenen Verzeichnisstruktur zu \u00e4ndern und so die M\u00f6glichkeit zu erhalten, Befehle mit Root-Rechten \u00fcber die Tools sudo oder su auszuf\u00fchren. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"