A vulnerability (CVE-2022-31214) has been identified in the Firejail Application Sandboxing Tool that could allow a local user to become root on the host system. There is a working exploit in the public domain, tested in current releases of openSUSE, Debian, Arch, Gentoo and Fedora with the firejail utility installed. The issue has been fixed in the release of firejail 0.9.70. As a workaround for protection, you can set the parameters "join no" and "force-nonewprivs yes" in the settings (/etc/firejail/firejail.config).
Firejail uses the namespaces mechanism, AppArmor, and system call filtering (seccomp-bpf) on Linux for isolation, but requires elevated privileges to set up an isolated launch, which it obtains through linking to the suid root flag utility or running with sudo. The vulnerability is caused by an error in the logic of the "--join=" option. β, designed to connect to an already running isolated environment (analogous to the login command for a sandbox environment) with the definition of the environment by the process ID running in it. Before dropping privileges, firejail detects the privileges of the specified process and applies them to the new process that joins the environment with the "--join" option.
Before connecting, it checks if the specified process is running in the firejail environment. This check evaluates the existence of the file /run/firejail/mnt/join. To exploit the vulnerability, an attacker can simulate a fictitious non-isolated firejail environment using the mount namespace, and then connect to it using the β-joinβ option. If the settings do not enable the prohibition of obtaining additional privileges in new processes (prctl NO_NEW_PRIVS), firejail will connect the user to a fictitious environment and try to apply the settings of the user namespace of the user identifiers (user namespace) of the init process (PID 1).
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 point space, completely controlled by the attacker. Among other things, the attacker can execute setuid-root programs in the mount point space he created, which allows, for example, changing /etc/sudoers settings or PAM parameters in his file hierarchy and gaining the ability to execute commands as root using the sudo or su utilities.
Source: opennet.ru