Impact
If bubblewrap is installed in setuid mode and the kernel supports unprivileged user namespaces, then the bwrap --userns2 option can be used to make the setuid process keep running as root while being traceable. This can in turn be used to gain root permissions.
Note that this only affects the combination of bubblewrap in setuid mode (which is typically used when unprivileged user namespaces are not supported) and the support of unprivileged user namespaces.
Known to be affected are:
- Debian testing/unstable, if unprivileged user namespaces enabled (not default)
- Debian buster-backports, if unprivileged user namespaces enabled (not default)
- Arch if using
linux-hardened, if unprivileged user namespaces enabled (not default)
- Centos 7 flatpak COPR, if unprivileged user namespaces enabled (not default)
Patches
This has been fixed in the 0.4.1 release, and all affected users should update.
Workarounds
Kernels after 4.9 supports limiting unprivileged user namespaces by setting /proc/sys/user/max_user_namespaces to 0. In fact, some systems, such as RHEL7 set this by default. This setting mitigates the vulnerability.
Some patched kernels, such as the linux package in Debian and the linux-hardened package in Arch Linux, support disabling unprivileged creation of user namespaces by setting /proc/sys/kernel/unprivileged_userns_clone to 0. This is done by default in some distributions such as Debian, and also mitigates the vulnerability.
Impact
If bubblewrap is installed in setuid mode and the kernel supports unprivileged user namespaces, then the
bwrap --userns2option can be used to make the setuid process keep running as root while being traceable. This can in turn be used to gain root permissions.Note that this only affects the combination of bubblewrap in setuid mode (which is typically used when unprivileged user namespaces are not supported) and the support of unprivileged user namespaces.
Known to be affected are:
linux-hardened, if unprivileged user namespaces enabled (not default)Patches
This has been fixed in the 0.4.1 release, and all affected users should update.
Workarounds
Kernels after 4.9 supports limiting unprivileged user namespaces by setting
/proc/sys/user/max_user_namespacesto 0. In fact, some systems, such as RHEL7 set this by default. This setting mitigates the vulnerability.Some patched kernels, such as the
linuxpackage in Debian and thelinux-hardenedpackage in Arch Linux, support disabling unprivileged creation of user namespaces by setting/proc/sys/kernel/unprivileged_userns_cloneto0. This is done by default in some distributions such as Debian, and also mitigates the vulnerability.