[Pkg-utopia-maintainers] Bug#923557: bubblewrap: insecure use of /tmp

[Simon McVittie]

Control: forwarded -1 https://github.com/projectatomic/bubblewrap/issues/304

On Fri, 01 Mar 2019 at 22:43:40 +0100, Jakub Wilk wrote:
> [If] /run/user/<UID>/.bubblewrap/ doesn't exist and couldn't be created (as
> was the case on my system)

Mitigation: libpam-systemd creates a suitable /run/user/<UID>, so many
(even most) Debian systems will have this directory.

> bubblewrap falls back to
> /tmp/.bubblewrap-<UID>/. Local attacker could exploit this to prevent other
> users from running bubblewrap, for example:
> 
>   getent passwd | cut -d: -f3 | xargs printf '/tmp/.bubblewrap-%d\n' | xargs touch

As you say, creating non-directory, non-symlink files here is a denial
of service.

> But it gets worse, because bubblewrap is happy to use existing
> /tmp/.bubblewrap-<UID>/, even when the directory is owned by some else. In
> the worst case, this could be exploited by a local user to execute arbitrary
> code in the container. (Though I couldn't find any way to exploit this
> without disabling protected_symlinks.)

This directory is a mount point for a tmpfs that only exists in
bubblewrap's mount namespace, so I don't think its contents matter (which
is why it's OK that all bubblewrap processes with the same uid use the
same directory): the first thing bubblewrap does with it is to mount a
tmpfs over the top, which will be owned by the user running bubblewrap.
If it's a symlink to a different directory (without protected_symlinks)
then I can see some possible attack routes, which I won't go into on
this public bug.

There are some tricky constraints on this directory. I think it might be
created at a point in bubblewrap's lifetime where it shouldn't be trusting
environment variables, so it can't fall back from $XDG_RUNTIME_DIR to
$XDG_CACHE_HOME to $HOME/.cache like GLib does; but as far as I can see
there's no good time for bubblewrap to delete the directory, so if it used
mkstemp() you'd get one empty directory in /tmp for every bubblewrap run,
which would never be deleted, which is eventually also denial of service.

We can probably address this at a distro level by creating an empty
directory somewhere (in the package or in maintainer scripts) and
making bubblewrap use that - because it mounts a tmpfs over the top,
all it needs is a mount point somewhere out of the way, that you aren't
ever going to want to expose in one of your bubblewrap-based containers
(which rules out using /run, /tmp, /mnt, etc. as the mount point, because
you might want to share those with the host). I'm not sure whether that's
a suitable solution for upstream, though.

    smcv