{"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\/en\/blog\/news\/uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme","title":{"rendered":"A vulnerability in firejail allows root access in the system","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
A vulnerability (CVE-2022-31214) has been discovered in the Firejail application isolation utility, allowing a local user to gain root privileges on the host system. There is a working exploit publicly available, verified on current releases of openSUSE, Debian, Arch, Gentoo, and Fedora with the firejail utility installed. The issue has been resolved in firejail version 0.9.70. As a workaround, you can set the parameters 'join no' and 'force-nonewprivs yes' in the configuration file (\/etc\/firejail\/firejail.config). <\/p>\n
Firejail uses namespaces, AppArmor, and seccomp-bpf for syscall filtering in Linux to isolate applications, but requires elevated privileges for isolated execution, which it obtains through a setuid root binding or by running with sudo. The vulnerability arises from a flaw in the logic of the option '--join=', intended for connecting to an already running isolated environment (similar to the login command for the sandbox) by identifying the environment using the process ID within it. Before privilege dropping, firejail checks the privileges of the specified process and applies them to the new process connecting to the environment using the '--join' option. <\/p>\n
Before connection, a check is performed to determine if the specified process is running in the firejail environment. This check evaluates the presence of the file \/run\/firejail\/mnt\/join. To exploit the vulnerability, an attacker can simulate a non-isolated firejail environment by using a mount namespace, subsequently connecting to it using the '--join' option. If the settings do not activate the restriction on acquiring additional privileges in new processes (prctl NO_NEW_PRIVS), firejail will connect the user to the simulated environment and attempt to apply the user namespace settings of the init process (PID 1). <\/p>\n
As a result, the process connected via «firejail —join» will end up in the user's original user ID namespace with unchanged privileges, but in a different mount namespace fully controlled by the attacker. This means the attacker can execute setuid-root programs in the mount namespace they created, allowing, for example, changes to the settings in \/etc\/sudoers or PAM parameters in their file hierarchy, enabling command execution with root privileges using sudo or su utilities. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"