bubblewrap-0.4.1

[Bruce Dubbs]

New point version.

[Douglas R. Reno]

Release Notes

This release fixes a privilege escalation bug pointed out by Stephen Röttger, where in some setups
bubblewrap can be used to gain root permissions. Only version 0.4.0 is vulnerable, and only
if installed setuid while at the same time the kernel supports unprivileged user namespaces.
More details in the advisory here:

GHSA-j2qp-rvxj-43vj

Additionally there are some minor changes:

    Always clear the capability bounding set (cosmetic issue)
    Make the tests work with libcap >= 2.29
    Properly report child exit status in some cases

Alexander Larsson (9):
Ensure we're always clearing the cap bounding set
Don't rely on geteuid() to know when to switch back from setuid root
Don't support --userns2 in setuid mode
drop_privs: More explicit argument name

Christian Kastner (1):
tests: Update output patterns for libcap >= 2.29

Jean-Baptiste BESNARD (1):
retcode: fix return code with syncfd and no event_fd

TomSweeneyRedHat (1):
Add Code of Conduct

Security Advisory

Severity
    high

Packages

    bwrap 

Affected versions
    0.4.0 (setuid mode) 

Patched versions
    0.4.1 

CVE identifier
    CVE-2020-5291 

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.

[Douglas R. Reno]

Fixed at r22927

[Bruce Dubbs]

Milestone renamed

[Bruce Dubbs]

Milestone renamed