potentially insecure use of /tmp

[smcv]

@jwilk reported this Debian bug (#923557):

[If] /run/user/<UID>/.bubblewrap/ doesn't exist and couldn't be created
(as was the case on my system), 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

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.)

[smcv]

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.

Distribution packages can probably address this 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 those are useful directories that you might want to share with the host).

[smcv]

Distribution packages can probably address this by creating an empty directory somewhere (in the package or in maintainer scripts) and making bubblewrap use that

In fact it looks as though we can use any directory that is guaranteed to exist and be owned by root on any reasonable distribution, like /proc (which we already trust anyway), /tmp or /run, because by the time the container starts manipulating mount points we've already done the pivot_root dance.

[smcv]

I would very much appreciate review on this. I'm preparing an upload to Debian unstable, but I don't think I'm comfortable with preparing stable updates with a backport of the solution I proposed until someone with a better overview of how bubblewrap uses pivot_root has reviewed it.

[kdelee]

@smcv any plans to cut a release including this fix?

[smcv]

I don't do releases for this project. @cgwalters?

[ret2libc]

I think this deserves a CVE. Has anyone already requested one? Any objections against having one allocated?

[cgwalters]

For reference this was fixed with https://github.com/projectatomic/bubblewrap/releases/tag/v0.3.3

I think this deserves a CVE. Has anyone already requested one? Any objections against having one allocated?

No objections though I'd also note that I believe this to not be exploitable in most distributions (including RHEL) since XDG_RUNTIME_DIR will be set and we won't fall back to /tmp.

[ret2libc]

No objections though I'd also note that I believe this to not be exploitable in most distributions (including RHEL) since XDG_RUNTIME_DIR will be set and we won't fall back to /tmp.

I agree. I will request anyway one so that each distro can judge for itself.

[ret2libc]

CVE-2019-12439 was assigned to this issue.