They recently released the news that a vulnerability was identified (already listed under CVE-2022-31214) in the Firejail app sandboxing tool, it is detailed that the detected flaw could allow a local user to become root on the host system.
Firejail uses the namespaces mechanism, AppArmor, and system call filtering (seccomp-bpf) in Linux for isolation, but requires elevated privileges to configure an isolated release, which it obtains by binding to the suid root flag utility or run with sudo.
The vulnerability is due to an error in the logic of the “–join=” option », designed to connect to an isolated environment that is already running (similar to the login command for a sandbox environment) with the environment defined by the ID of the process running in it. In the pre-launch phase, 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, checks if the specified process is running in the firejail environment. This check evaluates the existence of the /run/firejail/mnt/join file. To exploit the vulnerability, an attacker can simulate a fictitious non-isolated firejail environment using the mount namespace and then connecting to it using the "--join" option.
If the configuration does not enable the mode of prohibiting obtaining additional privileges in new processes (prctl NO_NEW_PRIVS), firejail will connect the user to a fictitious environment and try to apply the user namespace configuration of user identifiers (namespace user) of the init process (PID 1).
Most of the logic behind the join function is in the source code from the `src/firejail/join.c` file. Critical sections of code are executed with elevated privileges (effective UID 0). The ID of the process passed as a command the line argument is inspected to determine if it is an rcontainer and determine some of its properties that It also applies to the new entry process.
The main criteria for deciding whether to join the target process succeeds is the presence of a file in the mount namespace of the target, process found in /run/firejail/mnt/join. This verification is done on the f`is_ready_for_join()` function. The file is opened using lThe `O_RDONLY|O_CLOEXEC` flags and the trace `fstat()` result should meet the following requirements:
– the file must be a normal file.
– the file must be owned by userid 0 (as seen from the initial user
namespace).
– the file must be 1 byte in size.
As a result, the process connected via "firejail --join" will end up in the namespace user's original user ID with unchanged privileges, but in a different mount point space, completely controlled by the attacker.
The resulting "joined" shell will now live on the initial user
namespace, still keeping the original normal user privileges, however the mount namespace will be the one controlled by the attacker. As
the nonewprivs configuration has not been applied, the attacker can now
run setuid-root programs within this mount namespace
In particular, an attacker can run setuid-root programs in the space of the mount point it created, allowing it to, for example, change /etc/sudoers configuration or PAM parameters in its file hierarchy and gain the ability to run commands as root using sudo or its utilities.
Finally, it is worth mentioning that a functional exploit has been developed, tested on current versions of openSUSE, Debian, Arch, Gentoo and Fedora with the firejail utility installed.
The problem was fixed in firejail version 0.9.70. As a security fix, you can set the configuration (/etc/firejail/firejail.config) to "no join" and "force-nonewprivs yes".
Finally if you are interested in knowing more about it, you can check the details in the following link